[
https://issues.apache.org/jira/browse/FLINK-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16912033#comment-16912033
]
TisonKun commented on FLINK-10333:
----------------------------------
[~till.rohrmann] I have started a survey thread on both user and dev list[1]
for an accurate idea how our users use high-availability services in Flink.
Regardless its intention to FLINK-13750, here are some concerns from my side in
FLINK-10333.
1. How to treat YARNHighAvailabilityService? Maybe mention the original
proposer [~StephanEwen] here. Since it is not yet implemented I'd like to drop
it because rework it along with this thread would be similar to rewrite it from
scratch. Also, even after we "rework" it, the services are still in state not
yet implemented.
2. How to treat EmbeddedHaServices? Standalone impl. is easy and zookeeper
impl. is detailedly documented. However, EmbeddedHaServices is unnoticed yet.
As discussed with Till on this thread[2], it is designed as a handy
implementation and should be not needed technically. But based on our
implementation of MiniCluster where the address of components resolved at the
runtime instead of pre-configured as standalone impl. requires, we have to
implement EmbeddedHaServices with this context.
[1]
https://lists.apache.org/x/thread.html/c0cc07197e6ba30b45d7709cc9e17d8497e5e3f33de504d58dfcafad@%3Cuser.flink.apache.org%3E
[2]
https://lists.apache.org/x/thread.html/eb7134109c437cd9c35b8dc0cc1a26ce22fe7d0b68fac8109189854e@%3Cdev.flink.apache.org%3E
> 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: Runtime / Coordination
> Affects Versions: 1.5.3, 1.6.0, 1.7.0
> Reporter: Till Rohrmann
> Priority: Major
>
> 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
(v8.3.2#803003)
