-
30. Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
clebert.suconic Jan 22, 2007 10:14 AM (in response to clebert.suconic)"timfox" wrote:
Clebert-
I just tried to deploy the scoped sar in JBAS and it fails, complaining that it cannot find a property editor for ConnectionFactory::setLoadBalancingFactory.
Looking at the code, the method setLoadBalancingFactory() takes a LoadBalancingFactory, but the MBean method takes a String.
I have fixed this, so I can get on with my work. You may want to review my fix since it was very quick.
This tells me one thing, you added an MBean attribute without adding a corresponding test for it.
All new functionality needs to have unit tests, so please could you add a test.
Cheers.
I just changed this in top of what Ovidiu had before... Ovidiu had a LoadBalancingPolicy and I placed a LoadBalancingFactory in replacement.
I actually started doing this by using a String the same way you changed... but then I realized what Ovidiu had before and I used the same thing. By looking at his code I thought MBeans would take care of it on the XML description (using a default's constructor) -
31. Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
timfox Jan 22, 2007 10:33 AM (in response to clebert.suconic)"clebert.suconic@jboss.com" wrote:
The update is happening on ConnectionFactoryJNDIMapper::onReplicationChange..
Look at the method's implementation, you will see a call to updateClusteredClients:line 359: endpoint.updateClusteredClients(delArr, failoverMap);
Sigh... You're still missing the point :)
This line of code is only called when the replication change is a deploy/undeploy of a connection factory:else if (sKey.startsWith(CF_PREFIX) && originatorNodeID != serverPeer.getServerPeerID()) {
My question was, can you explain to me how this is called when a node crashes?
When a node crashes it won't have the courtesy to undeploy its connection factories first.
So how would this get called? -
32. Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
clebert.suconic Jan 22, 2007 10:46 AM (in response to clebert.suconic)Sigh... You're still missing the point :)
This line of code is only called when the replication change is a deploy/undeploy of a connection factory:
Nope... this place is called also when a node leaves/joins the cluster. Replicator is re-sending the lists when a node leaves... (crash).
This is exactly the place where we were doing rebinds before.
I just executed ClusterViewUpdate Test, using run test... and I could see the event fired on logs.
ClusterViewUpdate would fail if the Connection Factory was not updated after a crash. -
33. Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
timfox Jan 22, 2007 10:50 AM (in response to clebert.suconic)line of code please?
-
34. Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
timfox Jan 22, 2007 10:52 AM (in response to clebert.suconic)CF_PREFIX is used when a connection factory is deployed/undeployed.
ADDRESS_INFO_KEY is used when a node joins/leaves
What you are now saying is that we make a change with prefix CF_PREFIX when a node joins leaves? -
35. Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
timfox Jan 22, 2007 10:54 AM (in response to clebert.suconic)Looking through the code, the only place where a replication change with prefix CF_PREFIX = "CF_" is sent is when a connection factory is deployed or undeployed, i.e. in registerConnectionFactory() and unregisterConnectionFactory().
There is no where else in the code where such a replication change is propagated.
So you still haven't explained how such a replication event gets propagated when a node crashes..... -
36. Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
clebert.suconic Jan 22, 2007 12:14 PM (in response to clebert.suconic)- DefaultClusteredPostOffice::nodeLeft will call cleanLocalDataForNode.
cleanLocalDataForNode will resubmit all the listeners as the CF was being redeployed. This logic was written long time ago.. I didn't change anything on the rebinds logics.