[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster] xmlBlaster in active/standby
Saju Abraham wrote:
Thanks! I did try out a small test in fact and the basic concept seems to
Just for information sake, do you have an idea when the mirroring of session
information across multiple master nodes would be implemented?
Usually it depends on the priority of other tasks we have
or if somebody codes it herself and donates it.
As we need to make a living as well, commercial extensions
have priority. In the moment nobody has ordered it so it may
take some time.
From: owner-xmlblaster at server.xmlBlaster.org
[mailto:owner-xmlblaster at server.xmlBlaster.org] On Behalf Of Marcel Ruff
Sent: Monday, October 24, 2005 1:49 PM
To: xmlblaster at server.xmlBlaster.org
Subject: Re: [xmlblaster] xmlBlaster in active/standby
Saju Abraham wrote:
I'd like to implement xmlBlaster in an HA setup, with two xmlBlaster
instances on two separate nodes acting in a active/standby approach. The
two nodes would be implemented as a single subsystem, and a vitrual IP
address is assigned to the subsystem for subscriber and publisher clients
access it. The subsystem process determines which xmlBlaster instance toframework.
My objective of using xmlBlaster is to use it as a messaging infrastructure
between several other heterogeneous subsystems in our application
And the existing subsystems are also deployed on several nodes for HA.
I'm kind of new to xmlBlaster, and my understanding is that automatic
switchover of a slave node to master and the mirroring of master nodes is
not supported yet. So my implementation would be something like this:
1) By default, all subscribe and publish sessions would be sent to the
active node. All messages are volatile. Connections will register a
ConnectionStateListener for fail safe handling. Standby node is idle
2) If standby node goes down during this time while the active node is
up, no problem.
3) If active node goes down, all existing sessions should be resestablished
at the standby node. This will be known when a notification comes to the
ConnectionStateListener. The standby node now becomes the active node, and
when the previously-active node comes up, it becomes the standby node.
Since all sessions at any point of time will only be directed towards one
node, and since messages are volatile (i.e. no messages in the queue), I
don't think that we need to have the two nodes as master & slave, we just
have to ensure that existing client connections are reestablished on the
Yes, this should work well as the xmlBlaster server is stateless.
Assure in a small test that your HA switching works as expected, the clients
may not 'hang' in a stale socket connection to the previous node.
But I could be missing some major drawbacks here on this approach, and any
insights or suggestions would be extremely helpful!
Thanks in advance,