[
https://issues.apache.org/jira/browse/HBASE-10378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13876174#comment-13876174
]
ramkrishna.s.vasudevan commented on HBASE-10378:
------------------------------------------------
[[email protected]]
Had a glance at the patch. The WAL and WALService looks good.
I have some basic questions, incase of rollWriter and replications (including
starting the syncer and writer threads), should we have an implemenation for
the WALservice where based on the number of hLogs those many syncer and writer
threads need to be started along with the replicaiton services for them?
Currently the HRS just instantiates one HLog and starts them. What do you say?
I was having an idea of defining an interface called WALGrouper and every
region server would use an type of this WALGrouper and this grouper would know
how many hLog instance he is creating and for every instance those syncer and
writer threads would be started.
And the api
{code}
public WALService getWAL() {
{code}
How will this make sense when there are more than one hlog for that RS? I know
that in ur current implementation there are only 2 HLog and one among them is
going to be active? But what if my multiwal impl is not that way and i may have
more than one active HLog?
I can discuss with you offline too on some my concerns and questions that I had
while doing HBASE-8610.
> Divide HLog interface into User and Implementor specific interfaces
> -------------------------------------------------------------------
>
> Key: HBASE-10378
> URL: https://issues.apache.org/jira/browse/HBASE-10378
> Project: HBase
> Issue Type: Sub-task
> Components: wal
> Reporter: Himanshu Vashishtha
> Attachments: 10378-1.patch
>
>
> HBASE-5937 introduces the HLog interface as a first step to support multiple
> WAL implementations. This interface is a good start, but has some
> limitations/drawbacks in its current state, such as:
> 1) There is no clear distinction b/w User and Implementor APIs, and it
> provides APIs both for WAL users (append, sync, etc) and also WAL
> implementors (Reader/Writer interfaces, etc). There are APIs which are very
> much implementation specific (getFileNum, etc) and a user such as a
> RegionServer shouldn't know about it.
> 2) There are about 14 methods in FSHLog which are not present in HLog
> interface but are used at several places in the unit test code. These tests
> typecast HLog to FSHLog, which makes it very difficult to test multiple WAL
> implementations without doing some ugly checks.
> I'd like to propose some changes in HLog interface that would ease the multi
> WAL story:
> 1) Have two interfaces WAL and WALService. WAL provides APIs for
> implementors. WALService provides APIs for users (such as RegionServer).
> 2) A skeleton implementation of the above two interface as the base class for
> other WAL implementations (AbstractWAL). It provides required fields for all
> subclasses (fs, conf, log dir, etc). Make a minimal set of test only methods
> and add this set in AbstractWAL.
> 3) HLogFactory returns a WALService reference when creating a WAL instance;
> if a user need to access impl specific APIs (there are unit tests which get
> WAL from a HRegionServer and then call impl specific APIs), use AbstractWAL
> type casting,
> 4) Make TestHLog abstract and let all implementors provide their respective
> test class which extends TestHLog (TestFSHLog, for example).
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
