Bug #671
Updated by J. Moringen over 12 years ago
When trying to deactivate participants after a Spread connection has failed, something along the lines of the following happens:
<pre>
spread.SpreadException: write(): java.net.SocketException: Broken pipe
at spread.SpreadConnection.multicast(SpreadConnection.java:1934)
at spread.SpreadConnection.disconnect(SpreadConnection.java:961)
at rsb.transport.spread.SpreadWrapper.deactivate(SpreadWrapper.java:309)
at rsb.transport.spread.SpreadPort.deactivate(SpreadPort.java:376)
at rsb.transport.Router.deactivate(Router.java:143)
at rsb.Listener$ListenerStateActive.deactivate(Listener.java:54)
at rsb.Listener.deactivate(Listener.java:123)
at rsb.patterns.Method$MethodStateActive.deactivate(Method.java:61)
at rsb.patterns.Method.deactivate(Method.java:160)
at rsb.patterns.Server$ServerStateActive.deactivate(Server.java:52)
at rsb.patterns.Server.deactivate(Server.java:116)
at client.main(client.java:138)
</pre>
There seem to be two related issues:
* Since client code cannot handle this situation properly, the exception should be handled (probably by just ignoring it at @rsb.transport.Router.deactivate(Router.java:143)@) within RSB
* After the exception is thrown, some threads remain (not the main thread, since it terminates with the above exception) and continue to produce this kind of output:
<pre>
Oct 21, 2011 9:09:24 PM rsb.transport.spread.ReceiverTask run
WARNING: Caught a SpreadException while trying to receive a message: Connection closed while reading header
Oct 21, 2011 9:09:24 PM rsb.transport.spread.ReceiverTask run
WARNING: Caught a SpreadException while trying to receive a message: Connection closed while reading header
Oct 21, 2011 9:09:24 PM rsb.transport.spread.ReceiverTask run
</pre>
These could belong to participants associated to other methods of the remote server which do not get deactivated because of the exception.
Another instance of the problem can be seen "here":https://ci.cor-lab.de/view/RSB/job/rsb-integrationtest/label=ubuntu_lucid_64bit/901/consoleFull (search for "TimeoutException" in the output).
<pre>
spread.SpreadException: write(): java.net.SocketException: Broken pipe
at spread.SpreadConnection.multicast(SpreadConnection.java:1934)
at spread.SpreadConnection.disconnect(SpreadConnection.java:961)
at rsb.transport.spread.SpreadWrapper.deactivate(SpreadWrapper.java:309)
at rsb.transport.spread.SpreadPort.deactivate(SpreadPort.java:376)
at rsb.transport.Router.deactivate(Router.java:143)
at rsb.Listener$ListenerStateActive.deactivate(Listener.java:54)
at rsb.Listener.deactivate(Listener.java:123)
at rsb.patterns.Method$MethodStateActive.deactivate(Method.java:61)
at rsb.patterns.Method.deactivate(Method.java:160)
at rsb.patterns.Server$ServerStateActive.deactivate(Server.java:52)
at rsb.patterns.Server.deactivate(Server.java:116)
at client.main(client.java:138)
</pre>
There seem to be two related issues:
* Since client code cannot handle this situation properly, the exception should be handled (probably by just ignoring it at @rsb.transport.Router.deactivate(Router.java:143)@) within RSB
* After the exception is thrown, some threads remain (not the main thread, since it terminates with the above exception) and continue to produce this kind of output:
<pre>
Oct 21, 2011 9:09:24 PM rsb.transport.spread.ReceiverTask run
WARNING: Caught a SpreadException while trying to receive a message: Connection closed while reading header
Oct 21, 2011 9:09:24 PM rsb.transport.spread.ReceiverTask run
WARNING: Caught a SpreadException while trying to receive a message: Connection closed while reading header
Oct 21, 2011 9:09:24 PM rsb.transport.spread.ReceiverTask run
</pre>
These could belong to participants associated to other methods of the remote server which do not get deactivated because of the exception.
Another instance of the problem can be seen "here":https://ci.cor-lab.de/view/RSB/job/rsb-integrationtest/label=ubuntu_lucid_64bit/901/consoleFull (search for "TimeoutException" in the output).