activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Gomes (JIRA)" <>
Subject [jira] Commented: (AMQNET-112) Threading issues -- Insufficient synchronization in Connection, Session, etc.
Date Mon, 08 Sep 2008 20:11:52 GMT


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.


> Threading issues -- Insufficient synchronization in Connection, Session, etc.
> -----------------------------------------------------------------------------
>                 Key: AMQNET-112
>                 URL:
>             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.

View raw message