Bug 1278168 - [QE] (6.4.z) Server retrying remote JCA connection cannot be cleanly shut down
[QE] (6.4.z) Server retrying remote JCA connection cannot be cleanly shut down
Status: CLOSED DUPLICATE of bug 1301969
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: HornetQ (Show other bugs)
6.4.5
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Radovan Netuka
Miroslav Novak
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-04 15:12 EST by Miroslav Novak
Modified: 2016-12-15 09:46 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-15 09:46:41 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
standalone-full-ha-1.xml (29.60 KB, application/xml)
2015-11-04 15:12 EST, Miroslav Novak
no flags Details
standalone-full-ha-2.xml (27.82 KB, application/xml)
2015-11-04 15:13 EST, Miroslav Novak
no flags Details
threaddump.txt (67.52 KB, text/plain)
2015-11-04 15:13 EST, Miroslav Novak
no flags Details
ejb.jar (3.05 KB, application/zip)
2015-11-04 15:14 EST, Miroslav Novak
no flags Details
Client Application to Invoke EJB (5.34 KB, application/x-gzip)
2015-11-09 08:46 EST, Ryan Emerson
no flags Details

  None (edit)
Description Miroslav Novak 2015-11-04 15:12:03 EST
Description of problem:
We've found new issue with shutting down of EAP server retrying JCA outbound connection to remote server.

Version-Release number of selected component (if applicable):
EAP 6.4.5.CP.CR1 (HornetQ 2.3.25.SP5)

How reproducible:
Start 1st EAP 6.4.5 with queue OutQueue
Start 2nd EAP 6.4.5 with deployed EJB which sends message to remote queue OutQueue
Call EJB to send message to remote OutQueue
Shutdown 1st server
Try to shutdown 2nd server - this never happens as it's retrying connection to 1st server and following warning is logged every 2s:

21:00:22,820 WARN  [org.hornetq.core.client] (Thread-2 (HornetQ-client-global-threads-1761373667)) HQ212006: Waiting 2,000 milliseconds before next retry. RetryInterval=2,000 and multiplier=1

Expected results:
2nd server shutdowns.

Additional info:
Attaching configuration from servers, ejb and threadump from 2nd server.

Customer impact:
Customer will not be able to cleanly shutdown server and must kill it.
Comment 1 Miroslav Novak 2015-11-04 15:12 EST
Created attachment 1089840 [details]
standalone-full-ha-1.xml
Comment 2 Miroslav Novak 2015-11-04 15:13 EST
Created attachment 1089841 [details]
standalone-full-ha-2.xml
Comment 3 Miroslav Novak 2015-11-04 15:13 EST
Created attachment 1089842 [details]
threaddump.txt
Comment 4 Miroslav Novak 2015-11-04 15:14 EST
Created attachment 1089843 [details]
ejb.jar
Comment 5 Miroslav Novak 2015-11-04 15:16:11 EST
EJB can be called by following code:

final Properties env = new Properties();
            env.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
            env.put(Context.PROVIDER_URL, String.format("%s%s:%s", "remote://", "127.0.0.1", 4447));
            env.put("jboss.naming.client.ejb.context", true);
            Context ctx = new InitialContext(env);
            SimpleSendEJB simpleSendEJB = (SimpleSendEJB) ctx.lookup("ejb-sender/SimpleSendEJBBean!org.jboss.qa.hornetq.apps.ejb.SimpleSendEJB");
            simpleSendEJB.createConnection();
            simpleSendEJB.sendMessage();
            simpleSendEJB.closeConnection();
Comment 6 Ryan Emerson 2015-11-09 08:46 EST
Created attachment 1091753 [details]
Client Application to Invoke EJB
Comment 7 Ryan Emerson 2015-11-09 11:13:17 EST
I have also been able to reproduce this issue on EAP 6.4.4 (HornetQ 2.3.25.SP3). So this does not appear to be a regression.
Comment 15 Radovan Netuka 2016-12-15 09:46:41 EST

*** This bug has been marked as a duplicate of bug 1301969 ***

Note You need to log in before you can comment on or make changes to this bug.