[
https://issues.apache.org/jira/browse/HBASE-5705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Devaraj Das updated HBASE-5705:
-------------------------------
Attachment: 5705-2.2.patch
bq. I asked about comment in ClientCache in previous reviews but it went
unanswered. I'm talking about the old Doug comment on a. vs. b. choice. I
didn't understand it then and less so now. Is it a copy/paste error?
Answered on RB but a little bit more here - I think it makes sense to remove
this confusing comment (since now the ClientCache class has some javadoc). I'll
remove it in the next patch.
bq. The writing to a buffer before we write on the line goes away if we move to
a pure pb engine?
Right.
bq. Is the size used here right for case where we have an exception? (Or its
just a hint?)
Hint.
bq. And RPCRequestWritable and RPCResponseWritable will go away too when we do
pb? (You've answered yes to this multiple times I believe).
Yes (AFAICT).
bq. Why the need for a setRPC w/ no params?
Could you please point me to the block of code in the patch where this is.. If
you are referring to the setRPC with two params that I added here, that I
reverted back in my current update.. (and added a comment up on HBASE-6282).
bq. This stuff passed to Server, whats it about? Is this some Hadoop thing
about being able to do multiple serializations?
This is to handle WritableRpcEngine and ProtobufRpcEngine equally well. In the
case of WritableRpcEngine, the RPC request is serialized using Invocation
objects and in the case of ProtobufRpcEngine, they are done using
RpcRequestWritable (a thin wrapper over PB objects).
bq. When we do logResponse, we no longer take a Call but we pass in its name
and methodnames and params.... is that a regression? Would it be better to take
the Invocation?
This is handled in the way that the method now takes methodname and params
explicitly (as opposed to how it is in the current trunk where an Invocation
object is passed and the method body extracts the params and methodname). This
was needed to support ProtobufRpc. Also, HBASE-6282 is applicable here.
bq. In header can we say if its pbs that follow? Or will we have to always calc
message size before sending?
The RPC requires that any RPC message is preceded by the length of the same. In
that sense, we need the message size.
bq. Why we need this: clientProtocolVersion in request? Is this Writables
thing? It goes away when we go pb?
The clientProtocolVersion is currently unused on the server side (and it's
optional in the .proto definition), but it could potentially be used in the
server to decide how to best service the client's RPC (if there were multiple
implementations for a method, and the server could pick an implementation based
on client version). If this use case seems like we probably won't need to
support, we can drop the clientProtocolVersion (btw it being optional in the
.proto definition makes it amenable to easy removal even later). By keeping it,
it doesn't hurt either..
> Introduce Protocol Buffer RPC engine
> ------------------------------------
>
> Key: HBASE-5705
> URL: https://issues.apache.org/jira/browse/HBASE-5705
> Project: HBase
> Issue Type: Sub-task
> Components: ipc, master, migration, regionserver
> Reporter: Devaraj Das
> Assignee: Devaraj Das
> Fix For: 0.96.0
>
> Attachments: 5705-1.patch, 5705-2.1.patch, 5705-2.2.patch
>
>
> Introduce Protocol Buffer RPC engine in the RPC core. Protocols that are PB
> aware can be made to go through this RPC engine. The approach, in my current
> thinking, would be similar to HADOOP-7773.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
