[rabbitmq-discuss] Federation and Stomp
Steve Powell
steve at rabbitmq.com
Thu Feb 23 12:50:11 GMT 2012
Patrick,
Sorry to take so long to get back to you.
As you point out, SUBSCRIBE to an exchange destination will create an exclusive,
auto-delete queue for that STOMP session and client, and topic exchanges discard
messages when there is no queue to put the messages in.
What is happening is that the queue NOT created on a SEND, so when there is no
SUBSCRIBEr, there is no queue and so the topic exchange discards the messages.
If you want to retain topic messages after the subscriber disconnects,
then look at the Durable Topic Subscription extension for RabbitMQ STOMP
(see http://www.rabbitmq.com/stomp.html#d.dts).
Hope this helps,
Steve Powell
steve at rabbitmq.com
[wrk: +44-2380-111-528] [mob: +44-7815-838-558]
On 15 Feb 2012, at 15:29, patrickf wrote:
> I am testing RabbitMQ for suitability in a pub/sub application over multi data centre network.
>
> Existing clients are using stomp so we need to stay on stomp if at all possible. I am trying to set up federation with stomp. Federation seems to work fine, in that the log tells me it has federated links to the 2 upstream exchanges that are set up in the .config file. And using amqp I can send to the upstream exchange and have a consumer pick it up off the downstream exchange.
>
> When using stomp with a perl client set, I connect to the upstream exchange with destination /exchange/<exchange name> and get an auto-delete queue. I can configure a consumer client with the same destination and it pulls off the messages fine. The problem is that the consumer must be connected or any messages sent by the producer are lost.
>
> Is there a way to have a non-auto delete queue on the upstream exchange that I can connect to via stomp?
>
> Thanks
> Patrick
> _______________________________________________
> 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