On 05/12/2007, Marc Zampetti <[EMAIL PROTECTED]> wrote:
>
> James,
>
> AMQ-816 sounds exactly like what I need. Then I could configured all of
> these brokers as basically stand-alone with the consumers connected to a
> sub-set or all of them, depending upon what I need. Do you know if AMQ-816
> is
could load balance across, day, 10
> brokers. Then each 10 broker has a 100-5000 consumers processing
> requests concurrently (depending on how fast/slow it is to process
> messages).
>
> --
> James
> ---
> http://macstrac.blogspot.com/
>
> Open Source Integratio
On 05/12/2007, ttmdev <[EMAIL PROTECTED]> wrote:
>
> Given that Marc's producers will be sending non-persistent messages, wouldn't
> a shared - as opposed to pure - master/slave configuration provide
> redundancy at the broker level and do so w/no extra overhead?
Shared File System & Shared Databa
etty 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:
http://www.nabble.com/Questions-on-Network-of-Brokers-and-high-message-rates-tf4941283s2354.html#a14174704
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
On 05/12/2007, Marc Zampetti <[EMAIL PROTECTED]> wrote:
> James,
>
> Yes, it sounds like the JEDI thing and the partitioning approach is what I
> need. And yes, I'm talking queues for the most part. For the partitioning,
> is that something that AMQ, or are you talking about me having a layer in
>
rvice
>> the relevant consumer farm.
>
> Yeah. I guess it depends on how complex the routing is. It might be
> easier to just have an input queue, then some consumer process (which
> could be hosted inside the broker if need be) to do the routing;
> whether its Camel or
On 05/12/2007, Marc Zampetti <[EMAIL PROTECTED]> wrote:
> James,
>
> You are right about the HA comment I originally made. I was referring to
> fact that I'm not looking for persistent messages. But I am concerned about
> what happens when a broker fails and being able to recover from that
> quickl
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 effic
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 la
nd 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+,
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:
http://www.nabble.com/Questions-on-Network-of-Brokers-and-high-message-rates-tf4941283s2354.html#a14165394
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
quot;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:
http://www.nabble.com/Questions-on-Network-of-Brokers-and-high-message-rates-tf4941283s2354.html#a14161300
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
outing. 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:
http://www.nabble.com/
13 matches
Mail list logo
