I'll have a look.

It seems like it's not getting an EOF, or not handling end of data properly. I added some printing to show how much of the response comes back, and it seems to get the full content but does not EOF (which would let the read return):

[] ~/projects/puma $ jruby -Xjit.threshold=0  -Ilib test/test_puma_server.rb -n test_custom_http_codes_10
/Users/headius/projects/jruby/lib/ruby/stdlib/power_assert.rb:7: warning: tracing (e.g. set_trace_func) will not capture all events without --debug flag
Loaded suite test/test_puma_server
Started
HTTP/1.0 449 CUSTOM
Content-Length: 0

^C

Ok, this is interesting. If I make the content of the response non-empty, it doesn't hang. Something about content-length=0 is causing this.

I suspect there's something preventing the socket from getting closed when content-length=0, and assuming this works ok in MRI it would mean that JRuby's not closing the stream.

I guess it is the last one because it is not hanging on JRuby 1.7 (see https://travis-ci.org/puma/puma/jobs/63112451)

I think I've found the issue. Because we often (usually) use JDK streams for most types of IO, we have to emulate errno behavior to match C's write(2). My logic there was producing an errno of EAGAIN whenever zero data could be written to a nonblocking stream. However in this case, it's a zero-length write, so it should just report that it wrote 0 rather than marking EAGAIN.

Fix should be coming shortly.

Great, thanks! I hope my catch helped a bit to improve JRuby :)

@deepj Indeed it did! This is a peculiar edge case we must not have had any test cases for.