[ 
https://issues.apache.org/jira/browse/IGNITE-15389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Lapin updated IGNITE-15389:
-------------------------------------
    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: 
{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.

 

*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.

  was:
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.


> 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.
>  
> *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.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to