[
https://issues.apache.org/jira/browse/HBASE-20471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16447525#comment-16447525
]
Yu Li commented on HBASE-20471:
-------------------------------
bq. We do expect SKIP_WAL to take effect on a per RPC basis
Yes I agree, by "Only allow setting SYNC_WAL..." I actually meant for sync mode
we only allow SYNC_WAL and no FSYNC_WAL per RPC. I think 1) don't write WAL; 2)
write WAL asynchronously and 3) write WAL synchronously could over all needs
from user perspective, and the detailed sync mode should be a
per-cluster/per-table/per-CF setting rather than per RPC. Let me edit my old
comment to make it clear (smile)
> Recheck the design and implementation of FSYNC_WAL durability for WAL
> ---------------------------------------------------------------------
>
> Key: HBASE-20471
> URL: https://issues.apache.org/jira/browse/HBASE-20471
> Project: HBase
> Issue Type: Task
> Reporter: Yu Li
> Priority: Major
>
> This is something derived from discussion in HBASE-19024 around [this
> comment|https://issues.apache.org/jira/browse/HBASE-19024?focusedCommentId=16445592&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16445592]
> We have been supplying user the API to set durability per mutation for a long
> time, by design the SYNC_WAL durability to call {{FSDataOutputStream#hflush}}
> and FSYNC_WAL {{FSDataOutputStream#hsync}}, while in implementation we have
> been calling hflush for FSYNC_WAL also until HBASE-19024. Although
> HBASE-19024 tried to fix the syntax with good willing, the implementation
> there cannot assure the FSYNC_WAL edits are truly hsync'ed due to the
> disruptor mechanism used in WAL implementation. Here in this JIRA we aim to
> have more discussion and give it a complete solution.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
