[rabbitmq-discuss] STOMP Plugin: Alternative exchange other than amq.topic?

Tue Feb 28 10:02:49 GMT 2012

Hi Cliff,

On the STOMP page, it says that subscribing to an explicit exchange does what
you want. Is there something I've missed?

> Having to create a queue and bind it to an alternatively named
> federated topic exchange using an AMQ client before each Stomp
> subscription significantly reduces the utility of the Stomp plugin (in
> this federated case).

--8<---cut-here------------------------
For SUBSCRIBE frames, a destination of the form /exchange/<name>[/<pattern>] can be used. This destination:

	• creates an exclusive, auto-delete queue on <name> exchange;
	• if <pattern> is supplied, binds the queue to <name> exchange using <pattern>; and
	• registers a subscription against the queue, for the current STOMP session.
---------------------------------------

Steve Powell  (a hippy bunny, man)
----------some more definitions from the SPD----------
vermin (v.) Treating the dachshund for roundworm.
chinchilla (n.) Cooling device for the lower jaw.
socialcast (n.) Someone to whom everyone is speaking but nobody likes.

On 22 Feb 2012, at 12:08, Cliff Redmond wrote:

> (Sending directly because my post is awaiting moderator approval)
> 
> Hi Steve,
> 
> thanks for your answer.
> 
> I'm facing the exact same problem as Ken: I think your solution only
> partially addresses the issue.
> 
> One of the most useful features of the Stomp plugin is that when a
> (Stomp) consumer subscribes to a Stomp topic, it automatically creates
> a new queue (with a lifecycle dictated by the subscription) and binds
> it to the default topic exchange on the relevant host.
> 
> e.g. invoking the following in a consumer:
> 
> $frame = Net::Stomp::Frame->new( {
>      command => "SUBSCRIBE",
>      headers => {
>          destination => "/topic/durable-topic-prefetch",
>          id => $subscriberId,
>          persistent => "true",
>          ack => "client",
>          prefetch_count => 1,
>      },
> });
> 
> $stomp->send_frame($frame);
> 
> will create a queue on the relevant broker:
> 
> sh-3.2# rabbitmqctl list_queues
> Listing queues ...
> [...]
> stomp.dsub.durable-topic-prefetch.?ܛ?R?M?\0006??1>?U	0
> [...]
> ...done.
> 
> and bind it to the default topic exchange:
> 
> Listing bindings ...
> [...]
> amq.topic	exchange	stomp.dsub.durable-topic-prefetch.?ܛ?R?M?\0006??1>?
> U	queue	durable-topic-prefetch	[]
> [...]
> ...done.
> 
> Having to create a queue and bind it to an alternatively named
> federated topic exchange using an AMQ client before each Stomp
> subscription significantly reduces the utility of the Stomp plugin (in
> this federated case).
> 
> My suggestion would be for a change to either of the Stomp or
> Federation plugins:
> 
> - be able to specify a topic exchange to the Stomp plugin (i.e. rather
> than have it always use amq.topic),
> - be able to federate internal/predefined exchanges in the Federation
> plugin.
> 
> With a preference for the former.
> 
> Hope this helps & many thanks,
> 
> Cliff.
> 
> On Feb 21, 6:25 pm, Steve Powell <st... at rabbitmq.com> wrote:
>> Hi Ken,
>> 
>> It is possible for you to SEND to the exchange of your choice from a STOMP
>> application, using a destination of the form: /exchange/<name>/<pattern> (seehttp://www.rabbitmq.com/stomp.html#d.ed) and there is no reason why this
>> shouldn't be a topic exchange of your own making.
>> 
>> If you need to SUBSCRIBE to AMQP destinations you can use the destination
>> /amq/queue/<name> (but the queue must exist).
>> 
>> Between them, these should allow you to use STOMP with federated exchanges
>> without plugin modifications.
>> 
>> Let us know how you get on.
>> 
>> Steve Powell  (a federated bunny)
>> ----------some more definitions from the SPD----------
>> vermin (v.) Treating the dachshund for roundworm.
>> chinchilla (n.) Cooling device for the lower jaw.
>> socialcast (n.) Someone to whom everyone is speaking but nobody likes.
>> 
>> On 20 Feb 2012, at 16:19, Ken Simon wrote:
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> Greetings,
>> 
>>> I'm trying to get federation working (via the rabbitmq_federation
>>> plugin) in our environment of STOMP hosts, and to do so I have to
>>> enable federation in the STOMP plugin's exchange: amq.topic.  This
>>> unfortunately doesn't seem to work because amq.* exchanges are
>>> reserved and cannot be re-declared.
>> 
>>> My solution at this point has been to edit the source of the STOMP
>>> plugin and point it at an exchange called "stomp_topic" (which I made
>>> up, but could be anything) instead of the default amq.topic.  Then I
>>> just configure the federation plugin to work with that exchange and it
>>> works fine.
>> 
>>> My question is, is there a better way of doing this?  I hate
>>> maintaining my own downstream changes to plugins if I don't have to.
>>> The docs say that the STOMP plugin routes all messages through
>>> amq.topic, so it appears that's not configurable.  But wouldn't it
>>> make sense to allow use of an exchange that's not reserved?  Or am I
>>> missing something, and this is actually way easier?  I'm having
>>> trouble finding any documented cases of people using both STOMP and
>>> federation.
>> 
>>> Thanks,
>> 
>>> --
>>> Ken
>>> _______________________________________________
>>> rabbitmq-discuss mailing list
>>> rabbitmq-disc... at lists.rabbitmq.com
>>> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>> 
>> _______________________________________________
>> rabbitmq-discuss mailing list
>> rabbitmq-disc... at lists.rabbitmq.comhttps://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss