[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
Client - Windows Server 2012


Issue Links:
Depends
depends on CSHARP-1200 Support cancellation of operations on... Backlog

 Description   

I run long Count operation (sync version), that use 10 sec query (in this case its normal).
We can't use async version for some reasons.

...
 
cancellationTokenSource.CancelAfter(1000);
 
GetCollection<SomeModel>("SomeModel").Count(filter, cancellationTokenSource.Token)

But Сount whatever takes 10 seconds. Why it is not cancelling ?
Or it check it only before start ?
I know about MaxTime, but we need to set time limit for many operations and this bug cause use us bad design code.



 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.

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