[CSHARP-1983] Count operation ignored CancellationToken Created: 10/May/17 Updated: 27/Oct/23 Resolved: 29/Oct/17 |
|
| Status: | Closed |
| Project: | C# Driver |
| Component/s: | API |
| Affects Version/s: | 2.3 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Ivan Artemov | Assignee: | Robert Stam |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Server - Ununtu 16.x |
||
| Issue Links: |
|
||||||||
| Description |
|
I run long Count operation (sync version), that use 10 sec query (in this case its normal).
But Сount whatever takes 10 seconds. Why it is not cancelling ? |
| Comments |
| Comment by Robert Stam [ 16/May/17 ] |
|
In general you should try to find a solution that uses MaxTime. Abandoning an operation without reading the reply from the server would require closing the socket because that connection would no longer be usable for other operations. However, even closing the socket doesn't cause the server to cancel the operation. The server will continue to execute the operation, however long that takes, only to find at the end of all that work that it can no longer send the reply because the client closed the socket. |
| Comment by Robert Stam [ 16/May/17 ] |
|
This most likely related to this ticket: https://jira.mongodb.org/browse/CSHARP-1200 The description of that ticket reads: 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. |