[rabbitmq-discuss] RabbitMQ very slow (or never) shuts down
mpietrek at skytap.com
Mon Dec 10 19:00:13 GMT 2012
Quick follow up on this - Was this bug fix implemented in 2.8.7 or
something later, i.e. 3.0?
I think I'm running into this again when shutting down a set of
bi-directionally federated brokers. It appears when a broker shuts down, it
wants to reach over to the other broker to clean up something (federation
If the other broker has already shut down, the currently shutting-down
broker will stall for a very long time (e.g. 15 minutes or more.)
On Fri, Oct 5, 2012 at 1:33 PM, Tim Watson <tim at rabbitmq.com> wrote:
> Quick update for you Matt. I was able to fully reproduce the behaviour you
> saw by dropping certain packets sent from the downstream federation client
> to the upstream broker during connection.close. We filed a bug and have
> implemented a fix, which should appear in a forthcoming release!
> On 19 Sep 2012, at 22:17, Tim Watson wrote:
> > Hi Matt
> > On 19 Sep 2012, at 20:21, Matt Pietrek wrote:
> >> Excellent. Thanks for the update. I really do appreciate it.
> >> Just for my own curiosity, do you have any sort of local repro, or are
> you still just trying to make sense of my logs?
> > Very much the latter at the moment. We've filed a bug to investigate and
> I'm going to apply some specific packet filtering during shutdown to see
> what kind of impact a lost FIN/SYN might make. I'm also going to be
> reviewing the supervision hierarchy in the erlang client (which federation
> uses) to see if there's and shutdown/timeout choices that aren't quite
> > _______________________________________________
> > rabbitmq-discuss mailing list
> > rabbitmq-discuss at lists.rabbitmq.com
> > https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rabbitmq-discuss