activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hervé BARRAULT <herve.barra...@gmail.com>
Subject Re: Multicast and ActiveMQ
Date Tue, 14 Feb 2012 09:05:58 GMT
Hi thanks for the answer.

I thought using queues (with vm protocol) and with your argument on
scalability confirms it.

Regards
Hervé

On Mon, Feb 13, 2012 at 11:01 PM, Matt Pavlovich <mattrpav@gmail.com> wrote:

> I recommend using Queues, since Durable Subscriptions can't scale on the
> consumer side (JMS spec only allows for one connection per subscriptionId).
>
> Another option would be to use a Camel route to help filter the messages
> based on your selector, so you only get messages into queues as needed.
>  This would help cut down on the wasted messages problem.  Also, if you run
> the Camel route in the same Java VM as ActiveMQ, you can use ActiveMQ's
> vm:// transport for super fast processing by the Camel route.
>
> Producer -> General.Q  -> Camel route (content based router) -> QueueA,
> QueueB, QueueC
>
> ActiveMQ does have another feature called Virtual Destinations, but I
> don't recommend using them, except in certain situations, and this isn't
> one of them.  The advantage of the Camel route is that you can start/stop
> it without having to start/stop the broker, as well as having more
> flexibility available to you in the routing rules.
>
> Hope this helps!
> Matt Pavlovich
>
>
> On 2/13/12 6:58 AM, Hervé BARRAULT wrote:
>
>> Hi,
>> is there no advice to send a message to multiple consumers using activeMQ
>> ?
>>
>> Regards
>> Hervé
>>
>> On 2/2/12, Hervé BARRAULT<herve.barrault@gmail.**com<herve.barrault@gmail.com>>
>>  wrote:
>>
>>> Hi,
>>> I would multicast messages to different (dynamically determined)
>>> consumers.
>>>
>>> I'm asking myself if it is more efficient to use multiple queues or use a
>>> topic with durable subscription and selectors (I am using persistence).
>>> I would say topics reduce the number of persisted messages but i am
>>> afraid
>>> that one consumer can influence other consumers (if some clients are
>>> slower
>>> than other).
>>>
>>> I have already seen that topic could have some problems in case of
>>> failover
>>> with the subscriptions.
>>>
>>> What is the best way to accomplish this behavior ?
>>>
>>> Regards
>>> Hervé
>>>
>>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message