[ https://issues.apache.org/jira/browse/IGNITE-15389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexander Lapin resolved IGNITE-15389. -------------------------------------- Resolution: Won't Fix > 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: Bug > Reporter: Alexander Lapin > Assignee: Alexander Lapin > Priority: Major > Labels: ignite-3, tech-debt > Time Spent: 10m > Remaining Estimate: 0h > > 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.10#820010)