[
https://issues.apache.org/jira/browse/HBASE-24984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17381087#comment-17381087
]
Anoop Sam John commented on HBASE-24984:
----------------------------------------
Yes. this is not just multiwal. Even in single RS wal also.
One multi() op can result in 1+ mini batches. Every mini batch creates one WAL
append entry. So this bug can be reproduced (At least in the 2.1.x version)
and we did that. [~gouravk] is working on repro in 2.3+ branches. Seems
there are differences there. Exploring that further.
We got same issue reported from one of our customer cluster too.
> WAL corruption due to early DBBs re-use when Durability.ASYNC_WAL is used
> with multi operation
> ----------------------------------------------------------------------------------------------
>
> Key: HBASE-24984
> URL: https://issues.apache.org/jira/browse/HBASE-24984
> Project: HBase
> Issue Type: Bug
> Components: rpc, wal
> Affects Versions: 2.1.6
> Reporter: Liu Junhong
> Assignee: Gaurav Kanade
> Priority: Critical
> Fix For: 2.5.0, 2.3.6, 3.0.0-alpha-2, 2.4.5
>
>
> After bugfix HBASE-22539, When client use BufferedMutator or multiple
> mutation , there will be one RpcCall and mutliple FSWALEntry . At the time
> RpcCall finish and one FSWALEntry call release() , the remain FSWALEntries
> may trigger RuntimeException or segmentation fault .
> We should use RefCnt instead of AtomicInteger for
> org.apache.hadoop.hbase.ipc.ServerCall.reference?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
