Testing Negative Acknowledgements when using Publisher Confirms

[Aylin Koroglu]

Dear All,

I'm using Publisher Confirms with RabbitMQ. I would like to test my code, where I'm handling the unacked messages (handleNack method). 

How can I create the scenario to receive Nacks from the broker? Stopping the broker or publishing the messages to a queue which has reached its limits, does not help at all..

Thanks in advance..

ch.setConfirmListener(new ConfirmListener() {

    public void handleAck(long seqNo, boolean multiple) {

        if (multiple) {

            unconfirmedSet.headSet(seqNo+1).clear();

        } else {

            unconfirmedSet.remove(seqNo);

        }

    }

    public void handleNack(long seqNo, boolean multiple) {

        // handle the lost messages somehow

    }

}

[Michael Klishin]

Killing queue process with rabbitmqctl is perhaps the easiest option.

MK

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To post to this group, send email to rabbitm...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Aylin Koroglu]

How can I do that ? 

And even if I kill the queue process, the message will still be delivered to the exchange and I will receive Ack again from the broker. 

I would like to receive Nack from the broker..

10 Mayıs 2015 Pazar 18:57:27 UTC+3 tarihinde Michael Klishin yazdı:

[Michael Klishin]

On 10 May 2015 at 19:21:32, Aylin Koroglu (aylin....@gmail.com) wrote:
> How can I do that ?

rabbitmqctl eval '{ok, Q} = rabbit_amqqueue:lookup({resource, <<"/">>, queue, <<"delete-me">>}), Pid = erlang:element(7, Q), exit(Pid, please_crash).'

> And even if I kill the queue process, the message will still be
> delivered to the exchange and I will receive Ack again from the
> broker.

Exchanges deliver messages to queues, not the other way around.

From http://www.rabbitmq.com/confirms.html:

«For routable messages, the basic.ack is sent when a message has been accepted by all the queues.»

If a queue process terminates under a constant stream of messages
and has to be re-started (which happens very quickly but
still not immediately), you should get a nack. 
--
MK

Staff Software Engineer, Pivotal/RabbitMQ

[Aylin Koroglu]

Thanks a lot MK.

I've executed the following command:

/apps/rmq/sbin/rabbitmqctl eval '{ok, Q} = rabbit_amqqueue:lookup({resource, <<"/">>, queue, <<"DETECT.QUEUE2">>}), Pid = erlang:element(7, Q), exit(Pid, please_crash).'

And I'm getting the following error:

Error: {{badmatch,{error,not_found}},[{erl_eval,expr,3,[]}]}

Is it trying to say that the queue was not found? But I'm sure that the queue exists.

10 Mayıs 2015 Pazar 22:43:44 UTC+3 tarihinde Michael Klishin yazdı:

[Michael Klishin]

Is you queue in the default / vhost?

MK

[Aylin Koroglu]

You're right. My queue is not in the default vhost. Once I changed the default vhost, to the vhost of my queue, the result of the command was true. Does it mean that, it worked correctly ? How can I double check that?

In addition to these, is there any manuel which explains the meaning of the command/commands you suggested ?

Thanks in advance..

11 Mayıs 2015 Pazartesi 10:13:36 UTC+3 tarihinde Michael Klishin yazdı:

[Aylin Koroglu]

By the way, I'm still receiving Acknowledgment from the broker, once I try to publish to the queue.

Either the command didn't work correctly or it worked correctly but killing the queue process is not enough to get Nack from the broker..


11 Mayıs 2015 Pazartesi 10:23:26 UTC+3 tarihinde Aylin Koroglu yazdı:

[Michael Klishin]

It looks up queue process id and terminates it, there will be a crash report in the SASL log.

MK

[Michael Klishin]

As I've said earlier, you need to do it under a constant stream of messages, possibly a few times. The process will be restarted in a fraction of a second.

MK

[Aylin Koroglu]

Yes, that really worked, thanks a lot!


11 Mayıs 2015 Pazartesi 11:57:20 UTC+3 tarihinde Michael Klishin yazdı: