[
https://issues.apache.org/jira/browse/HADOOP-6170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doug Cutting updated HADOOP-6170:
---------------------------------
Attachment: HADOOP-6170.patch
> Do add some JavaDoc per class.
Done.
> Can a single RPC server satisfy multiple protocols?
Yes, that should work. The client and servers protocols are both determined
through reflection. So long as the server implements the subset of methods
that the client calls then all's well. Avro doesn't validate the protocol name
in RPC, just the method name. Dunno if that's a bug or a feature! (I think
this is the same loophole that Hadoop RPC uses.)
> Typo.
Fixed.
> AvroTestProtocol is generated code, yes? Or does ReflectData.getProtocol()
figure it out from reflection and paranamer data?
The latter. This current patch only supports reflection-based RPC, since it's
intended to be a stepping stone for transition from Hadoop RPC, which is
reflection-based.
> Total nit: JUnit prefers the expected argument on the left.
Fixed.
> Eclipse tells me this is unused.
Added a comment.
> getRemoteName() { return "remote"; }
Good catch! That was a bug. This is used by Avro to cache the remote
protocol. It should be the remote host's address. Fixed.
I also took the opportunity to upgrade from Avro 1.0 to Avro 1.1, which
required a few minor changes to the io/serializer/avro stuff.
> add Avro-based RPC serialization
> --------------------------------
>
> Key: HADOOP-6170
> URL: https://issues.apache.org/jira/browse/HADOOP-6170
> Project: Hadoop Common
> Issue Type: New Feature
> Reporter: Doug Cutting
> Assignee: Doug Cutting
> Fix For: 0.21.0
>
> Attachments: HADOOP-6170.patch, HADOOP-6170.patch, HADOOP-6170.patch,
> HADOOP-6170.patch
>
>
> Permit RPC protocols to use Avro to serialize requests and responses, so that
> protocols may better evolve without breaking compatibility.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
