Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


hdost edited this page · 7 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 ...

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


JRuby-Rack is compatible with multiple versions of Rack (1.1 - 1.5). The rack gem is vendored and bundled with our artifacts, but it's rarely used these days. If you use Bundler and/or Warbler the bundled/packaged 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

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

JRuby::Rack Stuff


Something went wrong with that request. Please try again.