Chance Li updated HBASE-12439:
    Comment: was deleted

(was: [~stack]

thanks, sir.

{quote}less throughput, but way less CPU used (better 95th percentiles, etc), 
and handlers free for other tasks\{quote}

Yes sir, this is our purpose.

{quote}Would it make sense to put this limit behind a configuration 
I think we need it. It is mainly for to enable us to 'remove' it , even though 
we can't totally remove it because of the added counter on the path.

{quote}Also of note is how your compares show the asyncwal being slightly 
better than old wal.\{quote}
Let me check again. And this async_wal is one of Durablilty types. it's not WAL.

[~carp84] ok, I will work on it.)

> Procedure V2
> ------------
>                 Key: HBASE-12439
>                 URL: https://issues.apache.org/jira/browse/HBASE-12439
>             Project: HBase
>          Issue Type: New Feature
>          Components: master
>    Affects Versions: 2.0.0
>            Reporter: Matteo Bertozzi
>            Priority: Major
>              Labels: reliability
>         Attachments: ProcedureV2b.pdf, Procedurev2Notification-Bus.pdf, 
> Procedurev2Notification-BusRoadmap.pdf
> Procedure v2 (aka Notification Bus) aims to provide a unified way to build:
> * multi-steps procedure with a rollback/rollforward ability in case of 
> failure (e.g. create/delete table)
> ** HBASE-12070
> * notifications across multiple machines (e.g. ACLs/Labels/Quotas cache 
> updates)
> ** Make sure that every machine has the grant/revoke/label
> ** Enforce "space limit" quota across the namespace
> ** HBASE-10295 eliminate permanent replication zk node
> * procedures across multiple machines (e.g. Snapshots)
> * coordinated long-running procedures (e.g. compactions, splits, ...)
> * Synchronous calls, with the ability to see the state/result in case of 
> failure.
> ** HBASE-11608 sync split
> still work in progress/initial prototype: https://reviews.apache.org/r/27703/

This message was sent by Atlassian JIRA

Reply via email to