[
https://issues.apache.org/activemq/browse/AMQNET-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=45539#action_45539
]
Jim Gomes commented on AMQNET-112:
----------------------------------
Hi Chris,
Thanks for working on this. However, the grant ASF license option wasn't
checked when you attached the patch. If you would check that option, I'll
integrate these changes into the trunk. You may have to delete and re-attach
the patch.
Thanks!
> Threading issues -- Insufficient synchronization in Connection, Session, etc.
> -----------------------------------------------------------------------------
>
> Key: AMQNET-112
> URL: https://issues.apache.org/activemq/browse/AMQNET-112
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ Client
> Affects Versions: 1.0
> Reporter: Chris Fraire
> Assignee: James Strachan
> Fix For: 1.1
>
> Attachments: Apache.NMS.ActiveMQ.patch
>
>
> I have been debugging some threading issues in NMS, and I have attached a
> patch file with some proposed changes to correct the following issues:
> * Some threading issues in Connection, Session, and DispatchingThread
> - it is insufficient to use ArrayList.Synchronized or Hashtable.Synchronized
> since enumeration is not synchronized. Instead, use regular collections and
> explicit locking using a private object, myLock
> - instead of Connection.connected, use a volatile single-state-change bool
> called triedConnect, to add synchronization to CheckConnected without
> adversely-affecting performance
> - mark as volatile certain bools which have a single state change (e.g.,
> Connection.closed, which starts at false and changes once to true) and then
> double-check for minimal locking
> - some uses of AtomicBoolean (e.g., Connection.started) offered insufficient
> code synchronization. Instead, use regular bool and locking of the
> aforementioned myLock
> - remove Connection.closing field, and instead always accommodate that
> Connection.RemoveSession modifies the sessions list.
> - instead of (bool) DispatchingThread.m_bStopFlag, use a ManualResetEvent (in
> addition to the existing AutoResetEvent) to signal the worker thread
> - in TcpTransport, recognize that ShutdownCommand may cause broker to close
> connection, to avoid a spurious error message
> - accommodate potential ThreadAbortExceptions which can occur from
> explicitly-aborted worker threads
> - increase the wait for stopping async delivery, from 5 seconds to 30
> - use Interlocked.Increment for thread-safe int increments.
> (Interlocked.Increment wraps Int32.MaxValue to Int32.MinValue; will this be a
> problem?)
> * Tweak implementation of IDisposeable in TcpTransport, MutexTransport,
> TransportFilter, WireFormatNegotiator so finalizers call Dispose
> Thank you,
> Chris
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
