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

[galder.zamarreno@jboss.com]

After finishing implementing jbas-4455 for JRMP, I have just started with unified invokers and I have realised that UnifiedInvokerProxy/UnifiedInvokerProxyHA maintain a 
instance reference to the InvokerLocator/Client instances to a specific invocation is using. That is, when a new target is chosen, the unified proxy 
updates its Client and corresponding InvokerLocator instances (if they've changed), and uses the Cient instance variable to make the call. As far 
as I can see there's no synchronisation in the usage/assignment of Client or InvokerLocator. Proxies are meant to be thread safe which means that 
multiple client app threads could be using the same proxy without any problems. I can see all this going wrong the moment someone uses client 
proxies this way in a clustered environment with round robin load balance policy. We've got no guarantee that round robin will work correctly in these situations.

JRMP based invokers never had this problem because they never stored the target server invoker used as instance variable. Why should Unified 
invoker proxies do so? IMO, it shouldn't. In a clustered environment, such instance variable could be constantly changing, i.e. round robin.

Secondly, looking at FirstAvailable, electedTarget access/update is not synchronised, however, the chances of having some issues are very small. First, the proxy needs to be shared by various threads before the electedTarget has been set, but as electedTarget already  elected randomly, the secondary effects of this lack of safety are none.

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

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