[
https://issues.apache.org/jira/browse/YARN-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13620275#comment-13620275
]
Siddharth Seth commented on YARN-528:
-------------------------------------
Yep, we'll likely only support a single serialization, which at this point is
PB.
What the current approach was supposed to be good at.
1. Handling unknown fields (which proto already supports), which could make
rolling upgrades etc easier.
2. Wrapping the object which came over the wire - with a goal of creating fewer
objects.
I don't think the second point was really achieved, with the implementation
getting complicated because of the interfaces being mutable, lists and
supporting chained sets (clc.getResource().setMemory()). I think point one
should continue to be maintained.
Do we want *Proto references in the APIs (client library versus Java Protocol
definition) . At the moment, these are only referenced in the PBImpls - and
hidden by the abstraction layer.
What I don't like about the patch is Protos leaking into the object
constructors. Instead, I think we could just use simple Java objects, with
conversion at the RPC layer (I believe this is similar to the HDFS model).
Unknown fields can be handled via byte[] arrays.
I'm guessing very few of the interfaces actually need to be mutable - so in
that sense, yes this needs to be done before beta. OTOH, changing the PBImpl
itself can be done at a later point if required. (Earlier is of-course better,
and I'd be happy to help with this. Was planning on working on YARN-442 before
you started this work).
> Make IDs read only
> ------------------
>
> Key: YARN-528
> URL: https://issues.apache.org/jira/browse/YARN-528
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Robert Joseph Evans
> Assignee: Robert Joseph Evans
> Attachments: YARN-528.txt, YARN-528.txt
>
>
> I really would like to rip out most if not all of the abstraction layer that
> sits in-between Protocol Buffers, the RPC, and the actual user code. We have
> no plans to support any other serialization type, and the abstraction layer
> just, makes it more difficult to change protocols, makes changing them more
> error prone, and slows down the objects themselves.
> Completely doing that is a lot of work. This JIRA is a first step towards
> that. It makes the various ID objects immutable. If this patch is wel
> received I will try to go through other objects/classes of objects and update
> them in a similar way.
> This is probably the last time we will be able to make a change like this
> before 2.0 stabilizes and YARN APIs will not be able to be changed.
--
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: http://www.atlassian.com/software/jira
