[
https://issues.apache.org/jira/browse/HBASE-9681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790099#comment-13790099
]
Elliott Clark commented on HBASE-9681:
--------------------------------------
That sounds more like an in and an out codec. Why not just add each way.
eg.
{code}
// This is sent on connection setup after the connection preamble is sent.
message ConnectionHeader {
optional UserInformation user_info = 1;
optional string service_name = 2;
// Cell block codec we will use sending over optional cell blocks. Server
throws exception
// if cannot deal. Null means no codec'ing going on so we are pb all the
time (SLOW!!!)
optional string cell_block_codec_class = 3;
// This one is already there.
// For 0.98 this is set to a class that's only present in 0.98+
// Something like "org.apache.hadoop.hbase.codecs.SpecifyEachDirectionCodec"
// Obviously the name can use some work.
optional string cell_block_compressor_class = 4;
// This will be used on all key values being sent from this client to the
sever
optional string cell_block_compressor_from_client_class = 5;
// This will be used on all all key values being sent to the client from the
server.
optional string cell_block_compressor_to_client_class = 6;
}
{code}
Older servers will throw an exception if they don't know the full duplex codec.
So the client will fall back to a 0.96 codec.
Servers after 0.98 will throw an exception if they can't accept the codec's
specified for each direction (preferably an info carrying exception with a list
of codecs that are accepted). If it's successful then we just use each the
negotiated codec.
With this there's no extra round trips on the default case (server and client
both support the same codecs). On the worst case there's one extra round trip.
> Basic codec negotiation
> -----------------------
>
> Key: HBASE-9681
> URL: https://issues.apache.org/jira/browse/HBASE-9681
> Project: HBase
> Issue Type: Sub-task
> Affects Versions: 0.98.0
> Reporter: Andrew Purtell
>
> Basic codec negotiation:
> There should be a default codec used for cell encoding over the RPC
> connection. This should be configurable in the site file.
> The client can optionally send a message, a manufactured "call" that would
> otherwise be invalid in some way, to the server asking for a list of
> supported cell codecs. An older server should simply send back an error
> because the request is invalid except to servers supporting this feature. A
> server supporting this feature should send back the requested information or
> an error indication if something went wrong.
> The client can optionally send a message, a manufactured "call" that would
> otherwise be invalid in some way, to the server asking for it to use a given
> codec for all further communication. Otherwise the server will continue to
> use the default codec. The server will send back a call response
> acknowledging the change or an error indication if the request cannot be
> honored.
> Server configuration should support mappings from one codec type to another.
> We need to handle the case where the server has a codec available that
> extends the requested type but overrides some behavior in the base class, and
> this is what should be used in lieu of the base type. It must also be
> possible to choose an alternate default codec which stands in for the default
> codec, is compatible with client expectations, but changes the server side
> behavior as needed in the absence of negotiation.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
