activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ttmdev <>
Subject Re: Questions on Network of Brokers and high message rates
Date Tue, 04 Dec 2007 22:44:19 GMT

Re the second part of your post. If Camel is not an option, then what about a
composite queue in combination with selectors?  For example, in the snippet
below, Q.FOO gets a subset of the message stream being sent to Q.BLAST,
while Q.BAR gets the entire stream.  

<compositeQueue name="Q.BLAST">
              <filteredDestination selector=”color=’blue’” queue="Q.FOO" />
              <queue physicalName="Q.BAR" />              

Hope this helps - Joe

Marc Zampetti wrote:
> All,
> I'm considering ActiveMQ for an application that has very high message
> rates expected, at the rate of 6 - 10 million messages per minute. All of
> these messages are fairly small, on the order of 100 bytes or less, but
> they will be very regular, with a a large burst of additional messages
> (around 20 million extra) once an hour. Obviously, I'm looking at a fairly
> large Network of Brokers. I don't expect, nor do I need persistent
> messages on disk, nor do I want guaranteed delivery, though it would be
> nice. :-) Does anyone have any idea if this is even possible with AMQ? 
> There are a few portions of the applications that need to receive a subset
> of the message stream, and other portions that will simply process the
> entire stream. For those components that need to get a sub-set, I need to
> have some way to route the appropriate messages to the components. While
> still only a subset, this could still be 1 million+ messages per minute,
> and I'm looking for an efficient way to decide when to route a message or
> not. Each of these 6 million messages are unique, with a unique
> identifier, so I would need to have an id to queue mapping table in order
> to perform the routing. At 1 million+, my concern is that the table itself
> can get pretty large, and that some of the more "normal" routing things
> that Camel might help with won't be that helpful.
> Anyone have any ideas or best practices?
> Marc 

View this message in context:
Sent from the ActiveMQ - User mailing list archive at

View raw message