[jboss-jira] [JBoss JIRA] (WFLY-5596) MessageDrivenComponent startDelivery/stopDelivery is not thread safe

[Jason Greene (JIRA)]

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

Jason Greene commented on WFLY-5596:
------------------------------------

I remember glancing at this code and thinking it could be better protected. However, IIRC the only usage point is from management ops, and since these ops are declared as write operations they hold the exclusive management write lock. 

> MessageDrivenComponent startDelivery/stopDelivery is not thread safe
> --------------------------------------------------------------------
>
>                 Key: WFLY-5596
>                 URL: https://issues.jboss.org/browse/WFLY-5596
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, JMS
>    Affects Versions: 10.0.0.CR4
>            Reporter: James Livingston
>            Assignee: Jeff Mesnil
>
> WFLY-4470 made a change to prevent MDBs being activated or deactivated multiple times, but it is not thread safe. A volatile boolean is used for the flag, but there is no protection against multiple threads invoking the methods simultaneously.
> Possible effects include:
> * activating the endpoint twice, with (probably) only one deactivation later, leading to not de-registering XA resources from the recovery manager properly
> * activate() and deactivate() running in the wrong order if done by separate threads
> Several simple solutions probably will not work correctly. Using an AtomicBoolean would stop multiple activations/deactivations from concurrent calls, but would mean that startDelivery() could return before the activation was one. Using a synchronized block or other exclusive lock would work, however since it involves invoking non-container code (the resource adapter), there could potentially be a deadlock risk if that invoked some related container functionality.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)