You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Alexander Lapin (Jira)" <ji...@apache.org> on 2021/08/27 16:07:00 UTC

[jira] [Created] (IGNITE-15389) org.apache.ignite.internal.metastorage.client.CursorImpl has potential deadlock inside

Alexander Lapin created IGNITE-15389:
----------------------------------------

             Summary: 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
         Environment: [link title|http://example.com][link title|http://example.com]
            Reporter: Alexander Lapin


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.3.4#803005)