[JAVA-3850] ChangeStream Publisher's cursor does not closed after .cancel() Created: 27/Sep/20  Updated: 01/Jun/22  Resolved: 08/Dec/20

Status: Closed
Project: Java Driver
Component/s: Change Streams, Reactive Streams
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Ricky Chen Assignee: Ross Lawley
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

MongoDB 4.0.12, org.mongodb:mongodb-driver-reactivestreams:4.0.5


Attachments: Java Source File test_app.java    
Issue Links:
Depends
depends on JAVA-3813 Replace internal use of callbacks wit... Closed

 Description   

We start a Change Stream Publisher on a collection.

Do not execute any operation on this collection at that time.

The AsyncChangeStreamBatchCursor would call getMore command every second.

Now we invoke subscription.cancel() method.

The AsyncChangeStreamBatchCursor should be closed, but it doesn't.

The property isOperationInProgress == true , isClosePending == true and the Cursor continue in getMore loop, never closed.

 



 Comments   
Comment by Ross Lawley [ 08/Dec/20 ]

Fixed and pending release in 4.2.0

Comment by Jeffrey Yemin [ 30/Nov/20 ]

We're very close on JAVA-3813 but we're not planning to backport that to 3.12.x. It's going to require an upgrade to 4.2.0.

Comment by João Ferreira [ 30/Nov/20 ]

Hi Ross.

Any workaround while JAVA-3813 is not ready yet? I am facing this issue using mongo-scala-driver:2.8.0 and mongodb-driver-async:3.12.7.

Comment by Ross Lawley [ 20/Nov/20 ]

This will be fixed as part of the JAVA-3813 work.

Comment by Ross Lawley [ 06/Oct/20 ]

Hi a471558277@gmail.com,

Thanks for the repro of the issue, I now understand the cause. The changestream is pending a result back from the server before closing - this is due to it internally implementation using cursor.next rather than cursor.tryNext.

Scheduling to be fixed.

Ross

Comment by Ricky Chen [ 30/Sep/20 ]

test_app.java

This is my example. It can reproduce the problem on my shard MongoDB cluster, which has 100+ nodes.

Log:

> Task :App.main()
execute aggregate on connectionId{localValue:7}:MongoS:27017
execute getMore on connectionId{localValue:7}:MongoS:27017
execute getMore on connectionId{localValue:7}:MongoS:27017
execute getMore on connectionId{localValue:7}:MongoS:27017
execute getMore on connectionId{localValue:7}:MongoS:27017
execute getMore on connectionId{localValue:7}:MongoS:27017
execute getMore on connectionId{localValue:7}:MongoS:27017
execute getMore on connectionId{localValue:7}:MongoS:27017
execute getMore on connectionId{localValue:7}:MongoS:27017
execute getMore on connectionId{localValue:7}:MongoS:27017
execute getMore on connectionId{localValue:7}:MongoS:27017
execute getMore on connectionId{localValue:7}:MongoS:27017
execute getMore on connectionId{localValue:7}:MongoS:27017
execute getMore on connectionId{localValue:7}:MongoS:27017
execute getMore on connectionId{localValue:7}:MongoS:27017
execute getMore on connectionId{localValue:7}:MongoS:27017
execute getMore on connectionId{localValue:7}:MongoS:27017
execute getMore on connectionId{localValue:7}:MongoS:27017
execute getMore on connectionId{localValue:7}:MongoS:27017
execute getMore on connectionId{localValue:7}:MongoS:27017
onComplete.
await stop.
Subscription cancel.
execute getMore on connectionId{localValue:7}:MongoS:27017
execute getMore on connectionId{localValue:7}:MongoS:27017
execute getMore on connectionId{localValue:7}:MongoS:27017
execute getMore on connectionId{localValue:7}:MongoS:27017
execute getMore on connectionId{localValue:7}:MongoS:27017

Comment by Ross Lawley [ 29/Sep/20 ]

Hi Ricky Chen,

Many thanks for the ticket. Could you provide more detail on the bug? Either a full stacktrace or a test case to reproduce the error. Ideally, a minimal reproducible example  as I could replicate the bug and use it as a test case for the fix.

All the best,

Ross

Generated at Thu Feb 08 09:00:35 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.