[CSHARP-1200] Support cancellation of operations once network I/O has begun Created: 20/Mar/15  Updated: 31/Mar/22

Status: Backlog
Project: C# Driver
Component/s: Connectivity
Affects Version/s: 2.0
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Robert Stam Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by CSHARP-1983 Count operation ignored CancellationT... Closed
Case:

 Description   

All our operations support cancellation via a CancellationToken.

However, once an operation begins sending or receiving a message over the network we no longer support cancellation until the network I/O completes. It is likely that callers would expect a cancellation request to interrupt the pending network I/O.

The reason we don't support cancellation once network I/O has begun is that we don't want to leave the connection in a damaged state, such as with a half written or half read message. While we don't yet support pipelining (sharing the same connection among multiple tasks), any future support for pipelining would depend on tasks sharing the connection never leaving the connection in a damaged state.

So any implementation of this ticket would have to ensure that cancelling an operation is done in a way that doesn't damage the connection.



 Comments   
Comment by Alejandro Villarreal [ 31/Jan/18 ]

Just to add something for discussion when this gets implemented (which I assume probably needs full support for cancellation tokens in the underlying .NET NetworkStream class), in relation to Robert Stam's comments in CSHARP-1983. I understand that cancelling the operation on the client while the server keeps doing work is not ideal, but in my case I ran into a scenario where sometimes the server seems to not receive the request at all, yet the client still hangs and ignores timeouts, until 15 minutes later when the socket times out (I'm not sure where those 15 minutes come from) and an exception is thrown. I can't figure out what exactly happens in the network to cause this scenario, and it's probably less common that just wanting to restrict the amount of time a running operation takes, but I thought it could be part of the discussion.

Generated at Wed Feb 07 21:38:57 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.