[ 
https://issues.apache.org/jira/browse/HBASE-24984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17381066#comment-17381066
 ] 

Xiaolin Ha commented on HBASE-24984:
------------------------------------

I think what [~mopishv0] said is that when using ASYNC_WAL and wal group, one 
multi() call may contain data which should be synced to different wals. But 
currently in the ServerCall, there is only 1 call reference and 1 wal 
reference(though in different bit of the binary number).  When one wal synced 
complete(partial wal entries of the call), the wal reference will be released. 
And when the RPC call complete, the call reference will be released. But there 
may still be some other wal entries partial of this call haven't synced to wal. 
So once these wal entries sync, the RuntimeException or segmentation fault 
happens.
As [~anoop.hbase] mentioned, I also think we can reproduce this problem by UT, 
using SimpleRPCServer (where we have control over the pooled DBBs).


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

Reply via email to