Status: Resolved (View Workflow)
Affects Version/s: None
Fix Version/s: None
Steps to Reproduce:
Use reproducer from
WFLY-10997. If output does not contain "anonymous", the call was handled remotely.
Release Notes Text:The problem was fixed in WildFly core code base.
Sometimes, a local EJB call is handled by remote receiver instead of the local one, and this is caused by a difference in the Endpoint name used by EJB Client, that sometimes happens to have a ",MANAGEMENT" suffix.
This bug was found during investigation of
WFLY-10997, here is a description by Bartosz Baranowski:
[...] there seems to be race WRT Affinity.
Code creates two proxies:
Test test = (Test)ctx.lookup("ejb:/reproducer/TestSLSB!test.Test");
Test test2 = (Test)ctx.lookup("reproducer/TestSLSB!test.Test");
This in turns creates two locators with affinity:
Trick is that for some reason there is sort of a race. It seems this is "on startup" race, meaning this condition does not seam to change( I think) in subsequent calls, it just changes between server run ( server and client part run on server and are invoked via curl->servlet->ejb).
During run, ProtocolV3ObjectResolver receives affinity:
Latter one is received in both cases, however it is being used only sometimes( during second invocation).
Sometimes second call is being routed as remote, sometimes as local. If its run as local, we get the identity bug.
The switch or rewrite of affinity happens in ProtocolV3ObjectResolver due to different value of  selfNodeAffinity
In my case, machine == "drone-1-1". Sometimes, this value( that comes from remoting3) would be 'drone-1-1' and sometimes 'drone-1-1;MANAGEMENT'.
In read resolve, , replacement always defaults to 'drone-1-1'. So if selfNodeAfinity has the same value, Affinity == LOCAL, otherwise, since "drone-1-1:MANAGEMENT" != "drone-1-1",, affinity stick to URI and call becomes remote.
My guess is that this is due to random assignment of channels/endpoints or common pool of connections that are being used on who ever wants basis?