README to highlight does not work in threadsafe mode

Question

README to highlight does not work in threadsafe mode

seantanly opened this issue 12 years ago · 13 comments

I believe the readme should include a note on quiet_assets being not threadsafe, and should turn off quiet_assets through config.quiet_assets = false.

It would save users of this gem from some frustration when they are using it in threadsafe mode, and their logs starts to disappear randomly, development mode or not.

Due how quiet_assets work, which is toggling the Rails.logger.level, based on the current implementation of the default Rails logger (3.2.11), it is probably impossible to make it work in threadsafe mode.

Further technical discussion on yell regarding this topic.
rudionrails/yell#4

Thank you for this convenient gem.

Answer 1 · 2013-01-17T07:16:37.000Z

@seantan Thanks for the info I'll take a look!

Answer 2 · 2013-01-17T11:57:42.000Z

@route You're welcomed. More specifically on the same yell thread, it is this comment, rudionrails/yell#4 (comment)

Answer 3 · 2013-01-21T08:07:21.000Z

I have an idea about this mistake. @seantan can you participate in it? I've created a branch using_middleware could you run your application and check it works properly?

Answer 4 · 2013-01-21T10:56:54.000Z

Never mind my previous comment, seems like some parts won't work for rails 4

Answer 5 · 2013-01-21T15:15:43.000Z

@route looks like an interesting idea and it seems to work for me on Rails 3.2.11 though.

Answer 6 · 2013-01-21T15:34:25.000Z

Yes it works for 3.2 but there are diffs in logger implementation between rails versions. Thinking about realization now...

Answer 7 · 2014-03-28T08:10:23.000Z

With a blank new standard MRI rails 4 app. Add puma and quiet_assets to the Gemfile. Set rails config:

config.allow_concurrency = true

Start clicking around, you loose almost all the non-asset output.

Answer 8 · 2014-03-28T08:35:09.000Z

@pierre-pretorius have you tried to use QA from master branch?

Answer 9 · 2014-03-28T08:38:27.000Z

Just tried it now: Using quiet_assets (1.0.2) from git://github.com/evrone/quiet_assets.git (at master). Still get the same problem.

Answer 10 · 2014-03-28T08:40:36.000Z

Ok got it, will take a look. Maybe @Dima-exe has something to say?

Answer 11 · 2014-03-28T08:43:57.000Z

Thanks. It seems like this gem is the only way to address asset logging. Rails config doesn't take everything away. Anyone doing Rails::Live/websockets development probably needs multi threading in dev mode. Would be great if this gem could be threadsafe.

Answer 12 · 2014-04-09T15:50:07.000Z

Any progress on this issue? To set a global variable that is scoped per thread, use: Thread.current['local_var'] = some_var

http://bonamin.org/blog/2012/03/06/thread-safe-global-variables-in-ruby/

Answer 13 · 2015-06-02T03:24:07.000Z

Using a Thread local variable won't solve this problem. This is a race condition on the Rails.logger.level object. To solve it a mutex needs to be used around the entire method body, which is probably undesirable for many reasons.

Imagine the following scenario with a rails app running on log level info

Thread 1: Request arrives
Thread 1: store Rails.logger.level into method local copy of env hash(saves 'info')
Thread 2: Request arrives
Thread 1: set Rails.logger.level = error
Thread 2: store Rails.logger.level into method local copy of env hash(saves 'error')
Thread 1: allow app to process request
Thread 1: set Rails.logger.level = 'info', the value saved earlier in this thread
Thread 2: allow app to process request
Thread 2: set Rails.logger.level = 'error', the value saved earlier in this thread

Even if you replaced the location where you are storing the current logging level with a thread safe variable you can not prevent another thread from setting the Rails.logger.level to 'error'.