[
https://issues.apache.org/jira/browse/TEZ-1194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14026679#comment-14026679
]
Bikas Saha commented on TEZ-1194:
---------------------------------
This is not suggesting mixing byte array and byte buffers. This is adding a
layer of indirection in the API so that our choice of internal serialization is
hidden from the user. It also add some form of type checking where one know
that one is passing in a user payload as opposed to any other byte[] or
bytebuffer. If internally we change to bytebuffer then it will be transparent
to the user. This can also more cleanly expose helper methods like creating
payload from Configuration etc. Our internal code make unnecessary buffer
copies during RPC and maybe a ByteString instead of bytebuffer would be better.
TezUserPayload does not union. It just provides a wrapper API around the
current impl along with helper methods that hide the internal impl from the
user. Does that help clarify?
> Make TezUserPayload user facing for payload specification
> ---------------------------------------------------------
>
> Key: TEZ-1194
> URL: https://issues.apache.org/jira/browse/TEZ-1194
> Project: Apache Tez
> Issue Type: Sub-task
> Reporter: Bikas Saha
>
> Now that we have TezUserPayload being used internally to represent user
> payload it may be useful to make it user facing on the API for specifying
> payloads. Advantages
> 1) Clear code for the user instead of having untyped byte[] everywhere
> 2) Lets us internally evolve the representation of user payload and make it
> more efficient without having to break APIs. We can start with
> TezUserPayload(byte[]) and then move on to TezUserPayload(ByteBuffer) and so
> on while maintaining backwards compatibility without needing to add new
> methods. Old code can be translated within TezUserPayload while user migrates
> the code.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
