You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Jonathan Anstey <ja...@iona.com> on 2007/03/21 14:11:41 UTC
.NET Client & Java Broker Interop
Hi all,
I'm trying to use the Java broker with two .NET clients in a pub-sub
arrangement. I figured a good starting point for the clients would be in
Qpid.Client.Tests.interop. When I start the TopicListener, it connects
to the Java broker without issue. When I start the TopicPublisher, it
spits out the following exception:
2007-03-21 09:57:53,359 [976] WARN
Qpid.Client.Protocol.AMQProtocolListener:OnException(146) - Protocol
Listener received exception
System.IO.IOException: Unable to read data from the transport
connection: A blocking operation was interrupted by a call to
WSACancelBlockingCall. ---> System.Net.Sockets.SocketException: A
blocking operation was interrupted by a call to WSACancelBlockingCall
at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset,
Int32 size, SocketFlags socketFlags)
at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset,
Int32 size)
--- End of inner exception stack trace ---
at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset,
Int32 size)
at
Qpid.Client.Transport.Socket.Blocking.BlockingSocketProcessor.Read() in
E:\dotnet\Qpid.Client\Client\Transport\Socket\Blocking\BlockingSocketProcessor.cs:line
88
at Qpid.Client.Transport.Socket.Blocking.ByteChannel.Read() in
E:\dotnet\Qpid.Client\Client\Transport\Socket\Blocking\ByteChannel.cs:line
41
at Qpid.Client.Transport.AmqpChannel.Read() in
E:\dotnet\Qpid.Client\Client\Transport\AmqpChannel.cs:line 52
at
Qpid.Client.Transport.Socket.Blocking.BlockingSocketTransport.ReaderRunner.Run()
in
E:\dotnet\Qpid.Client\Client\Transport\Socket\Blocking\BlockingSocketTransport.cs:line
98
Can anyone shed any light on this? Also, are there anymore known interop
issues with the .NET client and Java broker?
Thanks!
Jon
Re: .NET Client & Java Broker Interop
Posted by Jonathan Anstey <ja...@iona.com>.
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
RE: .NET Client & Java Broker Interop
Posted by Tomas Restrepo <to...@devdeo.com>.
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/
Re: .NET Client & Java Broker Interop
Posted by Jonathan Anstey <ja...@iona.com>.
Rupert,
Just tried this and it works. Thanks for the hint. That said, I think I
will still wait for Thomas' mega-patch to the low level IO.
Cheers,
Jon
Rupert Smith wrote:
> 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 <to...@devdeo.com> 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/
>>
>>
>>
>>
>>
>
Re: .NET Client & Java Broker Interop
Posted by Rupert Smith <ru...@googlemail.com>.
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 <to...@devdeo.com> 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/
>
>
>
>
>
Re: .NET Client & Java Broker Interop
Posted by ja...@mail.ooc.nf.ca.
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!
Comments?
Thanks,
Jon
On Wed, Mar 21, 2007 at 01:49:17PM +0000, Rupert Smith wrote:
> The code for these tests was hacked together in a bit of a hurry. It outputs
> information about whether the tests pass or not to log4net, so you have to
> browse the debug level log output to find out if the test passed or not.
>
> Please add a line to print pass/fail to the console at an appropriate point
> in the TopicPublisher ( around line 143 and 147 where the Debug statements
> are).
>
> The exception you are seeing occurs after the test has passed when the
> publisher is closing its connection (I think). I don't know if I coded the
> connection close correctly or not. Take a look at the Shutdown method.
>
> Rupert
>
> On 3/21/07, Jonathan Anstey <ja...@iona.com> wrote:
> >
> > Hi all,
> >
> > I'm trying to use the Java broker with two .NET clients in a pub-sub
> > arrangement. I figured a good starting point for the clients would be in
> > Qpid.Client.Tests.interop. When I start the TopicListener, it connects
> > to the Java broker without issue. When I start the TopicPublisher, it
> > spits out the following exception:
> >
> > 2007-03-21 09:57:53,359 [976] WARN
> > Qpid.Client.Protocol.AMQProtocolListener:OnException(146) - Protocol
> > Listener received exception
> > System.IO.IOException: Unable to read data from the transport
> > connection: A blocking operation was interrupted by a call to
> > WSACancelBlockingCall. ---> System.Net.Sockets.SocketException: A
> > blocking operation was interrupted by a call to WSACancelBlockingCall
> > at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset,
> > Int32 size, SocketFlags socketFlags)
> > at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset,
> > Int32 size)
> > --- End of inner exception stack trace ---
> > at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset,
> > Int32 size)
> > at
> > Qpid.Client.Transport.Socket.Blocking.BlockingSocketProcessor.Read() in
> >
> > E:\dotnet\Qpid.Client\Client\Transport\Socket\Blocking\BlockingSocketProcessor.cs:line
> > 88
> > at Qpid.Client.Transport.Socket.Blocking.ByteChannel.Read() in
> > E:\dotnet\Qpid.Client\Client\Transport\Socket\Blocking\ByteChannel.cs:line
> > 41
> > at Qpid.Client.Transport.AmqpChannel.Read() in
> > E:\dotnet\Qpid.Client\Client\Transport\AmqpChannel.cs:line 52
> > at
> >
> > Qpid.Client.Transport.Socket.Blocking.BlockingSocketTransport.ReaderRunner.Run
> > ()
> > in
> >
> > E:\dotnet\Qpid.Client\Client\Transport\Socket\Blocking\BlockingSocketTransport.cs:line
> > 98
> >
> > Can anyone shed any light on this? Also, are there anymore known interop
> > issues with the .NET client and Java broker?
> >
> > Thanks!
> > Jon
> >
Re: .NET Client & Java Broker Interop
Posted by Rupert Smith <ru...@googlemail.com>.
The code for these tests was hacked together in a bit of a hurry. It outputs
information about whether the tests pass or not to log4net, so you have to
browse the debug level log output to find out if the test passed or not.
Please add a line to print pass/fail to the console at an appropriate point
in the TopicPublisher ( around line 143 and 147 where the Debug statements
are).
The exception you are seeing occurs after the test has passed when the
publisher is closing its connection (I think). I don't know if I coded the
connection close correctly or not. Take a look at the Shutdown method.
Rupert
On 3/21/07, Jonathan Anstey <ja...@iona.com> wrote:
>
> Hi all,
>
> I'm trying to use the Java broker with two .NET clients in a pub-sub
> arrangement. I figured a good starting point for the clients would be in
> Qpid.Client.Tests.interop. When I start the TopicListener, it connects
> to the Java broker without issue. When I start the TopicPublisher, it
> spits out the following exception:
>
> 2007-03-21 09:57:53,359 [976] WARN
> Qpid.Client.Protocol.AMQProtocolListener:OnException(146) - Protocol
> Listener received exception
> System.IO.IOException: Unable to read data from the transport
> connection: A blocking operation was interrupted by a call to
> WSACancelBlockingCall. ---> System.Net.Sockets.SocketException: A
> blocking operation was interrupted by a call to WSACancelBlockingCall
> at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset,
> Int32 size, SocketFlags socketFlags)
> at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset,
> Int32 size)
> --- End of inner exception stack trace ---
> at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset,
> Int32 size)
> at
> Qpid.Client.Transport.Socket.Blocking.BlockingSocketProcessor.Read() in
>
> E:\dotnet\Qpid.Client\Client\Transport\Socket\Blocking\BlockingSocketProcessor.cs:line
> 88
> at Qpid.Client.Transport.Socket.Blocking.ByteChannel.Read() in
> E:\dotnet\Qpid.Client\Client\Transport\Socket\Blocking\ByteChannel.cs:line
> 41
> at Qpid.Client.Transport.AmqpChannel.Read() in
> E:\dotnet\Qpid.Client\Client\Transport\AmqpChannel.cs:line 52
> at
>
> Qpid.Client.Transport.Socket.Blocking.BlockingSocketTransport.ReaderRunner.Run
> ()
> in
>
> E:\dotnet\Qpid.Client\Client\Transport\Socket\Blocking\BlockingSocketTransport.cs:line
> 98
>
> Can anyone shed any light on this? Also, are there anymore known interop
> issues with the .NET client and Java broker?
>
> Thanks!
> Jon
>