Description of problem:
While a thread (1) of EJB client invokes a remote EJB which needs long
processing time and wait for the response, if the other threads complete
more than 65536 invocations to the remote EJB, EJBCLIENT000011 message like
below occurs in EJB client side and the waiting thread (1) falls into
infinite wait for the response.
INFO: EJBCLIENT000011: Discarding result for invocation id 0 since no
waiting context found
All invocations should successfully complete regardless of the number of
invocations.
Version-Release number of selected component (if applicable):
EAP 6.3.3, 6.4.5.
I tested on RHEL 6.7, but this issue does not depend on OS/Hardware.
How reproducible:
always
Steps to Reproduce:
Use the reproducer remote-ejb-EJBCLIENT000011.zip attached.
The overview of this reproducer:
- The first thread starts and invokes the remote EJB which needs long
processing time. ..... (1)
- After that, the second thread starts and repeats invocation to the remote
EJB more than 65536 times before (1) finishes. ..... (2)
Each invocation to the remote EJB in (2) completes in a short period
of time.
- Once the remote EJB in (1) finishes its work, EJBCLIENT000011 message
occurs from the EJB client.
Steps to reproduce is as follows:
1. Start a standalone EAP server.
2. Extract remote-ejb-EJBCLIENT000011.zip.
3. Build the reproducer. ..... (*1)
$ cd remote-ejb-EJBCLIENT000011
$ mvn package
4. Deploy remote-ejb-EJBCLIENT000011-1.0.0.jar.
5. Run TestMain. ..... (*3)
2 or 3 minites later after starting TestMain, EJBCLIENT000011 message
will occur and TestMain will not end because of the first thread's
infinite wait for response.
(*1) Before execute mvn, modify providerIpPort at FIXME in
src/test/java/TestMain.java appropriately.
(*2) Run add-user.sh to add an application user.
(Username "jboss" and password "jbossjboss#2")
(*3) For reference, see run_test.sh in remote-ejb-EJBCLIENT000011 I used
for running TestMain. You can use it by making modification
appropriately.
Actual results:
The first thread of TestMain waits for the response of the invocation
indefinitely and TestMain never ends.
Expected results:
The first thread of TestMain receives the response of the invocation and
TestMain successfully ends.
Additional info: