Testing lightweight publisher confirms

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Testing lightweight publisher confirms

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Testing lightweight publisher confirms

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Testing lightweight publisher confirms

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Testing lightweight publisher confirms

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Testing lightweight publisher confirms

plesniak
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
Loading...