accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-751) Support Wire Compatability
Date Thu, 06 Sep 2012 00:07:07 GMT


Christopher Tubbs commented on ACCUMULO-751:

Currently, wire-compatibility between versions is explicitly disallowed. This is probably
not necessary, but makes it easier by eliminating huge classes of possible failure modes,
especially on large clusters.

As stated in the description, this is probably already possible, theoretically between bugfix
versions (like 1.4.0 and 1.4.1), if it weren't for the fact that it is explicitly disallowed.

To make this work, Accumulo must be more strict about its versioning semantics, and add a
guarantee of wire-compatibility between bugfix versions.
> Support Wire Compatability
> --------------------------
>                 Key: ACCUMULO-751
>                 URL:
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: master, tserver
>            Reporter: Mike Drob
>            Assignee: Eric Newton
> With the advent of the HA NameNode in HDFS, the need for planned Hadoop outages has greatly
diminished. I believe that Accumulo should follow suit and eventually allow for no-outage
> To support this feature, we would require wire compatibility between different versions
so that the cluster can continue to function in a mixed state. There are already contingencies
for master fail-over and tservers to leave/join the cluster, so I think this is a natural
extension of that code.
> To accomplish this for bugfix releases should be trivial. I think it is only necessary
to remove (or relax) the version check that happens when a tserver attempts to join. There
are rarely (never?) changes to the thrift protocol between bugfix releases, so theoretically
a 1.4.1 tserver is already compatible with a 1.4.0 master and vice versa.
> To maintain compatibility in the face of thrift protocol changes is certainly a harder
challenge, which might be best reserved for a separate ticket.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message