JRuby 1.6.6 + Rails 3.2.1 | Lots of errors? about puma

[evanphx]

@headius Any thoughts on this?

[jrochkind]

While I'm not sure if it can be responsible for that kind of 'malloc' exception, I suspect you really need to set config.threadsafe! in a rails app used with puma, no? Otherwise puma is going to be sending overlapping concurrent requests to the same rails app instance (right?), but rails is not neccesarily running such that request/action processing is actually threadsafe for this use.

(On the other hand, I'm not entirely sure what config.threadsafe! actually does under the hood these days, it might not actually do anything important. but it (or the other config variables it triggers, like config.allow_concurrency) is documented to be neccessary for concurrent overlapping request processing. Search for threadsafe! in http://guides.rubyonrails.org/configuring.html)

You might want to see if this is still reproducible with config.threadsafe!. And puma README probably ought to say in the Rails section that you want to config.threadsafe! (as well as be sure you aren't doing anything in app code that's not threadsafe under concurrent request handling)

[bporterfield]

I saw the malloc error when I used the puma gem direct from github with bundler. After some poking around I realized that bundling using git (gem 'puma', :git => https://github.com/puma/puma.git) does not build the java extension - it only builds the c extension. Forking the gem myself, building the java extension manually, and pointing bundler at my local path (gem 'puma', :path => ~/stuff/puma) resolved the issue. I'm guessing that Jruby's experimental c compilation stuff actually kinda worked, and that's why the error isn't consistent?

When puma 1.0 was released, the java platform gem was not pushed right away (#49) so a re-install of the gem may be all you need.

[headius]

Would be nice for someone to file a separate bug for either Puma or Bundler to get the git repo to build the java version properly under that Gemfile setup.

[bporterfield]

Re-opened issue #42 I had closed previously: #42

[sorentwo]

Was this issue essentially covered by issue #42 ? If so can this be closed?

[evanphx]

Closing since it seems to be stale.