hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Konstantin Shvachko (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-10641) Introduce Coordination Engine
Date Sat, 07 Jun 2014 19:54:01 GMT

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

Mime
View raw message