Description
The initiating cursor operation can be processed in the same thread as the cursor.hasNext() cursor.next(), etc, which, due to its synchronous nature, can block the processing of the response from the server that should complete the initiating operation.
In other words:
metaStorageMgr.range(...)
internally will call org.apache.ignite.raft.client.service.impl.RaftGroupServiceImpl#sendWithRetry
where raft command response within
fut0.whenComplete(...)
could be blocked with upcomming
cursor.hasNext(), cursor.next(), cursor.close() if it's processed within same thread.
Below, there is snippet of hasNext() where we await future result here synchronously.
initOp.thenCompose(
cursorId -> metaStorageRaftGrpSvc.run(new CursorCloseCommand(cursorId))).get();
Similar issue is https://issues.apache.org/jira/browse/IGNITE-15272
It worth to mention that Cursor extends Iterator that has synchronous operations by design.
Upd 1
Meta storage cursors will be completely reworked based on new non-raft reads, watches will be also reworked to be a local ones based on ms over learners approach. Thus given ticket seems to be obsolete.
Attachments
Issue Links
- is blocked by
-
IGNITE-15434 Implement cursor for partitions
-
- Resolved
-
- is fixed by
-
IGNITE-18397 Rework Watches based on learners
-
- Resolved
-
- is related to
-
IGNITE-18328 SQL query may hangs forever.
-
- Open
-
-
-
- Open
-
- links to
