activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMQ-6801) race in WSTransportProxy startup can lead to WebSocket connection failure
Date Fri, 01 Sep 2017 12:07:00 GMT

    [ https://issues.apache.org/jira/browse/AMQ-6801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150413#comment-16150413
] 

ASF subversion and git services commented on AMQ-6801:
------------------------------------------------------

Commit ca86e2fbe6ff1cba762993c09de443a36c3709e7 in activemq's branch refs/heads/activemq-5.15.x
from [~gemmellr]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=ca86e2f ]

AMQ-6801: ensure transport listener is set before tripping latch to indicate startup is occuring

(cherry picked from commit 2e492569db2345cf3be8532630f93219159a8b15)


> race in WSTransportProxy startup can lead to WebSocket connection failure
> -------------------------------------------------------------------------
>
>                 Key: AMQ-6801
>                 URL: https://issues.apache.org/jira/browse/AMQ-6801
>             Project: ActiveMQ
>          Issue Type: Bug
>    Affects Versions: 5.15.0
>            Reporter: Robbie Gemmell
>            Assignee: Robbie Gemmell
>             Fix For: 5.15.1, 5.16.0
>
>
> There is a race between the startup and arrival of data in the WSTransportProxy class
that can lead to failure to create a WebSocket connection because there is no transport listener
available when data arrives, at least over AMQP where the SASL header arrives and can't be
processed. This has been observed causing Websocket related test failures in the ActiveMQ
CI jobs and also in Qpid JMS CI jobs (seemingly only since it was updated to use 5.15.0, though
this code hasn't changed since introduction in 5.14.0 it appears?).
> When supplied with new frame data, there is a check that the WSTransportProxy instance
has already been started, and if not a latch wait is performed until it is before proceeding.
This latch is tripped during startup but before the transport listener has been set, meaning
it is possible for frame data processing to proceed before the listener is actually set on
the transport. Also, the listener field isn't volatile so it could additionally be true that
the thread processing the data doesnt yet see a listener which has been set on the transport
in the startup thread. Moving the latch trip to after setting the listener should address
both those issues.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message