[ejabberd] Components, addressing specific connections

Arne Claassen arne at getorganyzd.com
Thu Dec 11 20:59:29 MSK 2008

Hi Mickaël,

I found that part of the docs yesterday and set up destination  
affinity. I know i'm probably a weird use case, but while destination  
affinity means that a message to my array of component instances will  
always go to the same one once a conversation is started, that  
affinity doesn't seem to be based on the component jid's resource,  
i.e. at the first message that my component receives (even if its a  
reply to a message from my component) one of my component is chosen at  
random, even though after that the affinity sticks to it. But that  
means my component can't start the conversation and make sure it  
receives the replies. I.e. if i have component.foo.com/a and  
component.foo.com/b and /a sends a message to a JID from bar at component.foo.com 
/a the reply randomly arrives at /a or /b

What I have is that for state efficiency my multiple instances of the  
component handle different parts of the roster. And my components  
generally are the ones that start the conversation, so i need a way  
for the reply to come back to to the component that sent the message.

Ideally what I want is that if bob at baz.com talks to foo at component.foo.com 
  he will always talk to the appropriate instance. I'd be fine if the  
bare foo at component.foo.com would be multicast to all component  
instances and then i could reply from the right one and, since i then  
specify a resource, further communication would have its affinity set  
to that resource. Basically, the behavior you get with normal xmpp  
clients. The only reason i am switching from client to component is  
because my roster is getting too large and i want to handle it at the  
bot side. Unfortunately that means i am in some weird land between  
components and clients.

I assume that the available balancing options for components do not  
support this behavior. Being a newbie to erlang (went through Joe's  
book), is this a balancing option that I would write myself as a  
beginner or is the balancing logic advanced erlang foo?


On Dec 11, 2008, at 9:25 AM, Mickaël Rémond wrote:

> Hello Arne,
> It is documented in ejabberd doc: Service Load-Balancing
> http://www.process-one.net/en/ejabberd/guide_en#htoc78
> Le 8 déc. 08 à 18:05, Arne Claassen a écrit :
>> Mickaël,
>> Is there a place where these balancing options and other arguments  
>> are documented, or do i need to go to source code? I googled around  
>> and wasn't able to track anything down. Regarding your twitter  
>> reply on the same subject (i'm sdether), I know it's not an  
>> ejabberd issue, but just that the spec really doesn't say anything  
>> about what the behavior should be, which is why I hoped that  
>> ejabberd's implementation had different config options to deal with  
>> affinity, balancing, etc. and it sounds like it does, i just  
>> haven't figured it out yet.
>> thanks,
>> arne
>> On Dec 8, 2008, at 2:12 AM, Mickaël Rémond wrote:
>>> Hello Arne,
>>> Le 7 déc. 08 à 22:17, Arne Claassen a écrit :
>>>> I've been doing programming against client connections so far and  
>>>> some of my uses are running into issues with rosters, so i  
>>>> thought i'd re-implement as components, but it seems i loose the  
>>>> benefit of routing to a particular connection and can't even  
>>>> broadcast to all connections. Are there configuration options  
>>>> for  ejabberd_service that allow you to defeat round-robin and  
>>>> introduce resource affinity?
>>>> I.e. if one connecton sends a message to client and the client  
>>>> responds, is there a way to make sure the response actually gets  
>>>> back to the originator not the next connection in the round robin  
>>>> pool?
>>> You should look into the balancing option. Several algorithms are  
>>> possible that adds stickiness.
>>> -- 
>>> Mickaël Rémond
>>>  http://www.process-one.net/
>>> _______________________________________________
>>> ejabberd mailing list
>>> ejabberd at jabber.ru
>>> http://lists.jabber.ru/mailman/listinfo/ejabberd
>> _______________________________________________
>> ejabberd mailing list
>> ejabberd at jabber.ru
>> http://lists.jabber.ru/mailman/listinfo/ejabberd
> -- 
> Mickaël Rémond
>  http://www.process-one.net/
> _______________________________________________
> ejabberd mailing list
> ejabberd at jabber.ru
> http://lists.jabber.ru/mailman/listinfo/ejabberd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.jabber.ru/pipermail/ejabberd/attachments/20081211/3091a807/attachment.htm>

More information about the ejabberd mailing list