9:19 a.m.
[
https://issues.jboss.org/browse/WFLY-8217?page=com.atlassian.jira.plugin....
]
Scott Van Wart commented on WFLY-8217:
--------------------------------------
For anyone continuing to have issues with this, it appears to be corrected in 15.x but not
14.x or 13.x. I experienced it again with the following scenario:
- Thread spawned by 3rd party library calls a method on an @ApplicationScoped CDI bean.
- This in turn calls a @Transactional method on another @ApplicationScoped CDI bean.
- ... calls a @Transactional method on a @Dependent CDI bean.
- ... calls a method on an @ApplicationScoped bean.
- ... calls a method on an @Inject'ed @Stateless EJB.
- The EJB uses its @Inject'ed JMSContext and calls createBytesMessage():
{noformat}
2019-05-01 14:12:06,906 INFO
[org.jboss.jca.core.api.connectionmanager.ccm.CachedConnectionManager]
(hz._hzInstance_1_dev.cached.thread-5) IJ000100: Closing a connection for you. Please
close them yourself: org.apache.activemq.artemis.ra.ActiveMQRASession@4dc6784e:
java.lang.Throwable: STACKTRACE
at
org.jboss.ironjacamar.impl@1.4.11.Final//org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl.registerConnection(CachedConnectionManagerImpl.java:308)
at
org.jboss.ironjacamar.impl@1.4.11.Final//org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:819)
at
org.apache.activemq.artemis.ra@2.6.3.jbossorg-001//org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.allocateConnection(ActiveMQRASessionFactoryImpl.java:872)
at
org.apache.activemq.artemis.ra@2.6.3.jbossorg-001//org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:531)
at
org.apache.activemq.artemis.ra@2.6.3.jbossorg-001//org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:746)
at
org.apache.activemq.artemis@2.6.3.jbossorg-001//org.apache.activemq.artemis.jms.client.ActiveMQJMSContext.checkSession(ActiveMQJMSContext.java:140)
at
org.apache.activemq.artemis@2.6.3.jbossorg-001//org.apache.activemq.artemis.jms.client.ActiveMQJMSContext.createBytesMessage(ActiveMQJMSContext.java:242)
at
org.wildfly.extension.messaging-activemq//org.wildfly.extension.messaging.activemq.deployment.injection.JMSContextWrapper.createBytesMessage(JMSContextWrapper.java:122)
{noformat}
This was reported 3 times in a single transaction so it looks like the original problem
might be related to improperly or neglecting to attach the JMS session to the current
transaction.
I don't see this behaviour in 15.x but I'm including all this for anyone searching
for solutions to a similar problem; the marked Fixed Version says 13.x but this
doesn't seem to be the case.
ActiveMQ leaks connections if a JMS message is sent from an MDB
---------------------------------------------------------------
Key: WFLY-8217
URL: https://issues.jboss.org/browse/WFLY-8217
Project: WildFly
Issue Type: Bug
Components: JMS, Transactions
Affects Versions: 10.1.0.Final
Environment: Running on Windows 10. Java(TM) SE Runtime Environment (build
1.8.0_92-b14)
Reporter: Scott Van Wart
Assignee: Emmanuel Hugonnet
Priority: Minor
Fix For: 13.0.0.Final
Attachments: leak.zip, leak.zip, log.txt, log.txt, server.log
If an MDB causes a JMS message to be sent during the call to onMessage(), ActiveMQ
won't close its connection. I'm using JMS2 through an @Inject'ed JMSContext.
My sample project is an EAR with an EJB JAR (containing a service and an MDB) and a JAX-RS
endpoint (entry point for the test).
1) Build the EAR
2) Run wildfly with the standalone-full.xml configuration:
{{standalone.bat --server-config=standalone-full.xml}}
3) Enable debug and error reporting for leaked connections with ActiveMQ/CCM:
{{jboss-cli.bat -c}}
{{/subsystem=jca/cached-connection-manager=cached-connection-manager:write-attribute(name=debug,value=true)}}
{{/subsystem=jca/cached-connection-manager=cached-connection-manager:write-attribute(name=error,value=true)}}
4) Deploy the EAR.
5) Access http://localhost:8080/leak-web/rest/test?message=Hi
The REST endpoint will send a message to the test topic (Defined in
leak-ejb/src/main/java/test/mdb/TestTopic.java). TestTopicListener (in the same package as
TestTopic) will receive the message and send a second message to the topic. Upon returning
from TestTopicListener.onMessage(), the message is sent, but this shows up in the logs
(see attached log.txt)
I have no idea why JIRA attached each file twice.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
2409
days inactive
2409
days old
0 comments
1 participants
participants (1)
-
Scott Van Wart (Jira)