dlmarion commented on PR #2620:
URL: https://github.com/apache/accumulo/pull/2620#issuecomment-1102501287
> > Overall, I'm in favor of this change. I do worry that change to Thrift
code tend to break in surprising ways, but I think it will be fine with
sufficient testing, as this is nothing new when working with Thrift.
>
> I am curious what the behavior is when a 2.1 client connects to a 2.0
server or visa versa a 2.0 client connects to a 2.1 server with this changes.
Ideally there would be a nice error message that indicates RPC incompatibility,
not sure if thrift will do this though.
>
It definitely is the case that if you have attempt to use a non-multiplexed
client with a multiplexed server, then you get a message in the error
suggesting that you should be using the multiplexed client. The error that is
returned to the client is at
https://github.com/apache/thrift/blob/master/lib/java/src/org/apache/thrift/TMultiplexedProcessor.java#L116
> > Are there any performance implications for switching to this multiplexed
protocol?
>
> I am also curious about this.
I did look for issues in the Thrift JIRA regarding the multiplexed
processors, but I didn't really find much. The client passes the service name
and the message to the server, and in
[this](https://github.com/apache/thrift/blob/master/lib/java/src/org/apache/thrift/TMultiplexedProcessor.java#L79)
method the server uses the service name to get the correct Processor from a
map and then passes the message to that Processor. I think there will be a
small amount of time taken per API call to perform the logic in the
TMultiplexedProcessor.process method. Do you think I should benchmark it?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
