How can a Stomp 1.2 client subscribe to a temporary destination with ack mode "client"?

[mic...@mikejustin.com]

With RabbitMQ 3.6.5, sending a SUBSCRIBE frame for a temporary destination fails with an error like

Invalid destination '/temp-queue/tmp-0' is not a valid destination for 'SUBSCRIBE'

As a workaround, my client does not send a SUBSCRIBE frame at all. The RabbitMQ broker does not complain and delivers messages to the temporary queue, so the consumer receives them.


However, as the client does not send a SUBSCRIBE frame, there is no place where the ACK header can be added. I assume that the broker always auto-acks messages sent to a temporary queues.

Is there a way to use message acknowledgement for messages from Stomp temporary queues, or is auto-ack the only supported mode?

Regards
Michael Justin

[mic...@mikejustin.com]

I opened the case https://github.com/rabbitmq/rabbitmq-stomp/issues/95

As per RabbitMQ docs, the internal subscription for a temporary queue uses auto-ack mode. With auto-ack, messages are treated as acknowledged as soon as they sent. Is there a way to minimize the risk of message loss for unprocessed messages?

[Michael Klishin]

Use non-temporary queues. Automatic acknowledgement mode intentionally trades off
safety for throughput and less work on the consumer end. 

On 22 October 2016 at 12:21:10, mic...@mikejustin.com (mic...@mikejustin.com) wrote:
> I opened the case https://github.com/rabbitmq/rabbitmq-stomp/issues/95
>
> As per RabbitMQ docs, the internal subscription for a temporary queue uses
> auto-ack mode. With auto-ack, messages are treated as acknowledged as soon
> as they sent. Is there a way to minimize the risk of message loss for
> unprocessed messages?
>
> Am Donnerstag, 20. Oktober 2016 19:52:58 UTC+2 schrieb
> mic...@mikejustin.com:
> >
> > With RabbitMQ 3.6.5, sending a SUBSCRIBE frame for a temporary destination
> > fails with an error like
> >

> > *Invalid destination '/temp-queue/tmp-0' is not a valid destination for
> > 'SUBSCRIBE'*

> >
> > As a workaround, my client does not send a SUBSCRIBE frame at all. The
> > RabbitMQ broker does not complain and delivers messages to the temporary
> > queue, so the consumer receives them.
> >
> >
> > However, as the client does not send a SUBSCRIBE frame, there is no place
> > where the ACK header can be added. I assume that the broker always
> > auto-acks messages sent to a temporary queues.
> >
> > Is there a way to use message acknowledgement for messages from Stomp
> > temporary queues, or is auto-ack the only supported mode?
> >
> > Regards
> > Michael Justin
> >
>

> --
> 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 an email to rabbitm...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

--
MK

Staff Software Engineer, Pivotal/RabbitMQ

[Michael Klishin]

More specifically, there are two pretty clear cut scenarios that several

messaging protocols cover (some with more flexibility, some with less):

 * Transient state that can or should be discarded/lost when a client fails

 * Non-transient state

AMQP 0-9-1 provides a fair amount of flexibility around this and the STOMP plugin exposes

it via different endpoint types. But your flexibility for in between cases is limited with STOMP

and there is no middle ground with MQTT.

Either switch to AMQP 0-9-1 and use the exact queue properties you want or pick your poison.

> To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-users+unsubscribe@googlegroups.com.
> To post to this group, send an email to rabbitmq-users@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.
>

--
MK

Staff Software Engineer, Pivotal/RabbitMQ