Info

I’ve had two Ruby tickets reporting that a user gets a cursor id not found error with the latest version of the server and the Ruby driver. I’ve been able to reproduce it (see below for code and logs). Here are the details: The query is done with read preference secondaryPreferred The query has noCursorTimeout set to true The query uses an implicit session The sequence of operations is: find (success), getmore (success), getmore (failure/no cursor id found) As the user iterates over the query results, there is sometimes a few minutes between getMore requests. This value has been 7 minutes and 10 minutes. I confirmed that: The driver is indeed setting noCursorTimeout on the query The same lsid is being used for the original find and following getMores Neither the cursor nor the session are being prematurely ended before the getMore failure. (no endSessions commands or killCursors commands found in the logs) I can provide the user's primary and secondary logs, as well as application logs. Here are the Ruby tickets: RUBY-1312, RUBY-1318 I was able to reproduce this with the following Ruby code: https://gist.github.com/estolfo/f6a46b68fdf3db9be102ba2236e7abd5 This is the driver log: https://gist.github.com/estolfo/1bc93c544e25b71678d9389a306f5292

Top User Comments

misha.tyulenev commented on Wed, 2 May 2018 21:07:26 +0000: Thanks david.storch! Its hard to say if its a dup without looking at the reproducible test case. The major difference is that SERVER-34810 is an intermittent issue while this one seems to be reproducible. Ill look more into it and get back, it might be related to LogicalSessionCache refresh logic. david.storch commented on Wed, 2 May 2018 19:45:00 +0000: misha.tyulenev, I found SERVER-34810 by diagnosing a build failure. Is there any chance that this ticket has the same root cause? misha.tyulenev commented on Tue, 1 May 2018 20:45:20 +0000: emily.stolfo could you please clarify why the find command does not have clusterTime in it? is this the first command? https://gist.github.com/estolfo/1bc93c544e25b71678d9389a306f5292#file-no_cursor_found_driver_logs-rb-L98  The command that succeeds https://gist.github.com/estolfo/1bc93c544e25b71678d9389a306f5292#file-no_cursor_found_driver_logs-rb-L112 has the cluster time. Not that it should batter but it shows that the tests were not done identically. Thanks! misha.tyulenev commented on Fri, 13 Apr 2018 20:47:25 +0000: Hi pavel.duchovny could you please include server logs? Thanks! charlie.swanson commented on Fri, 23 Mar 2018 15:07:43 +0000: Moving this over to the Sharding backlog because we suspect the issue is caused by a session timeout. It's unclear to the query team if it's a driver issue or a server issue. emily.stolfo@10gen.com commented on Thu, 22 Mar 2018 03:12:39 +0000: Hi david.storch I patched the driver to not associate a session with the find and getmore operations and did not get the error with read preference secondaryPreferred. I've added the test log in the gist. david.storch commented on Wed, 21 Mar 2018 22:12:07 +0000: Thanks, Emily. I currently suspect that this is related to the session getting killed. Is it possible for you to run the repro in such a way that the cursor does not belong to a logical session? If the problem no longer repros, that would help bolster my case. emily.stolfo@10gen.com commented on Wed, 21 Mar 2018 21:52:58 +0000: I am testing against version 3.6.3. I've just tested with read preference primary and I did not get the cursor not found error. I've added the driver logs to the bottom of the gist. david.storch commented on Wed, 21 Mar 2018 21:35:32 +0000: emily.stolfo, against which versions of the server can you reproduce the problem? Does your Ruby script continue to reproduce the problem when the cursor is open on the primary instead of a secondary? alberto.ornaghi@gmail.com commented on Wed, 21 Mar 2018 21:30:20 +0000: Hi, i'm the reporter of RUBY-1312, i can also add that the same issue manifested on a standalone machine (diffrent schema, same mongodb and mongo-driver versions), so it's not strictly related to the secondarPreferred option.

Steps to Reproduce