CODEWITHSUNDEEP
multithreadingruby-on-rails-5puma
Julie
Julie

Reputation: 2011

Are Rails Thread.current variables isolated to a single user request?

I am using Thread.current to store a current user id so that I can see who did various updates to our database. However, after some usage in production, it is returning other user ids than those who could be updating this data. Locally and on lesser-used QA instances, the user ids saved are appropriate.

We are using Rails 5.1, ruby 2.5.1 with Puma. RAILS_MAX_THREADS=1, but we do have a RAILS_POOL_SIZE=5. Any ideas what might cause this issue or how to fix it? Specifically, does a single Thread.current variable last longer than a single user request?

Upvotes: 2

Views: 1226

Answers (1)

Myst
Myst

Reputation: 19221

Why would Thread.current be limited to a request?

The same thread(s) are used for multiple requests.

Threads aren't killed at the end of the request, they just picks up the next request from the queue (or wait for the a request to arrive in the queue).

It would be different if you used the Timeout middleware, since timeouts actually use a thread to count the passage of time (and stop processing)... but creating new threads per request introduces performance costs.

Sidenote

Depending on your database usage (blocking IO), RAILS_MAX_THREADS might need to be significantly higher. The more database calls / data you have the more time threads will spend blocking on database IO (essentially sleeping).

By limiting the thread pool to a single thread, you are limiting request concurrency in a significant way. The CPU could be handling other requests while waiting for the database to return the data.

Upvotes: 3

Related Questions