[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xmlblaster] xmlBlaster in active/standby

Saju Abraham wrote:

Marcel,

Thanks!  I did try out a small test in fact and the basic concept seems to
work ok.

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.

Regards,
Marcel


Best regards,
Saju


-----Original Message-----
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:



Hi,

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


to


access it. The subsystem process determines which xmlBlaster instance to
use.

My objective of using xmlBlaster is to use it as a messaging infrastructure
between several other heterogeneous subsystems in our application


framework.


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


during


this time.

2) If standby node goes down during this time while the active node is


still


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
second node. 




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.

regards,
Marcel



But I could be missing some major drawbacks here on this approach, and any
insights or suggestions would be extremely helpful!

Thanks in advance,
Saju