I noticed this problem first when upgrading a Rails app on a Ubuntu server using jruby-1.7.0-preview2 to jruby-1.7.0.

I'm using the puma webserver listening on a unix socket and nginx as a frontend.
This is the typical nginx config part:

upstream app {
    server unix:/tmp/puma.sock fail_timeout=0;
}

On jruby-1.7.0, after a few requests CPU load of the java process goes up. Sometimes the server still responds for a few requests as the response times are getting really slow.
Finally, the whole thing doesn't repond at all, the puma webserver crashes with this error:

IOError: closed stream
          close at org/jruby/RubyIO.java:2053
  begin_restart at /u/apps/docmago/shared/bundle/jruby/1.9/gems/puma-1.6.3-java/lib/puma/server.rb:637
            run at /u/apps/docmago/shared/bundle/jruby/1.9/gems/puma-1.6.3-java/lib/puma/cli.rb:438
           call at org/jruby/RubyProc.java:249
2012-10-23 22:07:54 +0200: Listen loop error: #<Errno::EBADF: Bad file descriptor - Bad file descriptor>

Reproducing this exact behavior is hard. However, i think i managed to break it down to the following steps (this time on Mac OSX):

• Create a new empty rails app
• Put gem 'puma', '1.6.3' in the gemfile and do a bundle install
• Run bundle exec puma -b unix:/tmp/puma.sock
• In another terminal run: socat TCP-LISTEN:1234,reuseaddr,fork UNIX-CLIENT:/tmp/puma.sock (this way we can leave nginx out of the equation)
• Fire a few requests to http://localhost:1234 using your favorite browser and watch CPU load

On jruby-1.7.0-preview2 CPU load stays well under 1% for me.
JRuby-1.7.0 stable however, goes crazy.

This bug might aswell be a bug in the puma webserver.

I hope somebody will be able to reproduce this - i know it probably is a hassle.
I'm trying to find a more simple case that elaborates the problem without that many moving parts.