[ejabberd] External Component Load Balancing

Mike Mahoney mmahoney at palantirisystems.com
Wed Jan 27 06:49:00 MSK 2010


Thanks for this info.

I'm still a bit confused about the 'source' domain_balancing option.  If
there were two components and two clients, and componentA sent an IQ to
clientA, I understand that it would get the response.  Would all requests to
clientA have to be routed through componentA now, or could componentB also
send IQs to clientA and be guaranteed to get the response?

Also, when you use domain_balancing_component_number do you specify the
number of components that will be connected?

  Ex: {domain_balancing_component_number, "my.domain.com", 4}.

My components don't store any real session information, they just facilitate
a single request/response, so {domain_balancing, "my.domain.com", source}
will probably be sufficient, even without an external session store.

Thanks again,
Mike

>  -----Original Message-----
>  From: ejabberd-bounces at jabber.ru [mailto:ejabberd-bounces at jabber.ru]
>  On Behalf Of Pedro Melo
>  Sent: Tuesday, January 26, 2010 11:30 AM
>  To: ejabberd at jabber.ru
>  Subject: Re: [ejabberd] External Component Load Balancing
>  
>  Hi,
>  
>  On Tue, Jan 26, 2010 at 4:13 PM, Paul Aurich <paul at darkrain42.org>
>  wrote:
>  > On Jan 26, 2010, at 03:05, Pedro Melo wrote:
>  >> then all stanzas for client with jid X will end-up in the same
>  >> component instance. As long as your query originates in that
>  >> component, the answer will arrive at the proper component. Of
>  course
>  >> if two or more instances of your component die at the same time,
>  the
>  >> order of components might change and all bets are off (my
>  >> understanding of the code 3 years ago, it might have changed by
>  now).
>  >
>  > It's my understanding that the "domain_balancing_component_number"
>  is designed specifically to address this problem with what you
>  described, in that it makes the algorithm stable even if one or more
>  of the components disconnect[s] (of course, this will mean sessions
>  handled by an offline component are just DOWN instead of being handled
>  by a different component).
>  
>  That parameter helps in a lot of cases but it does not guarantee that
>  after two instances die and reconnect at the same time, they will get
>  the same JIDs that they where getting before the disconnect.
>  
>  If you have 5 instances connected, and ejabberd orders them like A B C
>  D E, if B and D die at the same time and reconnect, you could end up
>  as A D C B E.
>  
>  That is enough for most people, because A C and E are unaffected. But
>  you must be aware that B and D can end up in different slots.
>  
>  Again, haven't looked at the current code, but it was like this at the
>  time.
>  
>  Bye,
>  --
>  Pedro Melo
>  http://www.simplicidade.org/
>  xmpp:melo at simplicidade.org
>  mailto:melo at simplicidade.org
>  _______________________________________________
>  ejabberd mailing list
>  ejabberd at jabber.ru
>  http://lists.jabber.ru/mailman/listinfo/ejabberd



More information about the ejabberd mailing list