Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 1 Oct 2013 17:17:25 +0000 (UTC)
From: "ramkrishna.s.vasudevan (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12671241.1380435108298.12092.1380647845502@arcas>
In-Reply-To: <JIRA.12671241.1380435108298@arcas>
References: <JIRA.12671241.1380435108298@arcas>
Subject: [jira] [Commented] (HBASE-9681) Basic codec negotiation
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

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

Currently we have a connectionheader, request header and request response on the RPC communication side.
The connection header is the place where the codec and compression is determined i.e once per connection.  Once the connection header is processed the remaining normal Request headers are processed.
So as to introduce the basic negotiaion protocol
1) 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?
2)This response to be interpreted by the client and select one codec from the list and send that codec as a new response from the client to the server.
3) To this response, the server tries to use the codec given by the client and again returns a success/failure msg if it was able to use the specified codec.
4)The mapping of individual codecs and the extended functionality of codecs that needs specific behaviour on the server side am yet to work on that.


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