You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org> on 2008/04/23 13:53:21 UTC
[jira] Created: (QPID-952) .NET NetworkStream does not immediately
detect connection failure.
.NET NetworkStream does not immediately detect connection failure.
------------------------------------------------------------------
Key: QPID-952
URL: https://issues.apache.org/jira/browse/QPID-952
Project: Qpid
Issue Type: Bug
Components: Dot Net Client
Affects Versions: M2, M1, M2.1
Reporter: Martin Ritchie
Summary:
The NetworkStream used by the Blocking IO does not immediately report the underlying socket connection failure. It can take up to 20 seconds before this is reported. According to the API:
http://msdn2.microsoft.com/en-us/library/system.net.sockets.networkstream.read(VS.71).aspx
The Read call only returns zero when the connection has been closed. So we can close the underlying socket which will stop all sends and force an exception on the next read attempt. This in turn will cause failover to be triggered.
Defect Identification:
When running with debug on you can see lots of 'Read() 0' logged out when the broker is killed. This is due to the NetworkStream returning 0 instantly as described in the API docs, as a result of the socket being gracefully shutdown. Unfortunately it is still possible to send data without an exception so sends can be lost.
Proposed Changes:
If we get 0 bytes being read from the NetworkStream we can block sends and shutdown the socket which will cause failover to occur in the next read loop.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (QPID-952) .NET NetworkStream does not
immediately detect connection failure.
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591981#action_12591981 ]
Martin Ritchie commented on QPID-952:
-------------------------------------
Did try DataAvailable but CanRead just returned true.
> .NET NetworkStream does not immediately detect connection failure.
> ------------------------------------------------------------------
>
> Key: QPID-952
> URL: https://issues.apache.org/jira/browse/QPID-952
> Project: Qpid
> Issue Type: Bug
> Components: Dot Net Client
> Affects Versions: M1, M2, M2.1
> Reporter: Martin Ritchie
>
> Summary:
> The NetworkStream used by the Blocking IO does not immediately report the underlying socket connection failure. It can take up to 20 seconds before this is reported. According to the API:
> http://msdn2.microsoft.com/en-us/library/system.net.sockets.networkstream.read(VS.71).aspx
> The Read call only returns zero when the connection has been closed. So we can close the underlying socket which will stop all sends and force an exception on the next read attempt. This in turn will cause failover to be triggered.
> Defect Identification:
> When running with debug on you can see lots of 'Read() 0' logged out when the broker is killed. This is due to the NetworkStream returning 0 instantly as described in the API docs, as a result of the socket being gracefully shutdown. Unfortunately it is still possible to send data without an exception so sends can be lost.
> Proposed Changes:
> If we get 0 bytes being read from the NetworkStream we can block sends and shutdown the socket which will cause failover to occur in the next read loop.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (QPID-952) .NET NetworkStream does not
immediately detect connection failure.
Posted by "Robert Greig (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591620#action_12591620 ]
Robert Greig commented on QPID-952:
-----------------------------------
Can you not call DataAvailable before reading?
"If the remote host shuts down or closes the connection, DataAvailable throws a SocketException".
Or what does CanRead return when the remote host has closed the connection?
> .NET NetworkStream does not immediately detect connection failure.
> ------------------------------------------------------------------
>
> Key: QPID-952
> URL: https://issues.apache.org/jira/browse/QPID-952
> Project: Qpid
> Issue Type: Bug
> Components: Dot Net Client
> Affects Versions: M1, M2, M2.1
> Reporter: Martin Ritchie
>
> Summary:
> The NetworkStream used by the Blocking IO does not immediately report the underlying socket connection failure. It can take up to 20 seconds before this is reported. According to the API:
> http://msdn2.microsoft.com/en-us/library/system.net.sockets.networkstream.read(VS.71).aspx
> The Read call only returns zero when the connection has been closed. So we can close the underlying socket which will stop all sends and force an exception on the next read attempt. This in turn will cause failover to be triggered.
> Defect Identification:
> When running with debug on you can see lots of 'Read() 0' logged out when the broker is killed. This is due to the NetworkStream returning 0 instantly as described in the API docs, as a result of the socket being gracefully shutdown. Unfortunately it is still possible to send data without an exception so sends can be lost.
> Proposed Changes:
> If we get 0 bytes being read from the NetworkStream we can block sends and shutdown the socket which will cause failover to occur in the next read loop.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (QPID-952) .NET NetworkStream does not
immediately detect connection failure.
Posted by "Robert Greig (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12592075#action_12592075 ]
Robert Greig commented on QPID-952:
-----------------------------------
erm ok, then I suggest you try DataAvailable.
> .NET NetworkStream does not immediately detect connection failure.
> ------------------------------------------------------------------
>
> Key: QPID-952
> URL: https://issues.apache.org/jira/browse/QPID-952
> Project: Qpid
> Issue Type: Bug
> Components: Dot Net Client
> Affects Versions: M1, M2, M2.1
> Reporter: Martin Ritchie
>
> Summary:
> The NetworkStream used by the Blocking IO does not immediately report the underlying socket connection failure. It can take up to 20 seconds before this is reported. According to the API:
> http://msdn2.microsoft.com/en-us/library/system.net.sockets.networkstream.read(VS.71).aspx
> The Read call only returns zero when the connection has been closed. So we can close the underlying socket which will stop all sends and force an exception on the next read attempt. This in turn will cause failover to be triggered.
> Defect Identification:
> When running with debug on you can see lots of 'Read() 0' logged out when the broker is killed. This is due to the NetworkStream returning 0 instantly as described in the API docs, as a result of the socket being gracefully shutdown. Unfortunately it is still possible to send data without an exception so sends can be lost.
> Proposed Changes:
> If we get 0 bytes being read from the NetworkStream we can block sends and shutdown the socket which will cause failover to occur in the next read loop.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-952) .NET NetworkStream does not immediately
detect connection failure.
Posted by "Marnie McCormack (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marnie McCormack updated QPID-952:
----------------------------------
Fix Version/s: (was: M4)
> .NET NetworkStream does not immediately detect connection failure.
> ------------------------------------------------------------------
>
> Key: QPID-952
> URL: https://issues.apache.org/jira/browse/QPID-952
> Project: Qpid
> Issue Type: Bug
> Components: Dot Net Client
> Affects Versions: M1, M2, M2.1
> Reporter: Martin Ritchie
>
> Summary:
> The NetworkStream used by the Blocking IO does not immediately report the underlying socket connection failure. It can take up to 20 seconds before this is reported. According to the API:
> http://msdn2.microsoft.com/en-us/library/system.net.sockets.networkstream.read(VS.71).aspx
> The Read call only returns zero when the connection has been closed. So we can close the underlying socket which will stop all sends and force an exception on the next read attempt. This in turn will cause failover to be triggered.
> Defect Identification:
> When running with debug on you can see lots of 'Read() 0' logged out when the broker is killed. This is due to the NetworkStream returning 0 instantly as described in the API docs, as a result of the socket being gracefully shutdown. Unfortunately it is still possible to send data without an exception so sends can be lost.
> Proposed Changes:
> If we get 0 bytes being read from the NetworkStream we can block sends and shutdown the socket which will cause failover to occur in the next read loop.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (QPID-952) .NET NetworkStream does not
immediately detect connection failure.
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591981#action_12591981 ]
ritchiem edited comment on QPID-952 at 4/24/08 5:51 AM:
--------------------------------------------------------------
Did _NOT_ try DataAvailable but CanRead just returned true.
was (Author: ritchiem):
Did try DataAvailable but CanRead just returned true.
> .NET NetworkStream does not immediately detect connection failure.
> ------------------------------------------------------------------
>
> Key: QPID-952
> URL: https://issues.apache.org/jira/browse/QPID-952
> Project: Qpid
> Issue Type: Bug
> Components: Dot Net Client
> Affects Versions: M1, M2, M2.1
> Reporter: Martin Ritchie
>
> Summary:
> The NetworkStream used by the Blocking IO does not immediately report the underlying socket connection failure. It can take up to 20 seconds before this is reported. According to the API:
> http://msdn2.microsoft.com/en-us/library/system.net.sockets.networkstream.read(VS.71).aspx
> The Read call only returns zero when the connection has been closed. So we can close the underlying socket which will stop all sends and force an exception on the next read attempt. This in turn will cause failover to be triggered.
> Defect Identification:
> When running with debug on you can see lots of 'Read() 0' logged out when the broker is killed. This is due to the NetworkStream returning 0 instantly as described in the API docs, as a result of the socket being gracefully shutdown. Unfortunately it is still possible to send data without an exception so sends can be lost.
> Proposed Changes:
> If we get 0 bytes being read from the NetworkStream we can block sends and shutdown the socket which will cause failover to occur in the next read loop.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.