Perhpas doing something like: When close is called explicitly (or Dispose),
set a flag to indicate this is the case, then do the close, now on catching
the exception you can check the flag to determine whether it was caused by
an explicit close or by some other error condition on the socket.
On 22/03/07, Tomas Restrepo <[EMAIL PROTECTED]> wrote:
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/
