]
Scott Van Wart commented on WFLY-9529:
--------------------------------------
[~emmartins] Is there any further update on this? We have an ActiveMQ connection leak
that I suspect is related to this. It seems every few weeks one of our Wildfly
installations starts up and needs to be restarted again to gamble on some race condition.
There seems to be a variety of symptoms that crop up, such as Wildfly allowing tasks to be
submitted to an MES at startup, only for that task to fail because the MES isn't ready
(our workaround for that is to use a scheduled MES and retry until it succeeds). I've
wrapped some of our messaging logic in an EJB but it looks like instead of getting
NameNotFoundException: TransactionSynchronizationRegistry it's culminating in an
ActiveMQ connection leak.
Honestly, we've moved the vast majority of our messaging to Hazelcast and have a few
more cases to cover. Whether or not this will get properly addressed is going to
determine if we put the final nails in the coffin.
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.