You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@bahir.apache.org by "Dominik Wosiński (JIRA)" <ji...@apache.org> on 2018/08/30 13:09:00 UTC

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

Dominik Wosiński created BAHIR-177:
--------------------------------------

             Summary: 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


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)