[
https://issues.apache.org/activemq/browse/AMQNET-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Fraire updated AMQNET-112:
--------------------------------
Attachment: Apache.NMS.ActiveMQ.patch
Hi, Jim. I've re-attached the patch.
Thanks,
Chris
> 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: Jim Gomes
> 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.
