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

[Elias Levy]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120703/fe2fd86c/attachment.htm>