]
Scott Van Wart commented on WFLY-8217:
--------------------------------------
I'll try a couple of other things in light of your comments. I'm no CDI expert
either. I think we need a support group. I haven't used @TransactionScoped but it
sounds suspicious as WELD gives the following warning:
{noformat}
WELD-001703: Unable to determine the @Intercepted Bean<?> for
[UnbackedAnnotatedField] @Inject @Intercepted private
com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.interceptedBean
{noformat}
That's always bothered me but I can't see any immediate ill effects from it. It
happens on each and every MDB that has some kind of transaction demarcation (unless
it's NOT_SUPPORTED--either through EJB3 annotations or JTA annotations). I wonder if
an MDB is defined outside the scope of CDI and I shouldn't be using JTA annotations at
all.
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: Jeff Mesnil
Priority: Minor
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.