[
https://issues.apache.org/jira/browse/HBASE-9681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790617#comment-13790617
]
Elliott Clark commented on HBASE-9681:
--------------------------------------
bq.This will have the two codecs that would be needed by the client and server?
I was thinking that would be the sentinel that the following two classes are
used.
However I'm still a little slow on picking up when you'd need the client to
specify more than one codec. It seems like in your example having the client
specify one codec and having the codec have some idea of where it's running
would make this easier.
h2.Client sending to Server
# Client calls getCodec.
# Client get Codec1
# Tells that codec that it's on the client
# Client then calls getEncoder
https://hbase.apache.org/devapidocs/org/apache/hadoop/hbase/codec/Codec.html#getEncoder(java.io.OutputStream)
#* This call returns Codec1.ClientEncoder
# send the kv's to the codec's encoder who encodes the key values placing the
tags at the end of the byte stream
# Client sends that encoded byte stream to the server after specifying the
codec on the header.
# Server then looks up the same codec codec by calling getCodec
# Server gets Codec1
# Server then tells the codec that it's on the server
# Server gets the decoder
https://hbase.apache.org/devapidocs/org/apache/hadoop/hbase/codec/Codec.html#getDecoder(java.io.InputStream)
#* This call returns Codec1.ServerDecoder
# Server feeds the decoder the bytes who preforms the exact inverse of what was
done by the client's encoder.
h2.Server sending to Client
# Server then looks up the codec specified in the connection header
# Server gets Codec1
# Server then tells the codec that it's on the server
# Server gets the encoder
https://hbase.apache.org/devapidocs/org/apache/hadoop/hbase/codec/Codec.html#getDecoder(java.io.InputStream)
#* This call returns Codec1.ServerEncoder
# Server feeds the encoder the cells. It stips any system tags and then
encodes the cells by moving the tags to the back end (or whatever is needed)
# Server sends these bytes
# Client then gets the Call result with the encoded bytes.
# Notices they are encoded so callse getCodec
# The client gets Codec1
# The client then informs Codec1 that it's on the client
# The client gets the decoder
#* This call returns Codec1.ClientDecoder
# This decoder knows nothing about system tags so it only preforms the inverse
of moving the tags to the end of the byte stream.
> 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)
