[
https://issues.apache.org/jira/browse/BAHIR-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16842628#comment-16842628
]
ASF GitHub Bot commented on BAHIR-177:
--------------------------------------
asfgit commented on pull request #51: [BAHIR-177] Fixed state recovery for
Flink and fixed size of the reco…
URL: https://github.com/apache/bahir-flink/pull/51
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> 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
>
> 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)
