[rabbitmq-discuss] STOMP Plugin: Alternative exchange other than amq.topic?
Cliff Redmond
cliff.redmond at gmail.com
Mon Mar 5 17:45:21 GMT 2012
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120305/19f1c44b/attachment.htm>
More information about the rabbitmq-discuss
mailing list