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)