[rabbitmq-discuss] STOMP plug-in, HA queues, and consumer cancelations

[Steve Powell]

> And therein lies the problem.


Yes, I agree.  All good points, well argued.
I've raised a bug (25045) to address this problem.

Steve Powell  (a happy bunny)
----------yet more definitions from the SPD----------
corrugate (n.) T.V. soap scandal.
olympic (n.) A camp road-digger.
jamboree (n.) A conserve made from French cheese.

On 3 Jul 2012, at 18:52, Elias Levy wrote:

> On Tue, Jul 3, 2012 at 9:06 AM, Steve Powell <steve at rabbitmq.com> wrote:
> You are quite right. Your understanding of HA queues is better than
> mine. However, AFAICS the STOMP adapter doesn't present
> the consumer_cancel_notify capability to the (Erlang) connection, so
> will not receive a notification when the consumer is cancelled.
> 
> The STOMP client will think that the subscription is sound even if the
> underlying consumer was cancelled. We can probably do better than this.
> 
> And therein lies the problem.
>  
> Although the STOMP client will stop receiving messages, I would not
> characterise this as 'dangerous', merely frustrating.
> 
> Maybe not dangerous, since there is no data loss, but certainly a lot worse than frustrating.  If you have long lived STOMP connections with consumers which suddenly stop receiving messages without any warning, depending on the importance of those messages and the processes that consume them, the loss of the subscription can be quite important from a business perspective.
> 
> E.g. if those messages are being used to monitor some business activity, you are now flying blind until the STOMP connection is torn down and reestablished.
> 
> Can you say what you think the correct STOMP behaviour ought to be if a
> subscription's consumer is unilaterally cancelled? I'm tempted to simply
> send an ERROR frame and simulate an UNSUBSCRIBE,
> leaving the STOMP client to recover however it thinks fit.
> 
> To resubscribe to the HA queues, obviously.  The HA queue consumer cancelation is a rather ugly implementation detail.  In an ideal world, a HA queue would behave just like a non-HA queue.  From a consumer perspective whether a queue is HA or non-HA would be invisible.  A HA queue would failover without consumers attached to the non-failing nodes noticing. Alas, this is not the case, and I understand why that is given the existing implementation.
> 
> So ideally the STOMP proxy would resubscribe when it receives a consumer cancelation.  Any messages that consumers received that had not yet been acked or for which acks where lost in flight wil be requeued and retransmitted by the new queue master.  I believe thats OK.  RMQ and AMQP already have an expectation that some messages may be delivered more than once as it does not have a two-phase commit for acknowledgements, so clients should already be ready for this eventuality.
> 
> But even sending an ERROR frame to the client to it knowns something went wrong and giving it an opportunity to recover is much better than the situation as it is right now.
> 
> Elias Levy