[
https://issues.apache.org/jira/browse/HBASE-9681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13783612#comment-13783612
]
Andrew Purtell commented on HBASE-9681:
---------------------------------------
bq. The connection header is the place where the codec and compression is
determined i.e once per connection.
My thinking is this is where the initial default codec for the connection would
established like it is done now for 0.96. Then an additional round of
negotiation would optionally happen, hence the idea for using 'invalid' calls
after the initial connection header processing. I suppose it could be done with
new optional fields in the connection header and response instead but this
would need to support:
- 0.96 clients talking to 0.98 servers expecting them to act like 0.96 servers
- 0.98 clients talking to 0.96 servers
- 0.98 clients talking to 0.98 servers, with codec negotiation, and server side
substitution
bq. Need to introduce a connection response that on getting the option from the
client to return the list of codecs. So on what basis should the server return
them? Check it from the classpath?
We can do this with configuration or decorators. Either we add a new site
configuration option where a comma separated list of codec classes could go, or
we create a new decorator type that marks codecs and scan the classpath for the
decorator at server startup and add the discovered classes to a list.
> 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)
