Re: [xmlblaster] HA possible using session & subscription persistence?

[Marcel Ruff <mr at marcelruff.info>]

Saju Abraham wrote:

> Hi,
>
> I had a few questions again on clustering/HA of xmlBlaster:
>
> 1) I wanted to know whether a HA setup could be achieved using the session
> and subscription persistence features.  I'll be having two xmlBlaster nodes
> that would be managed by HA software and the client would connect to only
> one of the nodes using a virtual IP address.  Sessions and subscriptions
> would be stored in Oracle.  When the active node goes down, we would start
> up the second node, but can the second node can pick up the persistent data
> of the 1st node from the DB and load all the sessions and subscriptions?
> I'm thinking there should be some common key or identifier for the
> persistent data so both nodes would use the same data, perhaps something
> like node id?  From the client perspective, it would be entirely transparent
> as they would only be connecting to the virtual IP address.
>  
Smart idea! From a first glance i think this could work, just try it.
As all persistent informations (like subscriptions and messages) are 
there on startup
of the backup xmlBlaster node no information will be lost even if 
clients reconnect
after failover with longer delays.

If you, for example, start xmlBlaster (on both nodes) like:
 
  java org.xmlBlaster.Main -cluster.node.id heron

  java javaclients.HelloWorldSubscribe -persistentSubscribe true
 
and check the XB_ENTRIES table in Oracle you will see the 'queueName' 
entries like:

 "topicStore_heron"
 "session_heronsubPersistence"
 "subscribe_heronsubPersistence"

and they are neutral to any physical host instance.
You probably have to STONITH the other node to avoid simultaneous running
xmlBlasters (but this is your HA setup doing anyhow).

Note: If you need to optimize xmlBlaster startup time you can usually
optimize it from normal startup of ~3 sec down to ~100 milli seconds.
You would need to have the standby xmlBlaster running in runlevel 3
(using command line option -runlevel 3)
and on activation fire it up to runlevel 9.
Change in xmlBlasterPlugins.xml to startup/shutdown the SOCKET
protocol plugin (if you for example use SOCKET) to runlevel 4
to find the new virtual addres.
Further remove all not needed protocols and other services (like telnet 
etc.).
To control the runlevels from outside you could consider using a
little JMX application, telnet or a fast C client (with an 
administrative SOCKET
protocol plugin in runlevel 2).

> 2) If suppose I wanted to implement mirroring of session and subscription
> info across nodes (which is being extremely optimistic :-) ), which would be
> a good place to start looking into (package, file, etc.)
>  
The best approach needs to be discussed, her some first ideas:
- Solve the initial replication when an additional node comes up
- Sending those info as normal messages to other cluster nodes
  where sync and async (with queueing) approaches can make sense
  depending on the use cases
  syn: The network must be very reliable as any error would block all 
sync'd nodes
  async: Loosely coupled nodes which can be down temporary as the 
messages are queued
- Or: mirroring the backend database table XB_ENTRIES (many issues to 
solve here)

As xmlBlaster has all communication, subscribing and queueing issues in 
its heart
the implementation should be straight forward, once we have found the 
concept.

> 3) For persistence of session and subscription info, if I wanted to use the
> JBoss distributed cache instead of a DB, I assume I need to create my own
> persistence plugin which would be an implementation of I_Map?
>  
I_Map and I_Queue.
Has JBoss distributed cache a JDBC interface?
If yes, it is simple, probably a configuration issue only.
If no, you need to implement the persistence part of I_Queue and I_Map.
Note that the RAM and CACHE implementations of I_Queue and I_Map
will still work no matter how your persistence plugin is working.

Enjoy,
Marcel

> Many thanks in advance!
>
> Kind regards,
> Saju
>
>
>
>
>