[SERVER-8195] Observed timeouts don't correspond to db.serverStatus().cursors.timedOut Created: 16/Jan/13 Updated: 15/Feb/13 Resolved: 16/Jan/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 2.2.2 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Arkadiy Kukarkin | Assignee: | Barrie Segal |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Operating System: | ALL | ||||
| Participants: | |||||
| Description |
|
The docs here http://docs.mongodb.org/manual/reference/server-status/ say that cursors.timedOut is "[the] total number of cursors that have timed out since the server process started", but I can see dozens of MongoCursorTimeoutException errors (php) scroll by without increasing the count. Is it still sampled/unreliable in 2.2.2? We have 2 shards of 3 machines each, but only one has a non-zero timedOut value (<10). I will see php report timeouts in bursts of 20-30, for different queries. Can this mean that the timeouts are happening in a way that does not actually hit the server? |
| Comments |
| Comment by Scott Hernandez (Inactive) [ 16/Jan/13 ] |
|
Yes, that sounds correct. The server supports no query timeout (what client do is set a socket read/write timeout which is very different and generally bad wrt/server), and the server only cleans up cursors not used in 10 minutes (if the NoTimeout flag was not used during its creation). |
| Comment by Arkadiy Kukarkin [ 16/Jan/13 ] |
|
Scott, am I correct in understanding that the serverStatus().cursors.timedOut value counts cursors timed out by the server after 10 minutes of inactivity (and without noTimeout set), while MongoCursorTimeoutException refers to queries closed by the client after $MongoCursor::timeout ms? This is an extremely confusing exception name, especially considering that in other drivers the query timeout is a property on the connection (I understand why it can be useful to change the timeout values per cursor, though) |
| Comment by Scott Hernandez (Inactive) [ 16/Jan/13 ] |
|
The cursor timeout exception is on the client (socket read timeout really) and not the same as the server-side timeouts (from unused cursors). The client exception could be better named to make that clear, but the docs are fairly clear this is a read timeout waiting for results from the server: http://us1.php.net/manual/en/class.mongocursortimeoutexception.php |