[
https://issues.apache.org/jira/browse/HBASE-10156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13972124#comment-13972124
]
stack commented on HBASE-10156:
-------------------------------
bq. We sync .meta. in the initial phase 'appendNoSync' in trunk.
What are you seeing lads? Ain't this doing same as 0.98 did; i.e. sync and not
return until sync completes? Or you seeing double sync call per meta write?
The txid is no longer exposed, that is right. It is kept internal to the
implementation.
bq. So if there is a stream of writes, we will wait for the sync of the last
writes, even if "our" edits are already in?
There is preemption. If a sync thread came back between your write and just
before you go to call sync, we'll skip the sync call. Search " //
See if we can process any syncfutures BEFORE we go sync."
What is the problem you lads are seeing? (I've been around this code a bit so
hopefully can help).
> FSHLog Refactor (WAS -> Fix up the HBASE-8755 slowdown when low contention)
> ---------------------------------------------------------------------------
>
> Key: HBASE-10156
> URL: https://issues.apache.org/jira/browse/HBASE-10156
> Project: HBase
> Issue Type: Sub-task
> Components: wal
> Reporter: stack
> Assignee: stack
> Fix For: 0.99.0
>
> Attachments: 10156.txt, 10156v10.txt, 10156v11.txt, 10156v12.txt,
> 10156v12.txt, 10156v13.txt, 10156v16.txt, 10156v17.txt, 10156v18.txt,
> 10156v19.txt, 10156v2.txt, 10156v20.txt, 10156v20.txt, 10156v21.txt,
> 10156v21.txt, 10156v21.txt, 10156v3.txt, 10156v4.txt, 10156v5.txt,
> 10156v6.txt, 10156v7.txt, 10156v9.txt, Disrupting.java
>
>
> HBASE-8755 slows our writes when only a few clients. Fix.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
