Jon,
> Thanks Rupert. Your help is greatly appreciated! The debug output from
> the interop tests indicate that all is well for the basic pub-sub
> scenario.
>
> You are right about the SocketException being thrown after the actual
> tests. The error does not actually affect the messages transfered in
> any way, it just indicates that there are problems in closing a
> connection. After looking at the other unit tests for the client, it
> seems that the proper way to shutdown is to just call Dispose() on the
> connection. Using this method still produces the original exception
> however. Take BlockingSocketTransport.cs for example, this loop is
> running in a thread near the bottom of the file:
>
> 1 while (_running)
> 2 {
> 3 Queue frames =
> _transport.ProtocolChannel.Read();
> 4
> 5 foreach (IDataBlock dataBlock in frames)
> 6 {
> 7
> _transport._protocolListener.OnMessage(dataBlock);
> 8 }
> 9 }
>
> If _running is set to false in between lines 1 & 3, when the Read()
> method is called, the socket is likely already closed and thus we get
> an exception. I am wondering what the best way to fix this is...
>
> - The block inside the loop could become a critical section, thus
> ensuring that the socket is not disconnected during a Read() call. Not
> sure about the side effects here...
> - Perhaps we could simply handle this particular exception better?
> - Or maybe we do nothing :) Well, sort of. Blocking calls (such as
> Read()) on sockets are interruptable by nature so this exception could
> be thrown at any time!
The thing is that the read runs in its own custom thread, running
constantly. There's really no good way in a case like this to say "stop
reading" and make sure it is caught on time, since the reads are blocking
reads.
I wouldn't spend much time trying to fix that right now, if only because I
rewrite most of the low-level IO code (including adding real asynchronous
reads) when implementing SSL support for the .NET client. The patch has not
been committed yet (it's https://issues.apache.org/jira/browse/QPID-398), as
it is a fairly massive patch at that.
(Though in all honestly, I don't remember if I successfully avoided the
error 100% of the time, I'll have to check it again).
Tomas Restrepo
http://www.winterdom.com/weblog/
