Forum: JRuby Which Rack web server?

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
John B. (Guest)
on 2015-04-27 20:57
(Received via mailing list)
Which Rack web server are folks using with JRuby? Any particularly bad
good experiences?

I suppose the only ones that support threading are Puma and Passenger?
Uwe K. (Guest)
on 2015-04-27 23:29
(Received via mailing list)
We are using Puma and are very happy with it.  We used to use trinidad
and were happy with that to.

was a trigger for us to switch in addition to puma supporting both MRI
and JRuby.  heroku’s move to puma as the recommended rack server was
also a factor.

We have been looking at torquebox 4 (not torquebox 3), but we will stick
with puma for a long while, I think.

> On 2015-04-27, at 18:55, John Joseph B. <removed_email_address@domain.invalid> wrote:
> Which Rack web server are folks using with JRuby? Any particularly bad or good
> I suppose the only ones that support threading are Puma and Passenger?

Uwe K.
Doug Hathaway (Guest)
on 2015-04-27 23:31
(Received via mailing list)
Tomcat deployed via Warbler.

On Mon, Apr 27, 2015 at 12:55 PM, John Joseph B. <
Christian MICHON (Guest)
on 2015-04-29 01:36
(Received via mailing list)
Mizuno (jetty).
- fastest from what I measured with apache-bench on my machines
- simplest configuration (almost none)

Only drawback: CTRL-C does not work well on Windows (the java process
be detached and will keep running), you might need to implement a
hook in your app.
Benjamin O. (Guest)
on 2015-04-29 02:05
(Received via mailing list)
We use Trinidad (multithreaded) and are satisfied with it. It's fast
and it scales and can be monitored nicely. We use Passenger for MRI apps
and have considered standardizing on Passenger or puma for everything,
don't have any specific plans to do so.

FWIW I think you have to buy Passenger Enterprise to run your app
multithreaded on Passenger.

On Tue, Apr 28, 2015 at 4:34 PM, Christian MICHON <
Theo Hultberg (Guest)
on 2015-04-30 10:01
(Received via mailing list)
Our experience is that there doesn't exist a good, correct, performant
server for JRuby. We've used most of them, for two use cases: embedded
status APIs in long running applications and as the primary interface
applications with a HTTP API.

We package our applications as standalone JAR files with JRuby and all
gems, and run them with `java -jar ...`, and this rules our some of the
options. Either because some servers just don't work when run that way
because they assume they will be able to muck about with the file system
any way they like, or because they need to be in control, they need to
the container of the application.

These are the servers we've tried, and our experience. If your use case
different, for example serving Rails apps, this may not be your

* Fishwife is the only one we've found that doesn't have significant
and can be embedded. It's not perfect, but it works well for us.

* Mizuno is the precursor to Fishwife, and it hasn't been updated in

* Puma is nice and I'd really like to use it, but the error handling is
buggy. It has often filled up disks with error messages. I think the
of this has been fixed, but in our experience it doesn't handle
errors very well. We stay well away from Puma.

* Jubilee showed some great promise but then development stopped. We
haven't tried the last released version, but the last version we tried
significant bugs around request body handling.

* rack-jetty was abandoned several years ago and doesn't handle request
bodies over 4 KiB.

* I'm not aware of any major bugs in Trinidad, but it doesn't work when

* Torquebox is also not embeddable, and version 4 is starting to feel

* WEBrick works surprisingly well for status APIs that don't get called
very often.

As I said, our use case is very different from serving a Rails
so your experience will probably be different.


On Wed, Apr 29, 2015 at 12:04 AM, Benjamin O. 
Christian MICHON (Guest)
on 2015-04-30 10:12
(Received via mailing list)

A small correction is needed on this specific sentence: "Mizuno is the
precursor to Fishwife, and it hasn't been updated in years"

Mizuno had a new release 1 week ago and the last one before was less
than 9
months ago...
Theo Hultberg (Guest)
on 2015-04-30 11:23
(Received via mailing list)
Christian, my bad, last I checked it was dead, but looking at the repo
it has had some activity. That said, the diff between now and two years
is just updates between maintenance releases of Jetty and a setting for
min number of threads, so I'll revise my statement to "it basically
been updated in years". That doesn't mean that it's bad or unstable,
that it might be hard to get bugs fixed.


On Thu, Apr 30, 2015 at 8:10 AM, Christian MICHON <
Christian MICHON (Guest)
on 2015-04-30 12:51
(Received via mailing list)
Fishwife seems to be a well maintained product.

Yet it may not work with legacy rack applications, as it is not
with ruby 1.8 mode. In 1.8 mode, you'll get systematically the following
500 error:
[qtp1296674576-15] ERROR fishwife.RackServlet - On service:
constant Fishwife::RackServlet::ASCII_8BIT

But thanks for mentioning this gem Theo. :-)
Theo Hultberg (Guest)
on 2015-05-01 16:19
(Received via mailing list)
IIRC Fishwife also does not support Java 6 because of it's use of Jetty
On the other hand both Ruby 1.8 and Java 6 are EOL, so I don't think
can be blamed for not supporting them anymore. I guess you could argue
JRuby in 1.8 mode is not EOL just because MRI 1.8 is EOL, though, but
still, legacy code bases that can't be updated will also require legacy
versions of dependencies.


On Thu, Apr 30, 2015 at 10:50 AM, Christian MICHON <
This topic is locked and can not be replied to.