Andrzej Bialecki wrote:
> That's excellent news - I just looked at the code, I think it would
> require only minimal tweaks to use it together with other Hadoop
> services running in "local" mode - e.g. it would be more convenient to
> have the MiniHBaseCluster (or its modified version, let's call it
> LocalHBaseCluster) handle the startup / shutdown itself, so that the
> user applications could assume that all necessary services are already
> running. I'm also going to check what is the startup time of
> MiniHBaseCluster.
>
MiniHBaseCluster already has a shutdown method. Construction of a
MiniHBaseCluster starts up the cluster instance. Would you like a
different startup mechanism Andrzej? If so, what would you suggest?
Otherwise, I"m thinking we'd move MiniHBaseCluster from src/test to
src/java so it makes it into the hadoop-*-hbase.jar renaming it
LocalHBaseCluster to follow the LocalJobRunner precedent. We should
also make the hbase.master value default "local" rather than
"0.0.0.0:60000" and start a LocalHBaseCluster . How does that sound?
See the content of src/test/hbase-default.xml if you want to tweak
things to make startup faster. The properties therein are the list to
tune if you want to make startup and shutdown snappier.
>> If the default mode -- i.e. if the hbase.master was set to 'local' in
>> hbase-default.xml -- was to run a MiniHBaseCluster instance, would
>> this suffice Andrzej? Or do you need master and regionservers
>> talking to each via direct in-process method invocations rather than
>> over sockets as is done in "local" mapreduce?
>>
>
> Direct in-process pseudo-protocol would be probably more efficient and
> it would reduce the number of sockets in use, but we could implement
> it as a future enhancement if needed. For now I'm happy with them
> using sockets.
Agreed. I do not think it would be hard having the master invoke region
server methods directly (and vice versa) rather than go via the RPC but
that we can be done later.
St.Ack
|