`config.threadsafe!` needed with pre-4 Rails

[ghost]

I don't know what the backwards support policy is for faye-rails, but in pre-4 Rails, but I have an issue in latest Rails 3.x when running the application. I'm using latest thin and faye-rails and I get the following error:

!! Unexpected error while processing request: deadlock; recursive locking

This appears to be an issue with Faye from this issue report: https://github.com/faye/faye/issues/190. I get this issue running locally however, not on Heroku. The resolution is to add config.threadsafe! to my application.rb. This would be a great caveat to have listed or a solution to be added to the gem. I believe Rails 4 solves this problem by removing the Rack::Lock middleware which seems to be the core of the issue. Still be nice to have this issue listed with a potential solve.

[ghost]

I'll gladly submit a patch, just want some discussion around it.

[jimsynz]

Right. I guess this just seemed obvious to me because Faye uses heavy use of threads via event machine. It might be a good idea to write a "concurrency warning" section of the readme to address these sorts of issues, since they seem to crop up frequently.

[DanKnox]

I use the faye-websocket-ruby gem in one of my projects so I have had to deal with this issue for quite some time.

I haven't had time to play around with rails 4 much yet, but I can say that in rails 3 enabling config.threadsafe! in development mode typically causes some undesirable side effects. The biggest of which is that it sets config.cache_classes = true. This stops the automatic reloading of files during each request while in development which will force you to restart your server every time you make a change to the source code.

Since the Rack::Lock middleware is the only problem. I have advised users of my gem to just remove that middleware in their development environment instead of using config.threadsafe!. For production, config.threadsafe! can should be used.

You can do so easily with the following:

config.middleware.delete Rack::Lock

[nilbus]

Just to confirm, I also stopped having issues after deleting the Rack::Lock middleware as suggested above.

[amejiarosario]

:+1: yes, adding config.middleware.delete Rack::Lock in application.rb did it for me in Rails 3.2.18