Hello,
I am trying to test an implementation that uses lightweight publisher confirms, and I'm wondering how to create conditions for causing handleNack on my ConfirmListener to be called. Unrouted messages go to the ReturnListener. Killing the server pretty much immediately kills the underlying Connection/Channel. I think I am just lacking creativity today: does anyone have advice on how to simulate server hiccups? Secondly, what are the most common causes of ConfirmListener.handleNack being called, since server connectivity problems seem to immediately kill the channel? Thank you, Adam _______________________________________________ rabbitmq-discuss mailing list [hidden email] https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss |
On 01/12/11 14:25, Adam Rabung wrote:
> Secondly, what are the most common causes of > ConfirmListener.handleNack being called, since server connectivity > problems seem to immediately kill the channel? An individual queue process crashing within RabbitMQ. That's the only thing that can do it. Obviously this makes it rather difficult to test. I'm not *entirely* sure I want to introduce "rabbitmqctl crash_queue <queuename>", but maybe it's needed... Cheers, Simon -- Simon MacMullen RabbitMQ, VMware _______________________________________________ rabbitmq-discuss mailing list [hidden email] https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss |
On 01/12/11 14:29, Simon MacMullen wrote:
> On 01/12/11 14:25, Adam Rabung wrote: >> Secondly, what are the most common causes of >> ConfirmListener.handleNack being called, since server connectivity >> problems seem to immediately kill the channel? > > An individual queue process crashing within RabbitMQ. That's the only > thing that can do it. Obviously this makes it rather difficult to test. Ah, hang on. One way to "crash" a queue is to have it running on a single node in a cluster and take that node down. So: 1) Create a two node cluster, node1 and node2. 2) Create a non-mirrored queue on node1. 3) Start a publisher using confirms on node2, publishing to that queue. 4) Stop node1. You should see nacks then I think. Cheers, Simon -- Simon MacMullen RabbitMQ, VMware _______________________________________________ rabbitmq-discuss mailing list [hidden email] https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss |
On Thursday, December 1, 2011 9:42:39 AM UTC-5, Simon MacMullen wrote: > Ah, hang on. One way to "crash" a queue is to have it running on a > 1) Create a two node cluster, node1 and node2. > You should see nacks then I think. Tried this, but was still unable to generate a NACK. Dan _______________________________________________ rabbitmq-discuss mailing list [hidden email] https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss |
On 05/02/13 17:55, DLB9000 wrote:
> On Thursday, December 1, 2011 9:42:39 AM UTC-5, Simon MacMullen wrote: > > > Ah, hang on. One way to "crash" a queue is to have it running on a > > single node in a cluster and take that node down. So: > > > 1) Create a two node cluster, node1 and node2. > > 2) Create a non-mirrored queue on node1. > > 3) Start a publisher using confirms on node2, publishing to that queue. > > 4) Stop node1. > > > You should see nacks then I think. > > > Tried this, but was still unable to generate a NACK. Yes, sorry, my previous suggestion doesn't work. We only generate nacks for queues that have died unexpectedly. So you need to actually kill a queue. This is in general meant to be hard :-), but with "rabbitmqctl eval" you can do anything: $ rabbitmqctl eval '{ok, Q} = rabbit_amqqueue:lookup(rabbit_misc:r(<<"/">>, queue, <<"test">>)), [{pid, Pid}] = rabbit_amqqueue:info(Q, [pid]), exit(Pid, bang).' The above command kills the queue "test" in the virtual host "/". I've just tested this, and it does indeed cause nacks to be sent. Cheers, Simon -- Simon MacMullen RabbitMQ, VMware _______________________________________________ rabbitmq-discuss mailing list [hidden email] https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss |
This post has NOT been accepted by the mailing list yet.
Hi,
We're trying to reproduce case that you described, but we can't get any NACKs. We tried it on single node, and on cluster with queue on one node being killed. After invoking this command several times we get our queue in 'crashed' state but even if we keep publishing to messages to it they are always ACKed (after queue crash messages are not longer routed to it but still we haven't notice any NACK). Is this case still valid on rabbitmq version 3.5.1? What exactly should be our cluster setup to make this scenario work? Thanks, Piotr Lesniak |
Free forum by Nabble | Edit this page |