[
https://issues.apache.org/jira/browse/QPID-7905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16249766#comment-16249766
]
Alex Rudyy commented on QPID-7905:
----------------------------------
Whilst looking into the potential fix for the reported problem, the following
approaches have been analyzed:
* Adding synchronization locks into {{Connection#start}}/{{Connection#stop}}
methods similar to synchronization locks in {{Connection#close}}
* Moving sending of {{flow}} command into the dispatcher thread.
Adding synchronization locks would involve adding the following synchronization
locks: session creation lock, delivery lock, dispatcher lock and failover
mutex. Adding of these lock seem would work for 0-9 code path. However, 0-10
path uses dispatcher thread to release pre-aquired messages on
{{Connection#stop}}, thus, acquisition of of delivery and dispatcher locks
would require changes to the code to release messages
{{AMQSession#drainDispatchQueueWithDispatcher}} which is called from
{{AMQPSession_0_10#stop}}.
Moving sending of {{flow}} command into the dispatcher thread would require
changes to how dispatcher works. The dispatcher would need to be created and
started immediately on {{Connection#start}} and stopped on {{Connection#stop}}
or started on session creation if connection is started, the code where flow
is currently send
(rollback/recover/SuspenderRunner/registerConsumer/start/stop) would need to be
changed to submit special tasks into dispatcher to send the flow. It seems we
need to make a lot of changes to the client in this case.
> [Java Client AMQP 0-x] Connection#start is not thread-safe
> ----------------------------------------------------------
>
> Key: QPID-7905
> URL: https://issues.apache.org/jira/browse/QPID-7905
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
> Reporter: Lorenz Quack
> Priority: Critical
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> The JMS spec says that Connections may be used from several threads
> concurrently.
> However, our implementation of {{Connection#start}} is currently not
> thread-safe. It iterates over its list of sessions and calls
> {{Session#start}}. The session rightfully (this is specified in the JMS spec
> as well) assumes that it is being called from a single thread.
> An example of the impact of this is that a session can be used (by
> {{Connection#start}}) after it has been closed (via {{Session#close}})
> leading to an Exception due to the broker receiving a frame with an unknown
> {{channelId}}.
> Note: The comment on {{Connection#start}} stating that JMS allows for non
> thread-safe implementations seems to be in error!
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
