[JAVA-4849] MongoException: next() called after the cursor was closed Created: 18/Jan/23 Updated: 28/Oct/23 Resolved: 03/Feb/23 |
|
| Status: | Closed |
| Project: | Java Driver |
| Component/s: | None |
| Affects Version/s: | 4.8.0 |
| Fix Version/s: | 4.9.0 |
| Type: | Question | Priority: | Major - P3 |
| Reporter: | Sam Weston | Assignee: | Ross Lawley |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
| Comments |
| Comment by Githook User [ 03/Feb/23 ] | ||||||||||||||||||||
|
Author: {'name': 'Ross Lawley', 'email': 'ross.lawley@gmail.com', 'username': 'rozza'}Message: Ensure BatchCursorFlux does not drop an error The BatchCursor class can be closed by the BatchCursorFlux class This leads to a next() called after the cursor was closed error and
| ||||||||||||||||||||
| Comment by Sam Weston [ 01/Feb/23 ] | ||||||||||||||||||||
|
Thanks Ross, we really appreciate you looking in to it. | ||||||||||||||||||||
| Comment by Ross Lawley [ 01/Feb/23 ] | ||||||||||||||||||||
|
Hi sam@unlikely.ai,
Its the first report we've had of this scenario, so I would say its a little unusual or just under reported. However, I can see our use of the BatchCursor here allows it to signal an error that ends up being dropped. I was able to determine the cause and look to have a fix in the next release. Ross | ||||||||||||||||||||
| Comment by Sam Weston [ 01/Feb/23 ] | ||||||||||||||||||||
|
Hi Ross, Thank you very much for looking into this for us. I understand the explanation and it's reassuring to know it's not functionally affecting the code. The error seems a little trigger-happy, is it not a fairly standard scenario to kick off a series of requests and then cancel some of them before they return? How do you suggest dealing with this, should I silence this particular error since it's always a false alarm? For context, we need the nesting and would like to keep things general, so putting the
at the lower level is not ideal. I do very much appreciate the suggested fixes though. Many thanks, | ||||||||||||||||||||
| Comment by Ross Lawley [ 31/Jan/23 ] | ||||||||||||||||||||
|
Hi sam@unlikely.ai, Interesting question! And as often with async your code has uncovered a race condition, which results in an error being logged. The race condition is due to more data being requested from MongoDB than required and then cancelling the subscription. This ends up with the cursor being closed while data has been requested from MongoDB and then once the data has returned the error is logged. It is just a side effect and shouldn't impact the correctness of the code. Why this happens is slightly in the weeds:
.flatMap(collection -> Flowable.fromPublisher(collection.find(bsonFilter))) ends up requesting 128 results from the publisher due to using rxJava's default buffer size. The following code (non nested) does not report an error because the downstream request to the MongoDB driver is always one.
If you force the MongoDB find publisher to only return a single item it removes the demand race condition even if its nested.
Note: collection.find(bsonFilter).first() will essentially return a Single rather than an unbound Observable. I hope that helps, Kind regards, Ross | ||||||||||||||||||||
| Comment by Esha Bhargava [ 20/Jan/23 ] | ||||||||||||||||||||
|
sam@unlikely.ai Thank you for reporting this issue. We'll look into it and get back to you soon. |