Testing lightweight publisher confirms

[Adam Rabung]

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

[Simon MacMullen-2]

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

[Simon MacMullen-2]

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

[DLB9000]

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.

Dan


_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

[Simon MacMullen-2]

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

[plesniak]

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