[
https://issues.apache.org/jira/browse/HBASE-16205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15387157#comment-15387157
]
Anoop Sam John commented on HBASE-16205:
----------------------------------------
The upsert code path rely on Object equality check to make sure we wont remove
the just added cell. That was broken by v2 patch and V3 corrects that.
Also added back the old ShareableMemory interface. We will create Cell impls
of this type from the Codec ByteBufferedKeyValueDecoder. Here all Cells backed
by same buffer chunk where the RPC requests are read into. In such case only we
need this deep copy (if MSLAB copy not happened). We are not blind doing this
deep copy now (as per V3 patch).
> When Cells are not copied to MSLAB, deep clone it while adding to Memstore
> --------------------------------------------------------------------------
>
> Key: HBASE-16205
> URL: https://issues.apache.org/jira/browse/HBASE-16205
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver
> Affects Versions: 2.0.0
> Reporter: Anoop Sam John
> Assignee: Anoop Sam John
> Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-16205.patch, HBASE-16205_V2.patch,
> HBASE-16205_V3.patch
>
>
> This is imp after HBASE-15180 optimization. After that we the cells flowing
> in write path will be backed by the same byte[] where the RPC read the
> request into. By default we have MSLAB On and so we have a copy operation
> while adding Cells to memstore. This copy might not be there if
> 1. MSLAB is turned OFF
> 2. Cell size is more than a configurable max size. This defaults to 256 KB
> 3. If the operation is Append/Increment.
> In such cases, we should just clone the Cell into a new byte[] and then add
> to memstore. Or else we keep referring to the bigger byte[] chunk for longer
> time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
