[
https://issues.apache.org/jira/browse/HBASE-16205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15376391#comment-15376391
]
Anoop Sam John commented on HBASE-16205:
----------------------------------------
In trunk after HBASE-15180, we will not do a copy to create cells in
Codec#Decoder. (Pls refer IPCUtil#createCellScannerReusingBuffers)
This is with the assumption that the Cells any way will get copied to MSLAB
area before adding to memstore. So before HBASE-15180 we were doing 2 copies.
Now as said above in 3 cases, the copy of cells to MSLAB area wont happen. In
such cases the cells added to Memstore (These will last for longer time until
next flush) will refer to the same byte[] where the RPC read the requests.
This will be much bigger sized. The RPC request buffer will contain request
header and mutation PB bytes etc. So we dont allow bigger sized buffers to get
GCed as Cells in memstore still refer those.
This deep copy is to avoid such cases.
Am I explaining it correctly now?
> 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
>
>
> 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)
