[jira] [Comment Edited] (HBASE-9681) Basic codec negotiation

["Andrew Purtell (JIRA)" <ji...@apache.org>]

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

Andrew Purtell edited comment on HBASE-9681 at 10/7/13 4:03 PM:
----------------------------------------------------------------

So to modify the OP with Elliot's suggestion:

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, and also optionally a preference ordered list of the codecs it wants. An older server should simply send back an error because the request is invalid except to servers supporting this feature. 

If the preference ordered list was provided, the server should enable the most preferred codec available for all further communication on the connection and send back a call response acknowledging the change and indicating which codec is in use, or an error indication if something went wrong.

If a preference ordered list was not provided, or if no codec on the client's list was available, the server should send back a list of available codecs. The client can optionally send another message, a manufactured "call" that would otherwise be invalid in some way, to the server asking for it to use one of the codecs from the server supplied list 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.

Suggestions for error handling:

- Once codec negotiation is initiated by the client, if the client and server can't agree on a mutually intelligible codec then the connection setup should fail with a big fat ERROR in the log. I think this decision will be up to the client, since it is driving the negotiation. It would be good if the client can also send its decision to the server so the server can print an ERROR in its logs also.

- We should not do anything about incompatible default codecs if codec negotiation is disabled (either due to older servers, or older clients, or a configuration toggle). Connection setup should proceed, but there will be failures later.


was (Author: apurtell):
So to modify the OP with Elliot's suggestion:

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, and also optionally a preference ordered list of the codecs it wants. An older server should simply send back an error because the request is invalid except to servers supporting this feature. 

If the preference ordered list was provided, the server should enable the most preferred codec available for all further communication on the connection and send back a call response acknowledging the change and indicating which codec is in use, or an error indication if something went wrong.

If a preference ordered list was not provided, or if no codec on the client's list was available, the server should send back a list of available codecs. The client can optionally send another message, a manufactured "call" that would otherwise be invalid in some way, to the server asking for it to use one of the codecs from the server supplied list 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.

Suggestions for error handling:

- Once codec negotiation is initiated by the client, if the client and server can't agree on a codec then the connection setup should fail with a big fat ERROR in the logs on the server and client sides both.

- We should not do anything about incompatible default codecs if codec negotiation is disabled (either due to older servers, or older clients, or a configuration toggle). Connection setup should proceed, but there will be failures later.

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