[CSHARP-914] Possibility to Created: 20/Feb/14  Updated: 21/Nov/14  Resolved: 20/Mar/14

Status: Closed
Project: C# Driver
Component/s: None
Affects Version/s: 1.8.3
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: Dmitry Naumov Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to CSHARP-138 Add asynchronous APIs Closed

 Description   

It's not possible to cancel executing query. The problem relates to both MongoQueryable and MongoCollection methods. Based on assumption that 3rd party tools can "kill" connection and corresponding query, it would be nice to have methods like Close on MongoCursor, for example.

The use case is the following:
Incoming HTTP request is processed and query is executed. But, for example, query takes long time and user closes or refreshes browser. But unfortunately the query still executes and consumes resources. There is no way to reach underlying connection, on which query executes, and close it.



 Comments   
Comment by Craig Wilson [ 21/Nov/14 ]

You're welcome to look at our master branch. We are working as fast as we can.

Just to note, it is virtually impossible to kill an inflight where the server hasn't yet responded from the driver automatically. Async will release the local resources because while we are waiting for the response, no thread is being used. However, a connection is still checked out even though a thread isn't currently in use. Killing that connection is a really bad idea. Connections are pooled and are expensive resources to create. So, to simply kill off an expensive resource because you want to free it up doesn't make a lot of sense.

Regardless, I'd look at your queries and get them executing in under a second. I can't think of a good reason why a 30 second query would be acceptable.

Comment by Dmitry Naumov [ 21/Nov/14 ]

Craig,
is it possible to take part/contribute in development of this feature? It become very urgent for me and the only possible workaround I see is to do reflection-based hacks with QueryOperation and ConnectionProvider...

Comment by Craig Wilson [ 20/Mar/14 ]

Hi Dmitry,

I understand what you are saying. The way to accomplish this will be to use the async implementation coming in 3.0, as it will correctly handle dealing connection management in cases like this. As such, I'm going to close this as Works as Designed and you should watch CSHARP-138 for updates.

Thanks,
Craig

Comment by Dmitry Naumov [ 20/Feb/14 ]

Craig, I'm not very familar with server implementation, but I expect that it correctly handles closing incoming connection. Actually I see this expected behavior when I kill connection using 3rd party tools. I looked into C# driver to find something which connects MongoCursor and underlying connection used for this query, but quickly understood that it is not easy is I hoped. That's why I have no pull request to offer...

Of cource $maxTime would be great in some cases, but not in all. Let's say I have query which usually takes up to N (let's say 30) seconds to complete and that's fine. I can set $maxTime for, let's say, 35 seconds. But when running this query I understand that results are not needed any more (for example because external http connection was closed by user) and this happens on first second of query execution, I don't want to wait 35 - 1 = 34 seconds more wasting my resources...

Comment by Craig Wilson [ 20/Feb/14 ]

Hi Dmitry, thanks for the request. I'm going to put down some thoughts for discussion.

First, server 2.6 and driver 1.9 will be supporting something called $maxTime. You can see information about it here: https://jira.mongodb.org/browse/SERVER-2212
Second, if we were to do this on the client side, it would force us to either close the connection entirely or keep it open in the background to read what the server is sending us over the wire. This would require some thought and might not even be possible in all cases...

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