[
https://issues.apache.org/jira/browse/IGNITE-15389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-15389:
--------------------------------------------
Assignee: Vyacheslav Koptilin (was: Alexander Lapin)
> org.apache.ignite.internal.metastorage.client.CursorImpl has potential
> deadlock inside
> --------------------------------------------------------------------------------------
>
> Key: IGNITE-15389
> URL: https://issues.apache.org/jira/browse/IGNITE-15389
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexander Lapin
> Assignee: Vyacheslav Koptilin
> Priority: Major
> Labels: ignite-3
>
> 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:
> {code:java}
> metaStorageMgr.range(...)
> {code}
> internally will call
> org.apache.ignite.raft.client.service.impl.RaftGroupServiceImpl#sendWithRetry
> where raft command response within
> {code:java}
> fut0.whenComplete(...){code}
> 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.
> {code:java}
> initOp.thenCompose(
> cursorId -> metaStorageRaftGrpSvc.run(new
> CursorCloseCommand(cursorId))).get();
> {code}
>
> 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.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
