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