[
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.
