Chris Douglas commented on HDFS-11010:

bq. Let us take a step back, how do you propose that we solve this issue ? 

I don't have a solution, unless Google were to restore some of this 
functionality, or there's a proto3 pattern we can use to maintain compatibility.

We could upgrade to PB 2.6.1 with less pain (presumably), but absent a 
compelling reason to adopt 3.x... if it doesn't do what we need, then does it 
matter if it's supported? Supporting both 2.x and 3.x seems too complex, since 
we'd need to address two sets of backwards compatibility semantics in new 

bq. I am expecting that our clients will have to move to using new DFSclient 
since we have broken so many of those classes already.

Fair enough, but we can't move only HDFS to proto3, we also need to move YARN. 
I'm not sure old applications will link against PB3 classes. Applications 
submitted as shaded jars will have unique problems. Until we can provide better 
isolation (JDK9?), I'm not sure how to manage this upgrade smoothly.

Are there downstream projects that want to use features or exploit performance 
gains in proto3? If we're holding others back, then we can look harder for a 

> Update to Protobuf 3 in trunk
> -----------------------------
>                 Key: HDFS-11010
>                 URL: https://issues.apache.org/jira/browse/HDFS-11010
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: ipc
>    Affects Versions: 3.0.0-alpha2
>            Reporter: Anu Engineer
> This JIRA is to propose that we should move to protobuf 3 from protobuf 2.5. 
> This allows us to stay with the newer versions of the protobuf.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org

Reply via email to