QueryCache/ConnectionPool thread fix #1670
Conversation
…y to maintain appropriate linkage with AR database connection across threads
…erver configuration for gzipped assets pending)
|
Thanks for patching this. Hopefully someday this will be merged into 3.1.something and I can run multi-threaded apps under Thin again. It's killing me. |
|
Hey @mjtko can you rebase your patch? |
|
Hi, Doubt this will make it into core... It's not exactly a pleasant our elegant hack! :-) Perhaps a monkey patch gem of some kind for thin though? PS. Personally, I'm using Rainbows! and DataMapper these days. :-) Cheers, Mark. [Sent from a mobile device; please excuse my brevity and top reply.]Mark J. Titorenko Jordan Hollinger reply@reply.github.com wrote: Thanks for patching this. Hopefully someday this will be merged into 3.1.something and I can run multi-threaded apps under Thin again. It's killing me. Reply to this email directly or view it on GitHub: |
|
I don't know, I'm sure there's worse code in Rails :-) I suppose the question is "has Thin been doing things wrong all along, and it just now became obvious?", in which case Thin should be patched, or "has Rails 3.1 accidentally broken a sane expectation held by Thin?", in which case Rails should be patched. Honestly I don't have enough knowledge of either code base to hazard a guess. |
|
@spastorino I'll rebase it tomorrow (Europe), though, personally, I think this should wait until after 3.1.1 so, even though I'll rebase it against 3-1-stable, I'd wait until after 3.1.1 is out of the door before pulling. Up to you to decide of course! :) @jhollinger This has always been the case when running Rails in threadsafe mode under Thin (AFAICS) and, while from my POV Thin is doing the right thing, Rails has been making an assumption about the threading model within a rack server - I would expect Rainbows! with the event machine concurrency model to suffer the same problem. In short, my belief is that active record should be patched to support this use case. |
|
@mjtko don't worry this is not going in 3.1.1. Btw please rebase it on top of master, we will merge in 3-1-stable. Thanks. |
…y to maintain appropriate linkage with AR database connection across threads
… into connection-pool-thread-fixes Conflicts: activerecord/lib/active_record/query_cache.rb
|
Argh, I've totally messed this branch up trying to rebase it! Rather than trying to unpick the mess I'll open a new pull request against master. :) |
|
@spastorino Opened against master as #3243. Sorry for the confusion. :-) |
|
+1 very annoying issue |
QueryCache/ConnectionPool thread fix (was #1670)
QueryCache/ConnectionPool thread fix (was #1670)
Under thin, QueryCache is leaking connections.
This is caused by the fact that the thread that runs the
QueryCache::BodyProxy#closemethod is not the same as the thread that executesQueryCache#call. A connection is checked out withinQueryCache#call; this connection becomes orphaned, while a new connection is checked out within#closewhen theclear_query_cachecall is made.This patch prevents the connection checked out within
QueryCache#callfrom being orphaned by creating an identifier that is stored within a thread local and used withinConnectionPoolto uniquely identify the connection. This identifier is passed toBodyProxyat construction time and pushed into the thread that ultimately becomes responsible for theclear_query_cachecall.The connection is subsequently checked back in as expected at the end of the request lifecycle, plugging the leak.