Does implicit clustering work with master-slave configuration?

• Product Name: VisiBroker for Java
• Product Version: 5.2.1 & above
• Product Component: Naming Service
• Platform/OS Version: ALL

Resolution

Following is an example name service property file used to set up both implicit clustering (IC) and master-slave (MS) fail-over:

vbroker.naming.enableSlave=1 
vbroker.naming.masterHost= 
vbroker.naming.masterPort= 
vbroker.naming.masterServer=MasterNS 
vbroker.naming.slaveHost= 
vbroker.naming.slavePort= 
vbroker.naming.slaveServer=SlaveNS 
vbroker.naming.backingStoreType=JDBC 
vbroker.naming.poolSize=5 
vbroker.naming.jdbcDriver=oracle.jdbc.driver.OracleDriver 
vbroker.naming.url=jdbc:oracle:thin:@... 
vbroker.naming.loginName=... 
vbroker.naming.loginPwd=... 
vbroker.naming.cacheOn=0
vbroker.naming.propBindOn=1

 Please note that:

1. When using MS fail-over, the cache needs to be turned off:

vbroker.naming.cacheOn=0

However, in VBE 5.2.1, the Name Service will automatically turn off the cache if MS fail-over is used.

2. When using MS fail-over, both the master and the slave Name Services will need to use the same instance of backing store. The scenario described here demonstrates how IC and MS fail-over work together to ensure high-availability and fail-over:

One of the object in the cluster that the client has been talking to becomes stale, at the same time, the Name Service (either the Master or the Slave) that the client has been talking to also becomes unavailable
 
The following sequence of events shows how the client recovers from the failure condition shown above:

1. The client fails to communicate with the remote object

2. The client attempt to "mark suspect" the remote object in the Name Service cluster. This action has 2 effects: first, once this object has been marked suspect, it will no longer be handed out to other clients; second, when the size of the cache has been reached (if the cache is used), the object marked will be removed.

3. However, because the scenario also includes the failure of the Name Service instance, the call to mark suspect this clustered object will also fail.

4. The failure to make the "markSuspect" call (which is essentially an IIOP call) will in effect cause the VisiBroker ORB to switch to the 2nd instance of the MS fail-over setup.

5. The client resend the markSuspect call to the 2nd instance of Name Service. Since both MS Name Services use the same backing store, and no cache is used, the effect is that all changes to the cluster are done to the backing store.

6. Subsequently, the client ask the cluster to return an alternate remote object bound to the same cluster.

Please note that the same logic explained above applies if Naming Service Cluster feature plus implicit clustering needs to be setup in an application.

Support Case: 563379