-
Notifications
You must be signed in to change notification settings - Fork 0
JRubyOnRailsInGlassFish
» JRuby Project Wiki Home Page » JRuby on Rails: Glassfish V3 Deployment
Glassfish is an open source Java EE 5 application server. Java EE is a long tested deployment environment and by combining the benefits of GlassFish with JRuby, we should be able to provide the best deployment environment for Rails applications. Here are some of the benefits of using GlassFish as the deployment environment for JRuby on Rails applications :- Use the time tested Java EE deployment platform
- Avoid the complex Mongrel based deployment environment that one has to use to deploy Rails application.
- With the availability of Goldspike one can deploy a war file of your Rails application directly to a GlassFish instance.
- Java EE and Ruby-on-Rails applications can be easily integrated in one container. This allows to host JRuby-on-Rails applications in organizations who have already made investment in Java EE.
- Rails applications can certainly benefit from the out-of-the-box clustering and high-availability support provided by GlassFish.
- Reuse your database connections by using the database connection pooling mechanism provided by GlassFish.
- Last, but not the least, JRuby-on-Rails can leverage the extensive set of Java libraries.
In GlassFish v2 we currently support the war mode of deployment for your JRuby on Rails applications. The war can be created from your existing Rails applications by using Warbler.
Refer to the section titled "GlassFish V2" of the Getting Started Guide.
At the end of these steps ensure that you have the following environment variables defined :
GLASSFISH_ROOT - pointing to the directory where GlassFish V2 is installed JRUBY_HOME - the jruby version which would point to $GLASSFISH_ROOT/jruby/jruby-1_0_3/jruby-1.0.3. PATH - add $GLASSFISH_ROOT/bin and $JRUBY_HOME/bin to your existing PATH environment variable.
For those of you would like to deploy their own JRuby on Rails application, skip this section and refer to the next section titled "How to deploy JRuby on Rails applications".
Below you would find steps that would help you create a very simple JRuby on Rails "hello" application using the JRuby version that you have installed using the steps mentioned in the "Setup" section above.
cd $GLASSFISH_ROOT/jruby/samples jruby -S rails hello jruby script/generate controller say message ( to create a controller "say" with a view "message" )
Let us see how we could deploy this application to GlassFish v2 in both the Standalone Mode and Shared Mode. In the instructions listed below change the directory name if you are trying to deploy your own JRuby on Rails application.
If you already have a war file of your JRuby on Rails application (created using Warbler or Goldspike) then you could directly refer to the section "To deploy the Rails application".
- Go the Rails application directory :
cd $GLASSFISH_ROOT/jruby/samples/hello $GLASSFISH_ROOT/lib/ant/bin/ant -f $GLASSFISH_ROOT/jruby/install.xml create-standalone
You would now find a WEB-INF directory under "hello" sample directory which would contain web.xml and 2 directories lib and gems
- Before we do a directory deployment of the sample to Glassfish, ensure that the GlassFish application server is running :
cd .. asadmin start-domain
Note : If the application server is already running the command safely exits
To deploy the Rails application :
cd $GLASSFISH_ROOT/jruby/samples asadmin deploy hello
- Access the following URLs in a browser :
http://localhost:8080/hello
For having an application deployed in shared mode, first ensure that you have followed the "Post Installations" of the Getting Started Guide. Please note that the steps have to done only once for a GlassFish installation.
You would now find a WEB-INF directory under "hello" sample directory which would just contain web.xml
- To deploy the Rails application :
cd $GLASSFISH_ROOT/jruby/samples/hello $GLASSFISH_ROOT/lib/ant/bin/ant -f $GLASSFISH_ROOT/jruby/install.xml create-shared
- Access the following URLs in a browser :
http://localhost:8080/hello
Are you deploying on Glassfish on Windows? Well before you do think long and hard. Windows brings with it a unique set of challenges. First off the Jruby team admittedly has not devoted as much time as they would like testing on the Windows platform. Having said that, I've found that they have generally done a good job but from time to time we have found issues. So I thought I could share some of the issues we've run into and how we've worked around them.
If you are new to windows, it is worth knowing that windows likes to "lock" files on you. What do I mean by this? Well when you go to delete a file or move it or change it windows sometimes tells you that "the file is in use." (Sometimes it doesn't tell you this). DON'T IGNORE this message. When we redeploy our war file we always get : "The file jnidispatch.dll is in use and wasn't overwritten". You can safely ignore this if you haven't updated your version of jruby. But if you have. You should :
- undeploy your app
- stop your domain
- start your domain
- deploy the new version of your app
When deploying a war file via script (we layered ruby over the asadmin command set and did our deploys with rake), if you deploy your war file as such:
asadmin deploy "MyApp.war"Make sure if you undeploy your script you are undeploying "MyApp" and not myApp. Apparently it doesn't matter if the casing on your War file is myapp.war... it really only matters what you typ into your deploy step. (if you are coming from linux you probably are a guru with casing already)
Can't stress this enough (and this doesn't necessarily apply just to windows). Take the time to profile your application under load and at steady state and find the right set of JVM parameters that will make your app sing. Glassfish can really handle a heavy load. But you have to TUNE TUNE TUNE.
- Here is a subset of our JVM options in our domain xml:
<jvm-options>-XX:SurvivorRatio=2</jvm-options>
<jvm-options>-XX:MaxPermSize=192m</jvm-options>
<jvm-options>-server</jvm-options>
<jvm-options>-Xmx1000m</jvm-options>
<jvm-options>-Xms1000m</jvm-options>
<jvm-options>-XX:NewRatio=2</jvm-options>
<jvm-options>-Djavax.net.ssl.sessionCacheSize=10000</jvm-options>
NOTE the -server option makes a big difference.
This is also not specifically a windows issue, but GF v2 doesn't like colons (:) in URLs. We have some REST based web services, and we had some resources that had colons in the resource IDs. We ended up having to code around that. (FWIW: I believe that V3 and Tomcat don't have this issue).
I would recommend fronting your app server with something like Apache and having it handle the SSL stuff. We didn't do that and ran into lots of issues.
Setting up SSL was pretty straightforward. However we encountered some odd issues. First off, under load we run out of memory. That's not good. Diagnosing the problem with Jconsole heap dumps and a java profiler showed us that we had a Cache for the SslSessionContextImpl softreferences (and the references didn't point to anything) that was growing unbounded. From looking at the source code of the class, it appears that there is a default timeout to clean up this cache that's 24hours. I couldn't find a way to change the timeout. But I did find a way to limit the size of the cache. (see the last JVM-OPTION in the list above, the one that sets the ssl.sessionCacheSize).
After setting this, I thought I was out of the woods. I was handling 400 simultaneous users under a supremely heavy load, the memory was holding great, I knew that when I upgraded to rails 2.2.2+ I'd be able to handle even more. I was happy. Until my app crashed because... windows ran out of nonpaged pool memory. Why? Why? Why? Come to find out, this is the problem we were seeing Win 2k3 non paged pool. Well changing the blocking characteristic to true for Grizzly seems to me that we are not going to be able to handle as much load. But it appears to be stopping the nonpaged pool leak. I only applied the fix to my SSL listener as we had never seen this problem before switching to SSL.
GlassFish V3 is the next major release of the GlassFish application server with the focus on modularization, enablement of non Java EE containers, and embedability. As part of GlassFish V3 we have created a gem which would help users to launch their Ruby on Rails (ROR) applications embedded within the JRuby VM space.
Refer to the the section titled "GlassFish V3" of the Getting Started Guide.
At the end of these steps ensure that you have the following environment variables are defined :
JRUBY_HOME - the jruby version.
PATH - add $JRUBY_HOME/bin to your existing PATH environment variable.
Refer to the instructions provided in the "Sample Application" section of GlassFish V2 to create a very simple "hello" application. The directory name where you create the application would be different. Again for users who would like to use their own application please feel free to do so.
To deploy a Rails application with GlassFish v3 gem :
cd <directory_that_contains_the_hello_application> jruby -S glassfish_rails hello
That's it! You would see an output similar to the one listed below in the console where you started the Gem:
Jan 4, 2008 3:35:52 PM com.sun.grizzly.standalone.StaticResourcesAdapter <init> INFO: New Servicing page from: /Users/pramodgopinath/jruby-1.0.3/bin/hello/public Jan 4, 2008 3:36:00 PM com.sun.enterprise.v3.server.AppServerStartup run INFO: Startup service : Application Loader Jan 4, 2008 3:36:00 PM com.sun.enterprise.v3.server.AppServerStartup run INFO: Startup service : Grizzly on port 8080 Jan 4, 2008 3:36:00 PM com.sun.enterprise.v3.server.AppServerStartup run INFO: Glassfish v3 started in 8567 msThe application is deployed and ready to accept requests.
Use the following urls to check out the application :
http://localhost:8080/hello
http://localhost:8080/hello/say/message
GlassFish JRuby Wiki
Rails powered by GlassFish Application Server
Email dev@glassfish.dev.java.net aliasto discuss problems/issues with GlassFish deployments of JRuby on Rails applictions