[rabbitmq-discuss] RabbitMQ stomp-adapter behaviour

[Matthias Radestock]

Gavin,

Gavin M. Roy wrote:
> I change this auto-delete = false in the code before compilation to
> mirror ActiveMQ behavior.
> [...]
> the biggest issue I had to overcome was the concept that one has to
> subscribe to a queue in order to set the default behavior for it.

>From your and other peoples' comments I gather that with the default
behaviour it should be possible to SEND messages to a destination even
when there are no (and never have been any) subscribers for that
destination. The messages should be queued and delivered to future
clients when they subsequently SUBSCRIBE to that destination.

Correct?

If so then the challenge we face in implementing that behaviour on top
of AMQP is that the only place messages get stored in AMQP is in queues,
and that these queues need to be created explicitly and, with the
exception of exclusive and auto-delete queues, destroyed explicitly.

Currently the STOMP adapter only declares queues on SUBSCRIBE. We could
change it so it also declares them on SEND. AMQP's queue.declare is
idempotent, so this should work fine but there is a performance penalty.

With that change in place messages will get queued w/o the need to have
a subscription first.

Now, declaring queues implicitly on SEND and SUBSCRIBE is all very well,
but how & when do we get rid of them? Setting "auto-delete = false" has
the unfortunate side effect of the queues sticking around forever, even
when they have no messages or subscribers. That does not matter much if
there are a finite and small(ish) number of possible destinations. But
when there are many destinations, only some of which are in use at any
given time, then server resources can be exhausted.

I can think of various approaches to address this problem, but none are
very pleasant.


Matthias.