[
https://issues.apache.org/jira/browse/HBASE-15198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15127608#comment-15127608
]
Anoop Sam John commented on HBASE-15198:
----------------------------------------
bq.Don't we always use a Codec already?
Our idea was to use that. From Client -> Server during writes and Server ->
Client while reading. The default Codec is KVCodec and we dont write this in
hbase-default.xml So even if user don't add any entry in their xml, the
Codec should get used.
But because of the bug client -> Server was not using Codec.
The RpcClient impl is having a codec instance associated with it. Still...
Server -> Client is using Codec and CellBlock always
The now the explanation clear [~saint....@gmail.com]?
Regarding the alternate fix way what I was telling
Now you can see that the MultiServerCallable on its constructor read the
configs and decide whether to do CellBlock or not. So there will be 2 config
read. (Not so cheap) This will happen for each write req going to server.
Instead, if MultiServerCallable ask the RpcClient to know whether to use the
CellBlocking, we can just do that by a boolean read. For that we should add a
boolean return API in ClusterConnection (Connection is exposed to public and so
don't add there) and MultiServerCallable use that to decide whether to use
CellBlock or not.
May be this we can see later also go with simple fix now. Am ok either way.
wdyt?
[~jingcheng...@intel.com] Thanks for the test and confirm. The numbers looks
great! The saving in GC is very good.. After this fix, the write path started
using Codec and its Decoder and there is still garbage we create. So I believe
with fix in HBASE-15180, u will see better results.
> RPC client not using Codec and CellBlock for puts by default
> ------------------------------------------------------------
>
> Key: HBASE-15198
> URL: https://issues.apache.org/jira/browse/HBASE-15198
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.98.0
> Reporter: Anoop Sam John
> Assignee: Anoop Sam John
> Priority: Critical
> Attachments: HBASE-15198.patch
>
>
> For puts we use MultiServerCallable. Here to decide whether to use cellBlock
> we have
> {code}
> private boolean isCellBlock() {
> // This is not exact -- the configuration could have changed on us after
> connection was set up
> // but it will do for now.
> HConnection connection = getConnection();
> if (connection == null) return true; // Default is to do cellblocks.
> Configuration configuration = connection.getConfiguration();
> if (configuration == null) return true;
> String codec = configuration.get(HConstants.RPC_CODEC_CONF_KEY, "");
> return codec != null && codec.length() > 0;
> }
> {code}
> By default in hbase-default.xml, we dont have any Codec being specified.
> Where as in AbstractRpcClient we have
> {code}
> Codec getCodec() {
> // For NO CODEC, "hbase.client.rpc.codec" must be configured with empty
> string AND
> // "hbase.client.default.rpc.codec" also -- because default is to do cell
> block encoding.
> String className = conf.get(HConstants.RPC_CODEC_CONF_KEY,
> getDefaultCodec(this.conf));
> if (className == null || className.length() == 0) return null;
> try {
> return (Codec)Class.forName(className).newInstance();
> } catch (Exception e) {
> throw new RuntimeException("Failed getting codec " + className, e);
> }
> }
> .....
> public static String getDefaultCodec(final Configuration c) {
> // If "hbase.client.default.rpc.codec" is empty string -- you can't set
> it to null because
> // Configuration will complain -- then no default codec (and we'll pb
> everything). Else
> // default is KeyValueCodec
> return c.get(DEFAULT_CODEC_CLASS, KeyValueCodec.class.getCanonicalName());
> }
> {code}
> Our aim is to by def use Codec and it is KeyValueCodec.
> The codec finding in MultiServerCallable to be same way as in
> AbstractRpcClient and then only we will be doing cellblock stuff.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
