You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by kristoffer <st...@gmail.com> on 2006/10/19 14:24:20 UTC
Self configuring network of brokers
Hi,
Just got my client to connect to brokers using multicast properly, yea! But
(comparing with a static tcp connection) performance is so much worse when
using discovery:(multicast://default) at the client side. It looks like
(correct me if im wrong) every message sent from the client to the broker,
causing a multicast discovery in order to find a broker. Why is this
behaviour? Is because of loadbalancing? Is there some way that the discovery
could be made only when the connection is broken?
What i want is to have a loadbalanced system which is easy configurable. I
dont want to update all my traffic servers configuration with new tcp urls
if I decide to add a new broker. At the same time i dont want any overhead
of running multicast, except when a connection failure occurs.
Please help me understand if this is feasible or not, if not, what are a
common setup? What are my options in terms of performance vs
ease-of-configuration?
Thank you,
-Kristoffer
--
View this message in context: http://www.nabble.com/Self-configuring-network-of-brokers-tf2473032.html#a6895670
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Self configuring network of brokers
Posted by Hiram Chirino <hi...@hiramchirino.com>.
change all the occurrences of "multicast://default" to
"multicast://default?keepAliveInterval=100000" where the keepAliveInterval
is how often to send a heartbeat out in ms.
On 10/25/06, kristoffer <st...@gmail.com> wrote:
>
>
> Hi,
>
> Ok. Because there were some log statements before doing each send, saying
> somethin that my current broker has been added to the list of brokers?
>
> I browsed through the documentation but i could not find any information
> on
> how to change this heartbeat packets?
>
> regards,
> -Kristoffer
>
>
> Hiram Chirino wrote:
> >
> > On 10/19/06, kristoffer <st...@gmail.com> wrote:
> >>
> >>
> >> Hi,
> >>
> >> Just got my client to connect to brokers using multicast properly, yea!
> >> But
> >> (comparing with a static tcp connection) performance is so much worse
> >> when
> >> using discovery:(multicast://default) at the client side. It looks like
> >> (correct me if im wrong) every message sent from the client to the
> >> broker,
> >> causing a multicast discovery in order to find a broker. Why is this
> >
> >
> > no. but the client is getting every broker heartbeat which defaults to
> > about 1 every 500 ms. So if you have alot of brokers and a slow client
> > connection that could be alot of traffic that the client is getting.
> >
> > behaviour? Is because of loadbalancing? Is there some way that the
> > discovery
> >> could be made only when the connection is broken?
> >>
> >> What i want is to have a loadbalanced system which is easy
> configurable.
> >> I
> >> dont want to update all my traffic servers configuration with new tcp
> >> urls
> >> if I decide to add a new broker. At the same time i dont want any
> >> overhead
> >> of running multicast, except when a connection failure occurs.
> >
> >
> >
> > The overhead of multicast is only that each broker is sending out
> > heartbeat
> > messages. You can change the time interval to make that overhead be
> much
> > less.
> >
> > Please help me understand if this is feasible or not, if not, what are a
> >> common setup? What are my options in terms of performance vs
> >> ease-of-configuration?
> >>
> >> Thank you,
> >> -Kristoffer
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Self-configuring-network-of-brokers-tf2473032.html#a6895670
> >> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> >>
> >>
> >
> >
> > --
> > Regards,
> > Hiram
> >
> > Blog: http://hiramchirino.com
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Self-configuring-network-of-brokers-tf2473032.html#a6988430
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: Self configuring network of brokers
Posted by kristoffer <st...@gmail.com>.
Hi,
Ok. Because there were some log statements before doing each send, saying
somethin that my current broker has been added to the list of brokers?
I browsed through the documentation but i could not find any information on
how to change this heartbeat packets?
regards,
-Kristoffer
Hiram Chirino wrote:
>
> On 10/19/06, kristoffer <st...@gmail.com> wrote:
>>
>>
>> Hi,
>>
>> Just got my client to connect to brokers using multicast properly, yea!
>> But
>> (comparing with a static tcp connection) performance is so much worse
>> when
>> using discovery:(multicast://default) at the client side. It looks like
>> (correct me if im wrong) every message sent from the client to the
>> broker,
>> causing a multicast discovery in order to find a broker. Why is this
>
>
> no. but the client is getting every broker heartbeat which defaults to
> about 1 every 500 ms. So if you have alot of brokers and a slow client
> connection that could be alot of traffic that the client is getting.
>
> behaviour? Is because of loadbalancing? Is there some way that the
> discovery
>> could be made only when the connection is broken?
>>
>> What i want is to have a loadbalanced system which is easy configurable.
>> I
>> dont want to update all my traffic servers configuration with new tcp
>> urls
>> if I decide to add a new broker. At the same time i dont want any
>> overhead
>> of running multicast, except when a connection failure occurs.
>
>
>
> The overhead of multicast is only that each broker is sending out
> heartbeat
> messages. You can change the time interval to make that overhead be much
> less.
>
> Please help me understand if this is feasible or not, if not, what are a
>> common setup? What are my options in terms of performance vs
>> ease-of-configuration?
>>
>> Thank you,
>> -Kristoffer
>> --
>> View this message in context:
>> http://www.nabble.com/Self-configuring-network-of-brokers-tf2473032.html#a6895670
>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>
>>
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
>
--
View this message in context: http://www.nabble.com/Self-configuring-network-of-brokers-tf2473032.html#a6988430
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Self configuring network of brokers
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On 10/19/06, kristoffer <st...@gmail.com> wrote:
>
>
> Hi,
>
> Just got my client to connect to brokers using multicast properly, yea!
> But
> (comparing with a static tcp connection) performance is so much worse when
> using discovery:(multicast://default) at the client side. It looks like
> (correct me if im wrong) every message sent from the client to the broker,
> causing a multicast discovery in order to find a broker. Why is this
no. but the client is getting every broker heartbeat which defaults to
about 1 every 500 ms. So if you have alot of brokers and a slow client
connection that could be alot of traffic that the client is getting.
behaviour? Is because of loadbalancing? Is there some way that the discovery
> could be made only when the connection is broken?
>
> What i want is to have a loadbalanced system which is easy configurable. I
> dont want to update all my traffic servers configuration with new tcp urls
> if I decide to add a new broker. At the same time i dont want any overhead
> of running multicast, except when a connection failure occurs.
The overhead of multicast is only that each broker is sending out heartbeat
messages. You can change the time interval to make that overhead be much
less.
Please help me understand if this is feasible or not, if not, what are a
> common setup? What are my options in terms of performance vs
> ease-of-configuration?
>
> Thank you,
> -Kristoffer
> --
> View this message in context:
> http://www.nabble.com/Self-configuring-network-of-brokers-tf2473032.html#a6895670
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com