hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-10156) FSHLog Refactor (WAS -> Fix up the HBASE-8755 slowdown when low contention)
Date Thu, 17 Apr 2014 00:15:19 GMT

    [ 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

> 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

View raw message