hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: HBase shell compatibility needs
Date Thu, 14 Aug 2014 23:50:10 GMT
On Thu, Aug 14, 2014 at 11:53 AM, Sean Busbey <busbey@cloudera.com> wrote:

> Hiya Folks!
>
> Right now, the HBase shell relies on an old version of JRuby (1.6, last
> released ~2 years ago) and a very old version of Ruby (1.8).
>
>
Yeah.  Last time this came up we passed on upgrade since 1.7.x complete jar
is many megabytes larger than the already obnoxiously big 1.6.x jar with no
discernible advantage in areas we'd benefit from (HBASE-7028).



> I'd like to start working towards refactoring the shell. Updating some of
> our underlying libraries will make it easier to fix up some of our low
> hanging improvements (start up latency, utf8 support).
>
>
Thanks for working on shell.  Its been in neglect.

What you thinking for startup latency?  In the past I tried the -client and
-d32 args but no noticeable improvement (Startup time seems to be the bane
of jruby -- http://www.slideshare.net/CharlesNutter/jruby-the-hard-parts)

(Looking a little while ago, I was wondering if with a little work, we
could do without complete jruby and include just whats needed; would take a
review to see what jruby jars had what in them)



> This got me wondering about what the bounds of changing are (esp for
> master).
>
> 1) How common is making use of the fact that our shell is actually and IRB
> session?


IRB was one of the main reasons we went ruby/jruby. It was best available
shell on survey (long time ago).



> Do we want to keep encouraging that for users? Could we change the
> focus of the IRB version to be developers of HBase? Could we just make a
> HBase client gem and provide instructions for using it in IRB?
>
>
So, you'd have to do extra steps to have working hbase install?  (Install
jruby, then install hbase gem?) IMO, this is asking too much.  I'd think
HBase should include all needed to run it.



> 2) However extensive our keeping IRB is, do we need to keep the same Ruby
> compatibility? Spanning Ruby 1.8 and 1.9 is a pain, but possible. (I know
> very few people still using 1.8 though) When Ruby 2 support lands
> supporting either of those won't be possible, because at that point JRuby
> will only support Ruby 2.1[1].
>
>
Our use of ruby is basic. If we moved to 1.9 or 2.0, etc., would any of our
scripts even break?



> 3) Do we have any guidance on compatibility across versions for the shell?
> I couldn't find anything obvious.
>
>
None. Neglected area. Guidance welcome.


> 4) Lacking #2, what do we want to ensure keeps working the same? Existing
> shell commands in the exact form they have now? Table variables (as opposed
> to setting a "current table" context for the shell session)?
>
>
Having lines return a value would be more 'natural' and what scripters
expect.  Few of our verbs have had the work done so this works (Jesse Yates
did table).  There is an old issue/complaint that our shell doesn't do this
but was never fixed' and was actually resolved as invalid: HBASE-781

Thanks Sean,
St.Ack




> [1]: https://groups.google.com/d/msg/jruby-users/qmLpZ7qDwZo/J_iYViplcq4J
>
> --
> Sean
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message