hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ramkrishna.s.vasudevan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-9681) Basic codec negotiation
Date Thu, 03 Oct 2013 04:51:42 GMT

    [ https://issues.apache.org/jira/browse/HBASE-9681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13784821#comment-13784821
] 

ramkrishna.s.vasudevan commented on HBASE-9681:
-----------------------------------------------

bq.We can do this with configuration or decorators. Either we add a new site configuration
option where a comma separated list of codec classes
Currently using this as configuration.  We can use reflections to get the Codec related class
paths too.  I can later work on that part.
bq. I suppose it could be done with new optional fields in the connection header and response
instead but this would need to support:
Yes, adding new fields should work.  Working on it.  I would post a WIP patch on this. I feel
 we may need some new request/response too to make this 2 way communication.  And the header
of which can be forcefully made negative and the client/server understands the new response/request
if the header size is negative?

> 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)

Mime
View raw message