-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Fix CursorResourceManager.close
#1440
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 2 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -45,6 +45,7 @@ | |
import java.util.ArrayList; | ||
import java.util.List; | ||
import java.util.concurrent.CountDownLatch; | ||
import java.util.concurrent.ForkJoinPool; | ||
import java.util.concurrent.TimeUnit; | ||
import java.util.concurrent.atomic.AtomicInteger; | ||
import java.util.stream.Collectors; | ||
|
@@ -299,6 +300,24 @@ void testLimitWithGetMore() { | |
assertTrue(cursor.isClosed()); | ||
} | ||
|
||
@Test | ||
void attemptJava5516() { | ||
BsonDocument commandResult = executeFindCommand(5, 2); | ||
cursor = new AsyncCommandBatchCursor<>(commandResult, 2, 0, DOCUMENT_DECODER, | ||
null, connectionSource, connection); | ||
assertNotNull(cursorNext()); | ||
// Calling `close` twice is the key to reproducing. | ||
// It does not matter whether we call `close` twice from the same thread or not. | ||
ForkJoinPool.commonPool().execute(() -> cursor.close()); | ||
ForkJoinPool.commonPool().execute(() -> cursor.close()); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The issue this PR fixes is 100% a bug. And it manifests itself with an error that is very similar to the user-reported error (following is the error I reproduced locally):
However, none of this guarantees that the bug the PR fixes is the bug the user is facing, because theoretically, I can imagine other bugs leading to the same error. However, I was unable to find them in our code, so I am saying that the fix proposed in this PR is my current best solution to JAVA-5516. |
||
try { | ||
assertNotNull(cursorNext()); | ||
assertNotNull(cursorNext()); | ||
} catch (IllegalStateException e) { | ||
// one of the expected outcomes, because we call `cursorNext` concurrently with `close` | ||
} | ||
} | ||
|
||
@Test | ||
@DisplayName("test limit with large documents") | ||
void testLimitWithLargeDocuments() { | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem with the original code:
If
AsyncCommandBatchCursor.close
is called concurrently more than once whileAsyncCommandBatchCursor.next
is running (not necessarily thenext
method itself, but the asynchronous logic of this method), then the following state transitions were possible:close
calls observesState.OPERATION_IN_PROGRESS
, and changes it toState.CLOSE_PENDING
. So far so good.close
observesState.CLOSE_PENDING
and changes it toState.CLOSED
, which breaks one of the invariant that are supposed to be maintained byCursorResourceManager
: while an operation is in progress,state.inProgress()
must betrue
, i.e.,state
must be eitherOPERATION_IN_PROGRESS
orCLOSE_PENDING
(impliesOPERATION_IN_PROGRESS
).