Hi everyone,
I've been watching this discussion unfold and thought I might contribute.
Personally, I have not ran a jabberd2 instance in a long time, but this
question below:
On 13/09/2012, at 11:35 PM, Tomasz Sterna wrote:
> Dnia 2012-09-13, czw o godzinie 15:07 +0200, Alexandre Jousset pisze:
>>
>>> But then - what happens if two resources of the same priority get
>>> connected to two different sm instances?
>>
>> *This* was my real question ;-)
>
> I don't have answer.
>
> Will have to think about it.
>
leads me to believe that they should act like so:
It should be noted this is a hair-brained idea that has no testing or code to
back it up.
1) Lets just say that, for arguments sake, you have an SM instance setup within
the cluster that says:
"I will accept ONLY high-priority resources"
and all the cluster SM instances take note of this.
1) The resources connect and are given the same priority and connected to two
different SM instances (let's say SM-1 and SM-2)
2) SM-1 and SM-2 communicate with the high-priority (HP) SM manager (SM-HP)
when the new resources connect. A simple message might be:
"Hey there, it appears that I have a resource with priority A
(highest). Here it is: (RESOURCE). Bye"
3) SM-HP responds to both SM-1 and SM-2 and informs that:
"Please tell the client to reconnect to ME if possible, with this
token: (A UNIQUE TOKEN).
Otherwise, could you please forward ALL information to me AS SOON AS
you get it. Bye."
4) SM-1 and SM-2 then proceed to inform the resources that:
"There exists a high-priority server at this address: 1.2.3.4 that you
must reconnect to, if possible, using this token: (THE UNIQUE TOKEN)."
5a) Resource-1 (connected to SM-1) supports this and would automatically
reconnect to SM-HP without actually informing the user that they have
'disconnected' - rather it would log that a High-Priority Server exists at this
address and automatically reconnected to it.
5b) Resource-2 (connected to SM-2) does not support this and responds with a
message like:
"Oops, I have no clue what you are on about." (or similar)
to SM-2; this means that SM-2 must now respect SM-HP's request and forward all
traffic/activity to SM-HP WITHOUT interference and with the highest priority.
SM-2 tells SM-HP this is the case and to expect a lot of HP traffic from SM-2,
Resource-2.
--------------
In the event that the SM-HP server (or process) dies, this might happen:
1) All the other SM's in the group may realise this and broadcast to each other
and ask:
"Hey, is there a High-Priority server around here?"
for a duration of 30 seconds (for argument's sake).
2a) If a response from another SM-HP server is given, then all HP
traffic/connections/resources are forwarded (or reconnected) to it.
2b If, at no point, a response is given, each server waits a random time and
then announces that it intends to become a High-Priority server.
3a) All other SM's stop waiting and inform the new SM-HP in-waiting to proceed
and become the new SM-HP server.
3b) If a 'collision' of announcements is detected, then all servers reset their
timers and start again, with the offending servers adding a penalty time to
their countdown period.
I don't know if this would work in practice, but this is one way I see the
issue of the above question being resolved.
-James
