[jboss-dev-forums] [Design of Clustering on JBoss (Clusters/JBoss)] - Re: Transaction Sticky LB policy for 4.2/trunk

[galder.zamarreno@jboss.com]

"bstansberry at jboss.com" wrote : Please create JIRAs for these.  If you can fix them, even better. :-) 

I'll create them and try to fix them too :)

"bstansberry at jboss.com" wrote : I've only taken a one minute glance at the relevant UnifiedInvokerHA code. Would some synchronization in the UnifiedInvokerHAProxy.getClient code solve the problem? I believe UnifiedInvokerHAProxy.invoke does not use the client instance field, but rather a local variable.
  | 
  | A map of Clients keyed by target is also a possibility, although that's a more complex solution.

UnifiedInvokerHAProxy.getClient() returns the client instance variable. This is set in init(InvokerLocator) which gets called once only for UnifiedInvokerProxy. However in UnifiedInvokerHAProxy, this method is called whenever the cached locator is different to the one returned by the loca balance policy. So, in a round robin scenario, the client instance variable (which is accessed via getClient) would be changing constantly.

Synchronising getClient() could resolve the issue. Need to look more in depth. Seeing this, it is my intention to create a UT that tests thread safety as part of jbas-4455. It'd probably comment it when committing jbas-4455, so that it remains independent, and then resolve it when I fix that jira.

Another simple solution would be not to used the cached Client (like in jrmp). However, this could mean calling connect every time the Client is used. I need to look at Client in case this could be avoided by some isConnected() method. 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4092746#4092746

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4092746