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

[Steve Powell]

Cliff,

Did you see my previous answer:
http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2012-February/018456.html
?

Please get back to me if this isn't what you want.

Steve Powell  (a hopeful 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 24 Feb 2012, at 12:43, Cliff Redmond wrote:

> Hi Steve,
> 
> thanks for your answer.
> 
> I was facing the exact same problem as Ken: I think your solution only
> partially addresses the issue - requiring a subscription to a pre-
> existing queue significantly reduces the flexibility of Stomp/
> RabbitMQ.
> 
> One of the most useful features of the Stomp plugin is that when a
> Stomp consumer subscribes to a topic, it automatically creates a new
> queue (with a lifecycle dictated by the subscription) and binds it to
> the default topic exchange on that broker.
> 
> 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.
> 
> Pre-configuring AMQ queues is considerably less flexible, and the
> alternative, creating a queue (and binding it to an alternatively
> named federated topic exchange) using AMQP before each Stomp
> subscription, militates against using Stomp at all.
> 
> Would it be possible to make a change to either of the Stomp or
> Federation plugins:
> 
> - be able to specify a topic exchange in the Stomp plugin config (i.e.
> rather than have it always use amq.topic),
> - be able to federate internal/predefined exchanges in the Federation
> plugin.
> 
> (I used the Shovel plugin to workaround this issue).
> 
> 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 aSTOMP
>> 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 useSTOMPwith 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 getfederationworking (via the rabbitmq_federation
>>> plugin) in our environment ofSTOMPhosts, and to do so I have to
>>> enablefederationin theSTOMPplugin'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 theSTOMP
>>> 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 thefederationplugin 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 theSTOMPplugin 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 bothSTOMPand
>>> 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
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss