Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Random failures in ContinuationQueue#poll #462
I have been debugging random failures on Queue#subscribe and Session#create_channel for days now, where they seem to die with the top of the stack like this:
Per documentation I only allow one thread to access a particular channel at any given time. But still I run into random race conditions between an attempt to subscribe and a concurrent attempt by bunny to deliver a message on another subscription (on the same channel).
After digging into things, I found that
After deleting this one line the random failures seem to have gone away completely.
Actually even deleting the
(EDIT: by tracing it I've seen this loop body execute a second time, perhaps a little surprising given that the only remaining
At this point this is starting to look like the complexity of
Yes, it is unfortunate that Ruby's memory model is not defined or even documented. I will do some testing of your version.
On Mon, 20 Feb 2017 at 03:00, Joseph Wong ***@***.***> wrote: Actually even deleting the @cond.signal still sometimes result in a failure... which made me wonder how Ruby's memory model handles making changes visible across threads. This worked out better for me: def poll(timeout_in_ms = nil) timeout = timeout_in_ms ? timeout_in_ms / 1000.0 : nil @lock.synchronize do expiry = Time.now.utc + timeout while @q.empty? wait = expiry - Time.now.utc @***@***.***, wait) raise ::Timeout::Error if Time.now.utc >= expiry end item = @q.shift item end end At this point this is starting to look like the complexity of ::Queue's implementation itself. (Too bad it doesn't do timeouts natively.) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#462 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAEQi9Jcsol7mTQFX599uNQHu7cpLrIks5reNeZgaJpZM4MFnjL> .
-- Staff Software Engineer, Pivotal/RabbitMQ
added a commit
Feb 20, 2017
I can do a release tomorrow if it's been working well for you.…
On 4 Mar 2017, at 02:10, Joseph Wong ***@***.***> wrote: @michaelklishin will a version 2.6.4 be cut with this fix? Thanks for backporting to 2.6.x! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.