[
https://issues.apache.org/jira/browse/HBASE-20711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16507755#comment-16507755
]
Chia-Ping Tsai commented on HBASE-20711:
----------------------------------------
{quote}There is also a minor bug fix where on receipt we were using the Puts
row rather than the Cells row; client may have succeeded in submitting a Cell
that disagreed with the hosting Mutation and it would have been written as
something else altogether – with the Puts row – rather than being rejected.
On the bugfix, makes sense to you sir?
{quote}
Do you mean the path using the CellScanner (see below)? If so, I prefer to
reject the invalid cells (when calling the Mutation#add(Cell), the invalid cell
will be rejected by throwing the WrongRowIOException. Of course, we have to
skip the remaining cells in this case...Another issue :() rather than
swallowing them since it means something unexpected behaviors happen on our
hbase user's code. Correcting user's data without any alert may delay user to
notice the truly issue.
{code:java}
if (put == null) {
put = new Put(cell.getRowArray(), cell.getRowOffset(),
cell.getRowLength(), timestamp);
}
+ checkCellSizeLimit(maxCellSize, cell);
put.add(cell);
}{code}
BTW, why doing the following change? The change makes us copy the row many
times. Is it related another bugfix boss?
{code:java}
- .setRow(put.getRow())
+ cell = cellBuilder.clear()
+ .setRow(proto.getRow().toByteArray()){code}
> Save on a Cell iteration when writing
> -------------------------------------
>
> Key: HBASE-20711
> URL: https://issues.apache.org/jira/browse/HBASE-20711
> Project: HBase
> Issue Type: Sub-task
> Components: Performance
> Reporter: stack
> Assignee: stack
> Priority: Minor
> Attachments: HBASE-20711.branch-2.0.001.patch
>
>
> This is a minor savings. We were doing a spin through all Cells on receipt
> just to check their size when subsequently, we were doing an iteration of all
> Cells to insert. It manifest as a little spike in perf output. This change
> removes the purposed spin through Cells and just does size check as part of
> the general Cell insert (perf spike no longer shows but the cost of the size
> check still remains).
> There is also a minor bug fix where on receipt we were using the Puts row
> rather than the Cells row; client may have succeeded in submitting a Cell
> that disagreed with the hosting Mutation and it would have been written as
> something else altogether -- with the Puts row -- rather than being rejected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
