[rabbitmq-discuss] Feedback on STOMP changes

[Steve Powell]

May I point out to readers of this thread that the changes described by Rob's note apply only to queues.
The present case (where we create a queue on SEND) is where the destination is of the form /queue/*.

So the proposal will not affect topic pubSub applications, but only point-to-point queue SEND/SUBSCRIBEs.

It is pertinent that if a publisher sends to a topic for which there are no subscribers, then the message is discarded anyway; so the negative case here is only for SEND before SUBSCRIBE to a specific queue. If that queue was created (and not deleted) beforehand, then all would be well.

If we continue to create queues on SENDs to non-existent queue destinations, then we have the knotty problem of what properties those queues should have. Leaving this problem to the SUBSCRIBER seems to be natural and predictable as well as having the advantages outlined in Rob's note.

We anticipate a STOMP requirement to create a queue (which might be durable, shared, etc) explicitly, just in case some non-subscriber (e.g. a SENDer ?) needs to ensure it exists.  This would probably be a non-standard frame command added to our STOMP support, but it could be done, with our proposed changes, by SUBSCRIBE-ing with the appropriate properties, and then UNSUBSCRIBE-ing immediately afterwards.  If the queue was NOT auto-deleted then subsequent SENDs could operate successfully.

No-one seems to have  reacted to the throughput performance advantages of the proposal, which might be considerable.

Steve Powell  (a happy bunny)
----------some definitions from the SPD----------
Rigatoni n. A prime-ministerial grin.
Nigella n. The next bottle-size up from a Nebuchadnezzar.
Homily adv. Rather like a frenchman.

On 25 Jun 2011, at 11:43, Michael Justin wrote:

> Am 24.06.2011 15:33, Rob Harrop wrote:
> 
>> We'll add support for durable, exclusive, auto-delete and everything
>> else as headers on the SUBSCRIBE frame.
> 
> The Stomp+JMS bindings page http://stomp.codehaus.org/Stomp+JMS has a implementation recommendation for durable subscribers (more ore less implemented in this way in other brokers):
> 
> quote:
> "
> If you wish to create a durable topic subscriber you will need to do the following
> 
> *    set the client-id header on the CONNECT to a globally unique String for the Stomp connection
> *    set the durable-subscriber-name header on the SUBSCRIBE command.
> 
> The combination of the client-id and durable-subscriber-name uniquely identifies the durable topic subscription. i.e. after you restart your program and re-subscribe, the Broker will know which messages you need that were published while you were away"
> 
> 
> For compatibility of Stomp client implementations, RabbitMQ could implement it following this specification.
> 
> Regards,
> Michael Justin
> 
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110630/1ead428c/attachment.htm>