-
Notifications
You must be signed in to change notification settings - Fork 137
Home
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).
Sinatra page includes valuable hints on using "bare" Rack frameworks
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.
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.