You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The ensureIsOpen() was there because a long time ago, we were starting the mainloop before enqueuing the startblocker. The mainloop could exit before the startblocker was enqueued, thus ensureIsOpen() was used to detect and explode should that occur. These days, we enqueue the startblocker before starting the mainloop. The problem was thus if the mainloop exploded really quickly, ensureIsOpen would collect the error, but if the mainloop was a little slower, the error would pop out when inspecting the result of the startblocker. These errors are of different types and were causing the problem seen.
Because we enqueue the startblocker before we start the mainloop, we don't have to worry about the ensureIsOpen - if the mainloop dies, it'll call AMQConnection.shutdown which shutsdown channel0, which finds the current RPC and notifies that - that is the startblocker, so that's how the exception will always get back to the client user thread.
Testing suggests that irregardless of whether the above waffle is correct or not, the problem has vanished.
0 commit comments