[
https://issues.apache.org/jira/browse/HBASE-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12909122#action_12909122
]
HBase Review Board commented on HBASE-2993:
-------------------------------------------
Message from: [email protected]
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://review.cloudera.org/r/829/#review1176
-----------------------------------------------------------
src/main/java/org/apache/hadoop/hbase/LocalHBaseCluster.java
<http://review.cloudera.org/r/829/#comment4028>
Didn't realize one of these lifecycle things in Guava but then there's a
million different versions of Lifecycle I suppose (I'm pretty sure I've written
a few myself in past life). We could write our own but, its my guess it'd not
differ from what we have here much. Then again its missing Abort.
This kinda refactoring is a big improvement; we should go this way, yeah,
as it takes us further down road already started where we're trying to have
Servers in hbase look alike. But I want us to be even more radical. I want us
to move up to something like Spring where implementing their container means we
get a bunch of other facility for near free and where the wiring up of a
regionserver or a master can be done from config with others able to provide
alternate implementations if they'd like with just a config. change. It'd
encourage writing to Interfaces, etc. ( Well, maybe not Spring. Its too heavy
weight and that xml stuff makes me queasy. There are lesser IofC containers
such as pico or nano).
src/main/java/org/apache/hadoop/hbase/LocalHBaseCluster.java
<http://review.cloudera.org/r/829/#comment4029>
This is good
src/main/java/org/apache/hadoop/hbase/master/HMaster.java
<http://review.cloudera.org/r/829/#comment4030>
Thats a real pretty name (descriptive though I suppose)
src/main/java/org/apache/hadoop/hbase/master/HMaster.java
<http://review.cloudera.org/r/829/#comment4031>
We had a sort of convention for naming threads in hbase where host 'server'
is prefix where host includes service type and port if needed... that kinda
thing. Previous we had a naming convention per implementator... was a mess.
src/main/java/org/apache/hadoop/hbase/master/HMaster.java
<http://review.cloudera.org/r/829/#comment4032>
I like having state in there. I was also adding zk sessionid....
src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
<http://review.cloudera.org/r/829/#comment4033>
good
src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
<http://review.cloudera.org/r/829/#comment4034>
good
src/main/java/org/apache/hadoop/hbase/util/JVMClusterUtil.java
<http://review.cloudera.org/r/829/#comment4035>
Good. I think I made this class originally. It grew into a monster.
src/test/java/org/apache/hadoop/hbase/HBaseClusterTestCase.java
<http://review.cloudera.org/r/829/#comment4036>
Are we losing the threaddumping? It was useful.
- stack
> Refactor servers to use a common lifecycle interface
> ----------------------------------------------------
>
> Key: HBASE-2993
> URL: https://issues.apache.org/jira/browse/HBASE-2993
> Project: HBase
> Issue Type: Improvement
> Components: master, regionserver
> Affects Versions: 0.90.0
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
>
> In current trunk, the region server is a Runnable and the Master is a thread.
> We have all kinds of weird wrappers like JVMClusterUtil to try to work around
> this. It would be nice if they both implemented the same interface -
> LocalHBaseCluster and the MiniCluster would be a lot easier to understand as
> well, and we could share some more code between them.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
