activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james.strac...@gmail.com>
Subject Re: Race Condition?
Date Sat, 06 May 2006 06:34:45 GMT
On 4/28/06, Wayne1285 <WayneSIrwin@hotmail.com> wrote:
>
> I am using ActiveMq-4.0-RC3.  I have been having intermittent problems
> getting sessions created and closed.  I have downloaded the code and traced
> through it and I think I have found the problem.
>
> There is a race conditon in the TcpTransport class, in the doStart() method.
> As near as I can tell, as soon as the socket is created, the Broker responds
> with its WireFormatInfo.  This information is usually stored as the
> remoteWireFormatInfo in the InactivityMonitor.  The race condition occurs in
> the doStart() method as it appears the broker can sometimes send the
> wireFormatInfo before the initializeStreams() method can be called.  This
> results in the information not being capture in the dataIn input buffer.

I just refreshed my memory of the code for TcpTransport and took a
peek at InactivityMonitor. I'm not sure I grok yet the race condition.
TcpTransport only allows itself to be started once and uses a 
semaphore around the doStart(); so that all looks good. Also
TcpTransport doesn't allow messages to be sent until the transport is
started (it throws an exception if an attempt is made to send to the
transport before its started).

So I don't quite follow the sequence of events causing the race
condition; is some thread trying to use the TcpTransport before its
been started? If so I don't understand why the checkStarted() method
is not throwing an exception?

--

James
-------
http://radio.weblogs.com/0112098/

Mime
View raw message