I think wayne is saying this is a network race condition - where the
broker can send the wireformat info before the client starts reading.
However, as the client doesn't start reading from the socket until
after initializeStreams is called - I'm not sure how the socket will
miss the wireformat info from the broker?
On 6 May 2006, at 07:34, James Strachan wrote:
On 4/28/06, Wayne1285 <[EMAIL PROTECTED]> 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/
Rob Davies
http://rajdavies.blogspot.com/
