Karol Bucek edited this page Jan 22, 2016 · 8 revisions

JRuby-Rack is available as a Ruby-friendly gem release as well as a standalone Java-Servlet-friendly jar released using Maven, look for the latest version by searching for jruby-rack at http://search.maven.org/ ...

JRuby-Rack gets also bundled when using Warbler, which is available as a Ruby gem (gem install warbler) on MRI/JRuby.


JRuby-Rack is mostly compatible with multiple versions of Rack (1.2 - 1.6). A suitable rack gem is vendored and bundled with our artifacts, although it's rarely used these days. If you use Bundler and/or Warbler the bundled/packaged rack version will be used, it's only there as a last resort (for an out of the box rack experience).

JRuby on Rails

JRuby on Rails

Java Servers

Rails Step by Step

Deploying with WebLogic

Rack on JRuby

Sinatra page includes valuable hints on using "bare" Rack frameworks

Servlet Integration

JRuby-Rack's main mode of operation is as a servlet filter org.jruby.rack.RackFilter. This allows requests for static content to pass through and be served by the application server. Dynamic requests only happen for URLs that don't have a corresponding file, much like many Ruby applications expect.

A base-servlet org.jruby.rack.RackServlet is included as well. When setting up the servlet it will likely be mapped to handle all paths (using /*) one caveat might be that static content is likely to be served by Rack than (which requires acquisition of a runtime). Your throughput with static files will be much lower than when JRuby-Rack is configured as a servlet filter. This largely depends on how the container itself is configured and how it conforms to the servlet-spec when an user-servlet is mapped to handle all requests. You should also consider tuning the context configuration and/or overriding the servlet if this turns out to be an issue.

More details about the setting up / configuring the servlet environment can be found at Servlet Integration.

Runtime Management

JRuby-Rack allows you to run in a pooled mode which is similar to spawning multiple Ruby server processes (such as Mongrel) but in a single JVM process. This of course will require more memory than running in a single shared Ruby runtime.

Historically Rails and esp. most of the plugins and extension gems were not written in a thread-safe first manner. Thus up until JRuby-Rack 1.1 Rails is pooled by default (with max 5 runtimes) while (non-Rails) "plain" Rack applications are by default started in a single shared runtime (all requests run within the same Ruby environment). With the release of Rails 4.0 the horizon seems to be shifting to being thread-safe by default, thus expect JRuby-Rack 1.2 to default to shared runtime mode for all unless configured to pool.

Understanding the Metal

JRuby Performance Tunning

Concurrency in JRuby