You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Jim Gomes (JIRA)" <ji...@apache.org> on 2008/10/07 02:42:52 UTC

[jira] Issue Comment Edited: (AMQNET-112) Threading issues -- Insufficient synchronization in Connection, Session, etc.

    [ https://issues.apache.org/activemq/browse/AMQNET-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=45782#action_45782 ] 

semog edited comment on AMQNET-112 at 10/6/08 5:41 PM:
-----------------------------------------------------------

The changes made to the threading have severely impacted thread synchronization.  Message routing and dispatching has slowed to one message every 30 seconds.  I reimplemented the patch submission to fix the new issues while keeping the improved robustness of the contribution.

      was (Author: semog):
    The changes made to the threading have severely impacted thread synchronization.  Message routing and dispatching has slowed to one message every 30 seconds.
  
> 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
>
>          Time Spent: 3 hours
>  Remaining Estimate: 0 minutes
>
> 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.