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

RE: [xmlblaster] xmlBlaster in active/standby


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?

Best regards,

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

>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 to
>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
>this time.
>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
>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.


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