activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Fraire (JIRA)" <jira+amq...@apache.org>
Subject [jira] Created: (AMQNET-112) Threading issues -- Insufficient synchronization in Connection, Session, etc.
Date Mon, 08 Sep 2008 15:49:52 GMT
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
            Reporter: Chris Fraire
            Assignee: James Strachan
         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.


Mime
View raw message