hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kay Kay (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-2170) hbase lightweight client library as a distribution
Date Sat, 06 Mar 2010 23:22:27 GMT

    [ https://issues.apache.org/jira/browse/HBASE-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12842342#action_12842342

Kay Kay commented on HBASE-2170:

|  But from a deployment & operation perspective, it is a nightmare.

Why ? It is a nightmare now.  Theoretically - if there were a client for HBase doing some
M-R / inserts / scans - we have to add the hbase-*.jar and everything in lib/*.jar as well
, because it is monolithic. Currently - we just add hbase-0.xx.jar and add other jars as required
until there is no classnotfoundexception, which is really not the job of the client developer,
but that of the system publisher to make the distinction. 

I guess that holds true for any client/server system, to publish a light-weight client , to
focus on the server development better with different release cycles, depending on the need.

|  Can somebody please enumerate which jars are currently required by a hbase client application
and also enumerate which jars will be needed by after this patch?

The point is to shift the responsibility from the hbase client user to the hbase maintainers
, to decide which dependencies need to go with the client, so the client does not need to
do *add a jar from lib until no class not found exception occurs* algorithm.  On top of my
head - I can think of log4j / zk / thrift / rest , that would come in here. 

| Also, can somebody who is using hbase vouch for the fact that the splitting of jars is helpful?

To begin with ,  *we do* . We have a HBase farm set up , consisting of the data set / and
being inserted from the outside world and independent developers who develop on top of HBase
( on top of the ramp up curve, that they have to get on to the platform) are plain confused
by the list of jars and adding them to the client namespace, and if it does not make sense
to add , say hdfs.jar in the client lib of hbase , if all they wanted to do was to do some
scans / M-R on the hbase data, as that information is immaterial. We have plans to start using
mahout and build algorithms on top of the platform, and it makes no sense whatsoever to bring
in the hidden dependencies of hbase and expose it to the hbase client to discourage them entirely.

| The analogy I draw is that the hadoop libraries are the same for the hadoop clients as well
as servers. I have found it to be great help for operation purposes: there is lesser chance
of mixing up different incompatible versions.

But the hbase client is not meant to be on the same machine as a server ? From an operational
purpose  - you will be having a different set of jars for client and the server. And the common
jar, would not be released explicitly but be part of the client and the server as appropriate.

|   in a world of copying jars around, a single jar reduces the mess-up possibility significantly.
In an automated ops-world this is somewhat less important I hope'

The client is susceptible to less changes and the server a lot more. If there were 2 jars
- client and the server, would not that make it more clear as to the developer and the ops
as to which jar needs to be replaced and which machines are affected ? 

> hbase lightweight client library as a distribution 
> ---------------------------------------------------
>                 Key: HBASE-2170
>                 URL: https://issues.apache.org/jira/browse/HBASE-2170
>             Project: Hadoop HBase
>          Issue Type: Wish
>            Reporter: Kay Kay
> As a wish - it would be nice to have a hbase client library (subset of the current hbase
distribution) that needs to be present at the hbase client level to interact with the master/region
> From an app integration - users of hbase can just link against the client library as
opposed to getting the entire library to link against. 

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message