]
Scott Van Wart commented on WFLY-9529:
--------------------------------------
I've definitely seen issues (especially at deployment time) with injecting
TransactionSynchronizationRegistry as [~clerum] describes. The injected JMSContext was
simply the easiest to reproduce.
I've also had issues with submitting tasks to ManagedExecutorService within @Observes
@Initialized or @PostConstruct-annotated bean methods. Sometimes the bean initializers
are called before the executor service is ready. The workaround there was to use
ManagedScheduledExecutorService and submit a recurring task that cancels itself when it
first (successfully) runs. I'm just wondering if that's related, especially since
[~clerum] mentioned the ManagedExecutorService.
Alas I haven't been able to reproduce that issue reliably enough to submit a report
about it.
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.