[JAVA-2538] MongoCursorNotFoundException almost immediately after query. Created: 14/Jun/17  Updated: 27/Oct/23  Resolved: 14/Jun/17

Status: Closed
Project: Java Driver
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Min Choi Assignee: Unassigned
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

CentOS 7 with sharded cluster running mongo 3.4



 Description   

Hello,

We are getting MongoCursorNotFoundException almost immediately (about 1-2 seconds) after running a find query. To give a little more info, in our code we run a find and then grab the iterator from the FindIterable and run through the items in a while loop.

I put in some logs and found that after the find is run, while it's looping through, after 01.670seconds, it threw the exception below. 10 minutes after this occurs, in the mongos logs the cursor is closed for idle timeout.

The only thing I can think of for a possible cause is, we have 6 machines that have mongos running and each of the application servers use a round robin styled DNS resolver to resolve the mongos URL. Would this setup cause a problem for the mongo connection?

Stacktrace:

Caused by: com.mongodb.MongoCursorNotFoundException: Query failed with error code -5 and error message 'Cursor 692999830626020539 not found on server mongos:27276' on server mongos:27276
at com.mongodb.operation.QueryHelper.translateCommandException(QueryHelper.java:27)
at com.mongodb.operation.QueryBatchCursor.getMore(QueryBatchCursor.java:213)
at com.mongodb.operation.QueryBatchCursor.hasNext(QueryBatchCursor.java:103)
at com.mongodb.MongoBatchCursorAdapter.hasNext(MongoBatchCursorAdapter.java:46)

Please let me know if you need any additional information.



 Comments   
Comment by Min Choi [ 14/Jun/17 ]

Thanks for the quick reply. I'll look into this.

Comment by Jeffrey Yemin [ 14/Jun/17 ]

Hi Min,

Yes, your load balancer configuration is the likely culprit. Please see the MongoDB documentation for Production Configuration, which states:

You can deploy a mongos router on each application server to ensure each server has consistent access to the sharded cluster. Alternatively, deploy a group of mongos routers and use a proxy or load balancer between the application and the mongos group. In these deployments, you must configure the load balancer for client affinity such that every connection from a single client reaches the same mongos.

Generated at Thu Feb 08 08:57:29 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.