arangodb / arangodb-java-driver

When watching documents from the server using a cursor, this works fine if not reading to the end or the result size is below the batch size.

When fetching multiple bulks including the last, it seems the server closes the cursor itself and ArangoCursorImpl.close() tries this again resulting in a server error. It seems the allowRetry set to true in the constructor leads to an unused close()-call even it the result has no more documents.

Relates to DE-511 #505

If the enforced close is needed for retry, maybe passing the flag to the constructor directly from the options.getOptions().getAllowRetry() in ArangoDatabaseImpl.createCursor() would have less side effects.

sorry, just saw, this seems to be a duplicate of #528

But anyway, @rashtao wouldn't it be better to force close of the cursor only if the query option is set (just to optimise useless server roundtrips)?

Hi @aburmeis ,
thanks for reporting this.

When closing the cursor, the closing request is sent only if the following condition is met:

arangodb-java-driver/core/src/main/java/com/arangodb/internal/cursor/ArangoCursorImpl.java

Line 59 in 2953335

if (getId() != null && (allowRetry || iterator.result.getHasMore())) {

and I think this is OK.

But the real problem is the (wrong) way used to derive allowRetry:

arangodb-java-driver/core/src/main/java/com/arangodb/internal/cursor/ArangoCursorImpl.java

Line 54 in 2953335

this.allowRetry = result.getNextBatchId() != null;

since also non-retriable AQL cursors could return the nextBatchId attribute.

To fix it, allowRetry should be set based on the AQL cursor creation options.

This needs to be fixed both in ArangoCursorImpl and ArangoCursorAsyncImpl.

Cursor with multiple batches is closed twice