Mailing-List: contact hbase-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hbase-issues@hadoop.apache.org
Message-ID: <2146746297.121201267917747255.JavaMail.jira@brutus.apache.org>
Date: Sat, 6 Mar 2010 23:22:27 +0000 (UTC)
From: "Kay Kay (JIRA)" <jira@apache.org>
To: hbase-issues@hadoop.apache.org
Subject: [jira] Commented: (HBASE-2170) hbase lightweight client library as
 a distribution
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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 servers. 
> 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.