[
https://issues.jboss.org/browse/WFLY-9529?page=com.atlassian.jira.plugin....
]
Eduardo Martins commented on WFLY-9529:
---------------------------------------
[~silvaran] No, that was just a simplification of the app, the issue is that on such
event, and without a EE component in context, the Java EE standard JNDI contexts are not
available, and JMSContext dependency on it makes it fail to work. There are two possible
solutions for this, make such contexts (even if limited on resources bound) available, or
instead remove usage of JNDI by the injected JMSContext implementation, and while I can
code both quickly I'm investigating what is the proper solution (even comparing with
other vendor app servers).
By the way, I did not test that but it should work if you pack the app in a war instead of
ear.
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: JMS, Naming
Affects Versions: 10.1.0.Final, 11.0.0.Final
Environment: Running on Windows 10, Java 64-bit 1.8.0_131
Reporter: Scott Van Wart
Assignee: Eduardo Martins
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.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)