Description of problem: If different Threads are creating different InitialContext with the same remote-naming approach closing the InitialContext will have effect to other threads. The reproducer is attached to https://issues.jboss.org/browse/WFLY-3316 and can be used the same way (with the URL= remote://localhost:4447)
The problem here is in the naming component. When several threads are using EJBContext the NamingStoreCache is mixing context among threads. Cache problem & race condition description When the InitialContext creates a new RemoteNamingStore, *The cache is not taking into account the EJBClientHandler*. This EJBClientHandler could have different EJBClientContextIdentifier. When a remote ejb is invoked every thread is using the same RemoteNamingStore therefore the same EJBClientContext during an invocation (in this case because the endpoint data is the same). This leads to a race condition: ThreadA: close the context (raising the closed flag in the ejbcontext) ThreadB: tries to invoke the context. It raises the error EJBCLIENT000025. (both threads are using the RemoteNamingStore, therefore the same EJBClientHandler and EJBClientContext). Note for Wildfly : It also happens that EJBClientContext is executed before the RemoteNaming.CloseTask leading to a new stacktrace. (this happens for jboss-remote-naming 2.0.3.Final and jboss-remoting 4.0.5.Final due to the shutdown of the ExecutorService in EJBClientContext::close call.
Naming component 2.x upstream component PR https://github.com/jbossas/jboss-remote-naming/pull/22 1.x component PR https://github.com/jbossas/jboss-remote-naming/pull/23
Please provide test (as discussed with Carlo) to include this in CP01 payload. I will qa_ack afterwards.
Created attachment 1019572 [details] TestCase Providing test case: execution: mvn test Note: the dependency for the jboss.as should be modified to run the test. Property "version.org.jboss.as"
Verified in EAP 6.4.1.CR2.
Retroactively bulk-closing issues from released EAP 6.4 cummulative patches.