I wanted to share my experience upgrading to Jruby 1.7.4 from Jruby 1.6.7 for our Ruby on Rails 3.1 application that is deployed onto Windows servers.
Background:
My company has developed a check payment processing solution from using Ruby on Rails. We host our own instance of the application but the majority of the deployments are in-house at various financial institutions. The requirement for Windows is coming from these in-house deployments. We experimented with MRI for windows with limited success, eventually opting for Jruby for deployment. We started on Jruby 1.5.x about two years ago.
Deployment:
We use warbler to generate a ROOT.war file that gets deployed via Tomcat running as service on the windows machine. We have 2-5 resque workers running as services as well on the server, they connect to a native Windows redis build (https://github.com/MSOpenTech/redis). We’ve considered full stack deploy solutions (i.e. TorqueBox) but prefer the flexibility of warbler and really like resque/sidkiq.
We were “stuck” on 1.6.7 for a year or so as upgrading to 1.7.x cause the following issues:
Unreliable rake assets:precompile
Odd rails console issues in windows
Gem incompatibilities
We weren’t thrilled with the speed of 1.6.7, but it was our only option for a while. We would get customer complains of “slowness” often and had to compensate with more server CPUs.
I would test each 1.7.x with eager anticipation to see if these issues were fixed. I’m happy to say that 1.7.4 resolved them all (mostly).
With 1.7.4 we have:
Very reliable rake assets:precompile, its actually faster than 1.6.7
Approx 30% speed increase in rendering HAML templates
Better 1.9.3 compatibility
Windows rails console issues were more of a “Windows” problem, probably best explained in my stackoverflow answer: http://stackoverflow.com/questions/13649437/rails-console-issues-using-jruby-no-prompt-character-no-tab-completion-broken/16678898#16678898
We had a minor issue with the cocaine + paperclip gems that required us to fork paperclip. From what I can tell, $? (current thread variable) is getting set to nil if you try to execute a system command that does not exists (i.e. file not found in Windows). I can open an issue for this soon.
Overall our system is much more responsive now with the average request time dropping 20% to 30%. We’ve deployed to 4 customer sites and the feedback has been overwhelmingly positive. We are in the process of migrating from reque to sidekiq now, as sidekiq requires 1.7.x.
:USE_READLINE to true' does not solve the issue reported on Jira (http://jira.codehaus.org/browse/JRUBY-6996)Guys: thanks for fixing that scroll problem on Windows!