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

Steve Powell steve at rabbitmq.com
Tue Mar 6 17:22:07 GMT 2012


Cliff,

Thanks for clarifying your requirements.

Use of an explicit exchange/routing-key on your Producers and Consumers would
seem to solve the problem except for the fact that you want them to be Server
agnostic; i.e. to work on ActiveMQ as well; without modification. (There should
be no need to pre-allocate queues.)

Your configuration setting suggestion sounds reasonable; though it is rather a
coarse control and open to abuse -- if the 'redefined' exchange has different
properties the STOMP protocol might not work as expected.

The federation of existing exchanges looks a better bet to me. I'll talk to
others about this.

Steve Powell  (a happy 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 5 Mar 2012, at 17:45, Cliff Redmond wrote:

> Hi Steve,
> 
> sorry for the delay in my reply: my posts were blocked.
> 
> We were attempting to replace an installation of ActiveMQ with RabbitMQ, with minimal (read: no) producer and consumer code changes.
> 
> Producers and consumers used Stomp, and subscribed to topics using destinations beginning with 'topic':
> 
> /topic/<topicname>
> 
> Your suggestion, to use an explicit exchange name in these destinations, would seem like introducing a RabbitMQ dependency.
> 
> The Stomp plugin interprets subscriptions to topic destinations quite sensibly as far as it goes, but choosing to route via the default topic exchange (amq.topic) prevented us from replicating queues between data centers using the Federation plugin (which doesn't seem to be able to federate inbuilt exchanges). We eventually got it working using Shovel, though.
> 
> As I suggested before, there are two possible solutions here:
> - 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'd say the former would be easier to implement - perhaps you could talk to your colleagues working on the Stomp plugin?
> 
> Regards and thanks,
> 
> Cliff.
> 
> On Monday, 5 March 2012 16:22:05 UTC, Steve Powell wrote:
> 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
> 
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://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



More information about the rabbitmq-discuss mailing list