activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "james strachan (JIRA)" <>
Subject [jira] Moved: (AMQNET-11) Thread synchronization error in TcpTransport
Date Tue, 27 Feb 2007 10:39:04 GMT


james strachan moved AMQ-988 to AMQNET-11:

        Fix Version/s:     (was: 4.1.0)
          Component/s:     (was: NMS (C# client))
    Affects Version/s:     (was: 4.0.2)
                  Key: AMQNET-11  (was: AMQ-988)
              Project: ActiveMQ .Net  (was: ActiveMQ)

> Thread synchronization error in TcpTransport
> --------------------------------------------
>                 Key: AMQNET-11
>                 URL:
>             Project: ActiveMQ .Net
>          Issue Type: Bug
>         Environment: Windows
>            Reporter: Rob Lugt
>         Assigned To: james strachan
>             Fix For: 1.0
>         Attachments: amq988-patch.txt
> I have a problem where my C# client application crashes when placed under load.  It's
taken a while to get to the bottom of it, but I believe I have identified the problem and
luckily there's a simple solution.
> The AMQ .Net client uses a common pattern where a full-duplex TCP/IP connection is established
with the broker, and the client uses two threads to concurrently read and write data to/from
the underlying socket - one thread reading from a Reader object and the other writing to a
Writer object.
> The TcpTransport.Start() method contains the following:-
>   NetworkStream networkStream = new NetworkStream(socket);
>   socketWriter = new OpenWireBinaryWriter(networkStream);
>   socketReader = new OpenWireBinaryReader(networkStream);
> This pattern is explicitly allowed in Java and Win32 applications, but .Net is a little
vague on the subject.  The Microsoft documentation [1] suggests use of the asynchronous read/write
calls for multithreaded applications, but that would significantly complicate the C# client
which relies on blocking stream behaviour.  On the same doc page 
> Microsoft does specifiy that the Socket class is thread-safe, which I take to mean that
concurrent read/write calls are permitted, however the same is not true of NetworkStream [2].
> Perhaps it would be reasonable to expect NetworkStream to have no internal state other
than the Socket it contains, but apparently this is not the case because I've identified that
it is a corrupt NetworkStream which is causing my application to crash under load.  After
some experimentation and a fair amount of load testing, I think the solution is a simple change
to the TcpTransport.start() method to use a separate NetworkStream for input and output operations.
e.g. :-
>   NetworkStream inputNetworkStream = new NetworkStream(socket);
>   NetworkStream outputNetworkStream = new NetworkStream(socket);
>   socketWriter = new OpenWireBinaryWriter(inputNetworkStream);
>   socketReader = new OpenWireBinaryReader(outputNetworkStream);
> This works for me and my test client has now been running for 16 hours without crashing
(before it would rarely last longer than 10 minutes).
> Regards
> Rob Lugt
> [1]
> [2]

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message