[jboss-jira] [JBoss JIRA] (WFLY-9529) Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry

[Scott Van Wart (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-9529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505320#comment-13505320 ] 

Scott Van Wart edited comment on WFLY-9529 at 12/13/17 7:50 PM:
----------------------------------------------------------------

[~emmartins] I'm under the impression that when a managed thread is produced or a task is submitted to the scheduler service, it's created in such a way that it can never look up that TransactionSynchronizationRegistry.  Sometimes it works and sometimes it doesn't. If it doesn't, the problem persists until Wildfly is restarted. Is it a race condition (e.g. a CDI bean making use of a resource before the EE components are fully booted)?  Would it help if I only use @Resource ManagedExecutorService or @Resource ManagedThreadFactory from within EJBs--and not from within CDI beans?

For what it's worth, your second solution gets my vote as it seems like the @Inject JMSContext is the only component exhibiting this behavour.  Thanks so much for the information.


was (Author: silvaran):
[~emmartins] I'm under the impression that when a managed thread is produced or a task is submitted to the scheduler service, it's created in such a way that it can never look up that TransactionSynchronizationRegistry.  Sometimes it works and sometimes it doesn't--and if it doesn't, the problem persists until Wildfly is restarted. Is it a race condition (e.g. a CDI bean making use of a resource before the EE components are fully booted)?  Would it help if I only use @Resource ManagedExecutorService or @Resource ManagedThreadFactory from within EJBs--and not from within CDI beans?

For what it's worth, your second solution gets my vote as it seems like the @Inject JMSContext is the only component exhibiting this behavour.  Thanks so much for the information.

> 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)