[rabbitmq-discuss] A different Processing error in logs

[Toby Corkindale]

On 07/12/11 23:27, Steve Powell wrote:
> Dear Toby,
>
> Thank you for that description. I will attempt to reproduce this locally.  At
> first glance it appears that the reception of messages after UNSUBSCRIBE is
> counter-intuitive, and the interference with the second queue sounds suspicious.
>
> Could we see some of your code, please, or could you break this down into a
> series of STOMP frames, so we can see what the parameters are?  A trace of the
> STOMP frames would be best of all.

I've created a stand-alone script that demonstrates the issue occurring; 
it's in Perl, I hope that's OK?
(Edit: Two scripts containing two variants)

> Some questions:
>
> Are the subscriber and sender the same process?

In this demo, I'm subscribing to the queues, then sending a few messages 
to them, then waiting for frames to arrive -- all in the same script. 
However the original issue occurred with a script starting up and 
listening to queues that then received a few messages from another process.

> Can you say exactly what type of queue you create/subscribe to?

The demo is using STOMP queues, "/queue/test1" and "/queue/test2" - so 
fairly ordinary ones.

> In 2) is it necessary to SEND more than 2 messages?

Nah, seems like I can break it with two messages to a single queue even!
1) send to queue
2) send to queue
3) receive from queue, send ack, unsubscribe from queue
4) receive from queue (despite unsub), send ack -- crash

> In 3) how do you manage the connection when you stop reading it to unsubscribe?

In the real world code, it's a shared connection with several 
subscriptions - i'm only subscribing from a single one, so the 
connection stays open.

> Do you need to unsubscribe before ack to get the problem in 6?

Hmm, just checked, and I'm calling the ack *before* the unsubscribe.

> In 6) is the SEND from the same process again?

Doesn't seem to matter.


> If possible, a failing code sample would be helpful.


Two code samples are attached.
"minimal_demo.pl" seems to contain the bare minimum to cause the 
processing error to occur.

The other script is a bit more involved and closer resembles the 
original problem description - it also allows you to play around with 
options and message ordering a bit more.


PS. Despite all the messages I seem to send through to the list about 
one issue or another, I must say that I'm impressed with RabbitMQ, and 
that's it's working nicely with a couple of applications here.

We've learnt to use STOMP /topic/ queues with unique routing keys, 
rather than temp-queues, at least for the time being.
Also we create queues using the management JSON API and then use 
/amq/queue/ queues for certain queues that need more options than STOMP 
allows you to set.

Thanks again,
Toby


> One of the trials I would perform is to try sending on queue 2 after every
> interaction with queue 1.  Of course, that may make it necessary to field
> messages from the second subscription at the same time.
>
> I'll keep you informed about my progress.
>
> Steve Powell  (a working bunny)
> ----------some more definitions from the SPD----------
> avoirdupois (phr.) 'Would you like peas with that?'
> distribute (v.) To denigrate an award ceremony.
> definite (phr.) 'It's hard of hearing, I think.'
> modest (n.) The most mod.
>
> On 7 Dec 2011, at 01:32, Toby Corkindale wrote:
>> This feels like a RabbitMQ or STOMP bug to me, but here's some more info on
>> what causes it to occur so you can decide.
>>
>> 1) Create two queues, with ack=client, subscribe to both, using STOMP.
>> 2) Dump a bunch of messages into first queue.
>> 3) Upon receiving one message, unsubscribe from the first queue only, and
>>     then ack the message.
>> 4) Note that you still get delivered some more messages from that first
>>     queue.
>> 5) Attempt to send a client ACK back for one of these messages, which seems
>>     to work fine.
>> 6) Now attempt to send another message through on the second
>>     (still-subscribed) queue -- rabbitmq generates the Processing Error.
>>


-- 
.signature
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minimal_demo.pl
Type: application/x-perl
Size: 1214 bytes
Desc: not available
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20111208/c1a2de16/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: more_involved_demo.pl
Type: application/x-perl
Size: 1953 bytes
Desc: not available
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20111208/c1a2de16/attachment-0001.bin>