[
https://issues.apache.org/jira/browse/YARN-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13620326#comment-13620326
]
Robert Joseph Evans commented on YARN-528:
------------------------------------------
I am fine with splitting the MR changes from the YARN change like I said, I put
this out here more to be a question of how do we want to go about implementing
theses changes, and the test was more of a prototype example.
I personally lean more towards using the *Proto classes directly. Why have
something else wrapping it if we don't need it, even if it is a small and
simple layer. The only reason I did not go that route here is because of
toString(). With the IDs we rely on having ID.toString() turn into something
very specific that can be parsed and turned back into an instance of the
object. If I had the time I would trace down all places where we call toString
on them and replace it with something else. I may just scale back the scope of
the patch to look at ApplicationID to begin with and try to see if I can
accomplish this.
bq. Wrapping the object which came over the wire - with a goal of creating
fewer objects.
I really don't understand how this is supposed to work. How do we create fewer
objects by wrapping them in more objects? I can see us doing something like
deduping the objects that come over the wire, but I don't see how wrapping
works here.
> 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
