You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Aleksey Plekhanov (Jira)" <ji...@apache.org> on 2023/04/20 14:04:00 UTC

[jira] [Updated] (IGNITE-17964) Potential deadlock in discovery thread while updating SQL statistics.

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

Aleksey Plekhanov updated IGNITE-17964:
---------------------------------------
    Release Note: Fixed potential deadlock in discovery thread while updating SQL statistics

> Potential deadlock in discovery thread while updating SQL statistics.
> ---------------------------------------------------------------------
>
>                 Key: IGNITE-17964
>                 URL: https://issues.apache.org/jira/browse/IGNITE-17964
>             Project: Ignite
>          Issue Type: Bug
>          Components: sql
>            Reporter: Andrey Mashenkov
>            Assignee: Andrey Mashenkov
>            Priority: Major
>             Fix For: 2.15
>
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> On node start/activation IgniteStatisticsConfigurationManager initializes and tries to cleanup orphaned records (e.g. for tables, which were dropped before node stop/crash).
> To do that *stat-mgmt* thread updates distributed metastorage synchronously under the read-lock.
> Underneath, metastorage sends a request via discovery, then 
> discovery component gets the answer on that message, and gets stuck trying to get the write-lock to complete the future... 
> So, *stat-mgmt* and *disco-notify* threads fall into inevitable deadlock.
> We should avoid any synchronous operation on distributed metastorage under the read-lock.
> Let’s rewrite synchronous CAS deep inside the closure (see IgniteStatisticsConfigurationManager.updateLocalStatistics) to async CAS and pull it's future up to outside the closure and the read-lock.



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