accumulo-dev mailing list archives

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


Christopher Tubbs updated ACCUMULO-751:

          Component/s: thrift
               Labels: api compatibility versioning wire wireprotocol  (was: )
             Priority: Critical  (was: Major)
    Affects Version/s: 1.4.0
> Support Wire Compatability
> --------------------------
>                 Key: ACCUMULO-751
>                 URL:
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: master, thrift, tserver
>    Affects Versions: 1.4.0
>            Reporter: Mike Drob
>            Assignee: Eric Newton
>            Priority: Critical
>              Labels: api, compatibility, versioning, wire, wireprotocol
> 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