[
https://issues.apache.org/jira/browse/FLINK-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16729516#comment-16729516
]
TisonKun edited comment on FLINK-10333 at 1/4/19 2:20 AM:
----------------------------------------------------------
Following the ZK transaction idea, I drafted a design doc on how we rework ZK
based stores to achieve atomicity.
Mainly we will re-implement leader election service to get the
{{election-node-path}}. It could be done by porting the implementation of
{{LeaderLatch}} in Curator to Flink. Then we generate dispatcher/jm/rm's
{{session id}} based on {{election-node-path}}, and when communicate with ZK,
we pass the {{session id}}, which underneath converted to the
{{election-node-path}} to ensure that the caller is the leader, just as code
snipper above.
Subtasks can be separated as
# re-layout zookeeper content
# re-implement ZK leader election, expose election node path, which can be
converted to a session id
# re-implement ZK submitted job graph store, r/w with a session id(the session
id is then converted to the election node path)
# re-implement ZK completed checkpoint store, r/w with a session id(the session
id is then converted to the election node path)
# let only dispatcher maintain running job registry
What do you think? [~till.rohrmann] [~StephanEwen]
was (Author: tison):
Following the ZK transaction idea, I drafted a design doc on how we rework ZK
based stores to achieve atomicity.
Mainly we will re-implement leader election service to get the
{{election-node-path}}. It could be done by porting the implementation of
{{LeaderLatch}} in Curator to Flink. Then we generate dispatcher/jm/rm's
{{session id}} based on {{election-node-path}}, and when communicate with ZK,
we pass the {{session id}}, which underneath converted to the
{{election-node-path}} to ensure that the caller is the leader, just as code
snipper above.
Subtasks can be separated as
# re-implement ZK leader election, expose election node path, which can be
converted to a session id
# re-implement ZK submitted job graph store, r/w with a session id(the session
id is then converted to the election node path)
# re-implement ZK completed checkpoint store, r/w with a session id(the session
id is then converted to the election node path)
# discuss how running job registry should work (this is an on-going issue,
mainly about how we publish the status of a job
# (maybe) re-layout zookeeper content
What do you think? [~till.rohrmann] [~StephanEwen]
> Rethink ZooKeeper based stores (SubmittedJobGraph, MesosWorker,
> CompletedCheckpoints)
> -------------------------------------------------------------------------------------
>
> Key: FLINK-10333
> URL: https://issues.apache.org/jira/browse/FLINK-10333
> Project: Flink
> Issue Type: Bug
> Components: Distributed Coordination
> Affects Versions: 1.5.3, 1.6.0, 1.7.0
> Reporter: Till Rohrmann
> Priority: Major
> Fix For: 1.8.0
>
>
> While going over the ZooKeeper based stores
> ({{ZooKeeperSubmittedJobGraphStore}}, {{ZooKeeperMesosWorkerStore}},
> {{ZooKeeperCompletedCheckpointStore}}) and the underlying
> {{ZooKeeperStateHandleStore}} I noticed several inconsistencies which were
> introduced with past incremental changes.
> * Depending whether {{ZooKeeperStateHandleStore#getAllSortedByNameAndLock}}
> or {{ZooKeeperStateHandleStore#getAllAndLock}} is called, deserialization
> problems will either lead to removing the Znode or not
> * {{ZooKeeperStateHandleStore}} leaves inconsistent state in case of
> exceptions (e.g. {{#getAllAndLock}} won't release the acquired locks in case
> of a failure)
> * {{ZooKeeperStateHandleStore}} has too many responsibilities. It would be
> better to move {{RetrievableStateStorageHelper}} out of it for a better
> separation of concerns
> * {{ZooKeeperSubmittedJobGraphStore}} overwrites a stored {{JobGraph}} even
> if it is locked. This should not happen since it could leave another system
> in an inconsistent state (imagine a changed {{JobGraph}} which restores from
> an old checkpoint)
> * Redundant but also somewhat inconsistent put logic in the different stores
> * Shadowing of ZooKeeper specific exceptions in {{ZooKeeperStateHandleStore}}
> which were expected to be caught in {{ZooKeeperSubmittedJobGraphStore}}
> * Getting rid of the {{SubmittedJobGraphListener}} would be helpful
> These problems made me think how reliable these components actually work.
> Since these components are very important, I propose to refactor them.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
