]
Scott Van Wart commented on WFLY-9529:
--------------------------------------
That's good to hear; thanks for the update. My connection leak issue I mentioned
off-hand is much more likely to be [WFLY-8217] which seems to still be present in 13.x and
14.x but fixed in 15.x so it's not an issue. We're continuing to use an EJB
wrapper for our other JMS scenarios. I do wish there could be a grand unification of of
EJB/CDI/JSF in the EE spec complete with mass deprecation that would eliminate a good deal
of confusion. Our explicit use of EJB is very limited though required implicitly once
MDBs and executor threads are involved, even though most of our dependencies are strictly
CDI. It just looks like it creates unnecessary complexity. Thanks again.
Using injected JMS in a background task/thread leads to
NameNotFoundException: java:comp/TransactionSynchronizationRegistry
---------------------------------------------------------------------------------------------------------------------------
Key: WFLY-9529
URL:
https://issues.jboss.org/browse/WFLY-9529
Project: WildFly
Issue Type: Bug
Components: CDI / Weld, JMS, Naming
Affects Versions: 14.0.1.Final, 10.1.0.Final, 11.0.0.Final, 12.0.0.Final,
13.0.0.Final
Environment: Running on Windows 10, Java 64-bit 1.8.0_131
Reporter: Scott Van Wart
Assignee: Eduardo Martins
Priority: Major
Labels: ActiveMQ, jms, transaction
Attachments: injected-jms.zip, injected-jms2.zip, wildfly-11-injected-jms.txt
If I try to use an @Injected JMSContext while executing within a background task
(ManagedExecutorService) or thread (ManagedThreadFactory), I get the attached stacktrace.
I've experienced this a number of times with Wildfly 10.1.0, including messages sent
in Infinispan's expiry task thread.
My original workaround was to submit an additional task on a separate thread to send the
message, then wait for it to complete. That seemed unreliable (sometimes it would still
produce NameNotFoundException). I've resorted to creating my own JMSContext by using
@Resource( lookup="java:/ConnectionFactory" ) and sending messages that way.
Both workarounds prevent the message sending logic from participating in any ongoing
transactions.
I'm also attaching a sample EAR project. It can be built with Maven. It creates a
background task that waits 3 seconds and then tries to send a JMS message in a new
transaction using an injected JMS context. I use the standalone-full.xml profile to run
it.