[
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)
