Bug 1094380

Summary: (6.4.z) Multi threaded ejb invocations via remote-naming produce EJBCLIENT000025 if the Context is closed
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: wfink
Component: NamingAssignee: Enrique Gonzalez Martinez <egonzale>
Status: CLOSED CURRENTRELEASE QA Contact: Jan Martiska <jmartisk>
Severity: unspecified Docs Contact: Russell Dickenson <rdickens>
Priority: unspecified    
Version: 6.1.0, 6.2.0, 6.1.1, 6.2.1, 6.2.2CC: bbaranow, cdewolf, egonzale, emartins, jawilson, jmartisk, rsvoboda
Target Milestone: CR2   
Target Release: EAP 6.4.1   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-01-17 09:58:37 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1170672, 1207953    
Attachments:
Description Flags
TestCase none

Description wfink 2014-05-05 14:44:50 UTC 
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)
Comment 1 Enrique Gonzalez Martinez 2014-12-04 12:50:55 UTC 
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.
Comment 2 Enrique Gonzalez Martinez 2014-12-04 15:02:45 UTC 
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
Comment 3 Rostislav Svoboda 2015-04-23 14:24:30 UTC 
Please provide test (as discussed with Carlo) to include this in CP01 payload.
I will qa_ack afterwards.
Comment 4 Enrique Gonzalez Martinez 2015-04-28 08:38:59 UTC 
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"
Comment 5 Jan Martiska 2015-05-15 08:10:51 UTC 
Verified in EAP 6.4.1.CR2.
Comment 6 Petr Penicka 2017-01-17 09:58:37 UTC 
Retroactively bulk-closing issues from released EAP 6.4 cummulative patches.