Tomas Restrepo 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/
Tomas,
After looking at your patched socket code, I think I will stop trying to
fix this! Nice job. I think in general these kinds of issues are tough
to completely eliminate... Any idea when QPID-398 will be ready for a
commit? :)
Cheers,
Jon
