[
https://issues.apache.org/jira/browse/HADOOP-10641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020942#comment-14020942
]
Konstantin Shvachko commented on HADOOP-10641:
----------------------------------------------
I think that the latest patch is a better example on how the coordination
engine should work: it accepts a proposal, then agrees on its order, then
invokes Agreement.execute() to trigger the learner state update. This is an
initial patch and is a working progress. We should also introduce a generic
Proposer, which submits a proposal and then waits for agreement to be executed
in order to reply to the client.
Nicholas, good points:
- We chose Serializable interface to keep serialization as generic as possible,
as Plamen mentioned. We routinely define readObject(), writeObject() for our
proposals using protobuf. Actually in many cases we avoid extra serialization
by passing already serialized requests directly from RPC to CoordinationEngine.
- Not sure if it is exactly what you mean by the version of coordination
engine. I see two versions here:
-# CE software version. This should be tracked in the implementation of CE. We
assume there could be different implementations of CE. If one implementation
changes it should not effect other.
-# The version of a set of Proposals / Agreements. This should be tracked on
the application level. The set of proposals / agreements reflects a particular
application logic and is orthogonal to the engine implementation.
- Rolling upgrade is divided into two parts. Rolling upgrade of the application
(e.g. HDFS) and rolling upgrade of the engine itself. If both support it then
everything is good. If CE does not support RU, but the application does, then
we should still be able to upgrade the application in the rolling manner but
without upgrading CE. CE in this case will continue assigning GSNs and produce
agreements.
- Proposal and Agreement are made as generic as possible. Proposal is formally
empty, but it has everything it needs. One need to define equals(), hashCode(),
and serialization. We also routinely implement toString() so that CE could
print proposals in the logs.
Agreement has one method execute(), so that CE could make a call back to update
the application state. It also has two generic parameters: first defines the
application type, the second - the return type of the execute() method, which
is intended to be returned to the client.
ConsensusProposal from the patch combines Proposal and Agreement. This is
probably the most typical use case. But there could be Proposals that don't
assume Agreements, like control messages to the CE, and Agreements, which are
different from corresponding Proposals, or even agreements without proposals,
like control commands from CE to the application.
- ZKCoordinationEngine should not be abstract. Made the same comment to Plamen.
- Documentation for ZKCoordinationEngine makes sense.
> Introduce Coordination Engine
> -----------------------------
>
> Key: HADOOP-10641
> URL: https://issues.apache.org/jira/browse/HADOOP-10641
> Project: Hadoop Common
> Issue Type: New Feature
> Affects Versions: 3.0.0
> Reporter: Konstantin Shvachko
> Assignee: Plamen Jeliazkov
> Attachments: HADOOP-10641.patch, HADOOP-10641.patch,
> HADOOP-10641.patch
>
>
> Coordination Engine (CE) is a system, which allows to agree on a sequence of
> events in a distributed system. In order to be reliable CE should be
> distributed by itself.
> Coordination Engine can be based on different algorithms (paxos, raft, 2PC,
> zab) and have different implementations, depending on use cases, reliability,
> availability, and performance requirements.
> CE should have a common API, so that it could serve as a pluggable component
> in different projects. The immediate beneficiaries are HDFS (HDFS-6469) and
> HBase (HBASE-10909).
> First implementation is proposed to be based on ZooKeeper.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
