You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bahir.apache.org by "Luciano Resende (JIRA)" <ji...@apache.org> on 2019/05/19 12:42:00 UTC

[jira] [Assigned] (BAHIR-177) Siddhi Library state recovery causes an Exception

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

Luciano Resende reassigned BAHIR-177:
-------------------------------------

    Assignee: Dominik Wosiński

> Siddhi Library state recovery causes an Exception
> -------------------------------------------------
>
>                 Key: BAHIR-177
>                 URL: https://issues.apache.org/jira/browse/BAHIR-177
>             Project: Bahir
>          Issue Type: Bug
>            Reporter: Dominik Wosiński
>            Assignee: Dominik Wosiński
>            Priority: Blocker
>             Fix For: Flink-Next
>
>
> Currently, Flink offers a way to store state and this is utilized for Siddhi Library. The problem is that Siddhi internally bases on operators IDs that are generated automatically when the _SiddhiAppRuntime_ is initialized. This means that if the job is restarted and new operators IDs are assigned for Siddhi, yet the Flink stores states with old ID's. 
> Siddhi uses an operator ID to get state from Map :
> _snapshotable.restoreState(snapshots.get(snapshotable.getElementId()));_
> Siddhi does not make a null-check on the retrieved values, thus _restoreState_ throws an NPE which is caught and _CannotRestoreSiddhiAppStateException_ is thrown instead. Any flink job will go into infinite loop of restarting after facing this issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)