Greetings Railo fans,
In this article I will be covering how to setup and configure Railo with the Helicon Zoo module for IIS and then configure various custom settings. I will continue to add to this article as I find out new tricks and learn more about Jetty, so be sure to check back occasionally if you are using Helicon Zoo.
- Why Helicon zoo
- Installing Railo
- Enable Railo on your website
- Search engine friendly url's
- changing the JVM settings
- How to set the Java Agent
- Customising the JVM settings on a per site basis
Why Helicon Zoo
While Railo is a brilliant alternative to ColdFusion and has many benefits right out of the box, one of the problems it does suffer from is that like ColdFusion it runs as a service which means that every website is running inside the same instance of Java/tomcat and thus all websites can affect each other.
If you are only running a single website this is not a problem, but if you run multiple websites on the same server then this can present a couple of problems.
While Railo does offer built in sandboxing which restricts file access to the web root, this only applies to CFML code. If you drop in some Java then this completely overrides any Railo security and allows you to do pretty much anything you like. Your code will have the same level of access as the Tomcat service.
Sure you can disable direct Java access, but doing this will break virtually every modern app or framework, all of which use Java in some fashion.
- Stability and performance
If you run multiple websites then you also run the risk that any one of those sites will kill Tomcat by coming all its resources and thus take down all your other sites in the process.
- Custom configuration
As all sites share the same JVM settings, there is no way to configure each site separate out of the box, you would need a custom multiple instance Tomcat setup/installation to do this.
Enter Helicon Zoo, which uses Jetty as the Java servlet container for Railo and runs it as a process inside IIS and thus works in the same way that PHP, ASP etc work with all the advantages.
What this basically means is that every single Railo site is by default running a dedicated instance of Java/Jetty, which runs as the application pool identity. As a result you do not have the same security issues as any Java code that is executed runs in the context of your application pool identity, so you can fully control what Railo can and cannot do with standard windows permissions in the same way as you would with PHP.
Using Helicon Zoo also provides better performance and stability as well, because each site is a completely isolated Java process, it cannot affect your other Railo sites. Because each site is running as a separate process, this also means that each site has its own memory heap all to itself, which can either be defined globally (e.g. 256mb for every site) or you can create completely a separate JVM config settings for each individual site if you prefer.
One other advantage you get with running Railo as a process is that it shuts down when not in use to conserve system resources, as defined by your application pool settings.
what this means is that if you have a site that is not very busy then Java/Jetty/Railo will only be loaded when required, if there is no further activity on your site for say 1 hour (depending on what you have defined in your app pool) then the Java process for this site will be unloaded.
The only caveat to this is that initial load time will be considerably slower each time Java has to load again, plus of course you use more memory as each site will require at least 128MB to run Railo.