[
https://issues.apache.org/jira/browse/HBASE-20952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614317#comment-16614317
]
stack commented on HBASE-20952:
-------------------------------
Where is the 'design doc' that we're talking about? Is it the google doc
attached in middle of this JIRA? The overview? If so, I was wondering if this
doc was going to get a revision? Seems like plenty of questions and
back-and-forth above that might get consideration and that might have an impact
on the API and on general subsystem thinking? (Lets add link to this doc up at
the top of this issue)
I like the [~Apache9] questions. Is it that he's done more homework that he has
these questions or that he just has a better understanding of how the system
works? IMO, it tends to be easier working through concerns in a design than in
comments in JIRA/RB and or in code review; the latter tends to get distributed
all over and moving code without the high-level figured can bring on myopia. Is
the 'design doc' we talk of above the place to work through his concerns or is
that somewhere else?
Thanks
> Re-visit the WAL API
> --------------------
>
> Key: HBASE-20952
> URL: https://issues.apache.org/jira/browse/HBASE-20952
> Project: HBase
> Issue Type: Sub-task
> Components: wal
> Reporter: Josh Elser
> Priority: Major
> Attachments: 20952.v1.txt
>
>
> Take a step back from the current WAL implementations and think about what an
> HBase WAL API should look like. What are the primitive calls that we require
> to guarantee durability of writes with a high degree of performance?
> The API needs to take the current implementations into consideration. We
> should also have a mind for what is happening in the Ratis LogService (but
> the LogService should not dictate what HBase's WAL API looks like RATIS-272).
> Other "systems" inside of HBase that use WALs are replication and
> backup&restore. Replication has the use-case for "tail"'ing the WAL which we
> should provide via our new API. B&R doesn't do anything fancy (IIRC). We
> should make sure all consumers are generally going to be OK with the API we
> create.
> The API may be "OK" (or OK in a part). We need to also consider other methods
> which were "bolted" on such as {{AbstractFSWAL}} and
> {{WALFileLengthProvider}}. Other corners of "WAL use" (like the
> {{WALSplitter}} should also be looked at to use WAL-APIs only).
> We also need to make sure that adequate interface audience and stability
> annotations are chosen.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
