[
https://issues.apache.org/jira/browse/HBASE-14790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15034663#comment-15034663
]
Zhe Zhang commented on HBASE-14790:
-----------------------------------
Thanks for the clarification Duo.
bq. Here I'm trying to use only one thread to do all the things
I see. So you "fanout" for every packet with multiple threads. That does make
the logic simpler. But I guess the logic of bumping gen stamp is still
necessary -- imagine a packet is written to 1st DN but fails to reach 2nd DN.
Does the higher level WAL just abandon the file in this case? Simply closing
the file without bumping GS will cause data corruption.
>From performance perspective, {{FanOutOneBlockDFSOutputStream}} makes sure
>every packet reaches 3 DNs before proceeding -- it's like calling {{hflush}}
>for every packet. With slow DNs this could increase latency quite
>significantly. But if packet-level flush is indeed desired in the WAL use
>case, I think the flow in the patch makes sense.
If coarser grained flushing is desired, then I think we should still separate
{{OutputStream}} and {{DataStreamer}} logics, and we should develop a
single-block single-replica fail-stop {{DataStreamer}} as I commented above.
> Implement a new DFSOutputStream for logging WAL only
> ----------------------------------------------------
>
> Key: HBASE-14790
> URL: https://issues.apache.org/jira/browse/HBASE-14790
> Project: HBase
> Issue Type: Improvement
> Reporter: Duo Zhang
>
> The original {{DFSOutputStream}} is very powerful and aims to serve all
> purposes. But in fact, we do not need most of the features if we only want to
> log WAL. For example, we do not need pipeline recovery since we could just
> close the old logger and open a new one. And also, we do not need to write
> multiple blocks since we could also open a new logger if the old file is too
> large.
> And the most important thing is that, it is hard to handle all the corner
> cases to avoid data loss or data inconsistency(such as HBASE-14004) when
> using original DFSOutputStream due to its complicated logic. And the
> complicated logic also force us to use some magical tricks to increase
> performance. For example, we need to use multiple threads to call {{hflush}}
> when logging, and now we use 5 threads. But why 5 not 10 or 100?
> So here, I propose we should implement our own {{DFSOutputStream}} when
> logging WAL. For correctness, and also for performance.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
