[
https://issues.apache.org/jira/browse/HBASE-5937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13460232#comment-13460232
]
stack commented on HBASE-5937:
------------------------------
[~fpj] Sorry for not getting to your log. What have you been having to do to
get tests to pass? How did you fix TestMultiParallel? It is stuff to do w/
this refactoring?
On your question....{quote}I have also looked at making getReader/getWriter
part of HLog{quote}
What are you thinking? Currently Reader and Writer are Interfaces defined
inside HLog. You get one by calling a static method on HLog. You'd like to
getReader non-static, an invocation on a particular instance of HLog.
That seems fine by me. It makes sense given what you are trying to do. It is
less flexible than what we currently have but its flexible because it presumes
a particular implementation of HLog.
{quote}HLogInputFormat: Not clear how to instantiate HLog{quote}
This is a facility little used if ever. I'm surprised it not used more often.
Its a repair facility. You'd use it when you started a cluster somehow w/o
replaying WALs. You could use this class in a mapreduce job to quickly add the
edits from WAL back up into the cluster.
I took a look. What are you thinking constructors will look like for HLogs?
There'll be a factory? What will the factory take for arguments?
{quote}HLogPrettyPrinter: Executed through main calls in FSHLog and
HLogPrettyPrinter, so maybe we could pass necessary parameters{quote}
This is a tool for humans to look at contents of HLogs.
{quote}HLogSplitter: Have all parameters{quote}
This is the important one (smile)
{quote}HRegion: Have HLog object{quote}
Good... Its passed the HLog, right?
{quote}ReplicationSource: Not clear how to instantiate HLog{quote}
You know what this is about, right? This is how we do replication. We tail
the WALs and as the edits come in, we send them off to other clusters. We'll
need to be able to tail logs. Could we pass Replication an HLog instance?
I hope you call your HLog Inteface WAL!
{quote}I was also wondering if there are important side-effects in the case we
use the factory to get an HLog object just to get a reader or a writer{quote}
We'd have to change the current HLog constructor. It does a bunch of work when
created -- sets a sync'ing thread running (this syncing thread though is in
need of some cleanup), creates dirs and sets up first WAL. We wouldn't want it
doing this stuff if we wanted the instance just to do getReader/getWriter on it.
{quote}I have looked into the main constructor of FSHLog and I haven't been
able to convince myself that there is a way of executing it without throwing an
exception unnecessarily or having side-effects.{quote}
As it is currently written, yes.
I think this work trying to make an Interface for WAL is kinda important.
There is this bookeeping project but the multi-WAL dev -- i.e. making the
regionserver write more than one WAL at a time (into HDFS) -- could use the
result of this effort too.
Thanks Flavio.
> Refactor HLog into an interface.
> --------------------------------
>
> Key: HBASE-5937
> URL: https://issues.apache.org/jira/browse/HBASE-5937
> Project: HBase
> Issue Type: Sub-task
> Reporter: Li Pi
> Assignee: Flavio Junqueira
> Priority: Minor
> Attachments:
> org.apache.hadoop.hbase.client.TestMultiParallel-output.txt
>
>
> What the summary says. Create HLog interface. Make current implementation use
> it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
