hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Taylor (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-1936) ClassLoader that loads from hdfs; useful adding filters to classpath without having to restart services
Date Sat, 01 Jun 2013 00:05:21 GMT

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

James Taylor commented on HBASE-1936:

We're looking into leveraging this new feature to ease the installation of Phoenix (https://github.com/forcedotcom/phoenix).
Currently we require that the phoenix jar be copied into the HBase lib dir of every region
server, followed by a restart. For some background, Phoenix uses both coprocessors and custom
filters. These are just the tip of the iceberg, so to speak. There's a ton of shared/foundational
phoenix code being used by these coprocessors and filters - our type system, expression evaluation,
schema interpretation, throttling code, memory management, etc. So when we say we'd like to
upgrade our coprocessor and custom filters to a new version, that means all the foundational
classes under it have changed as well.

If we use this new feature, we're not sure we're easing the burden on our users, since users
will still need to:
1) update the hbase-sites.xml on each region server to set the hbase.dynamics.jar.dir path
of the jar
2) copy the phoenix jar to hdfs
3) make a sym link to the new phoenix jar
4) get a rolling restart to be done on the cluster

My fear would be that (1) would be error prone, and for (2) & (3) the user wouldn't have
the necessary perms. And (4), we'll probably just have to live with, but in a utopia, we could
just have the new jar be used for new coprocessor/filter invocations.

My question: how close can we come to automating all of this to the point where we could have
a phoenix install script that looks like this:

hbase install phoenix-1.2.jar

Is HBASE-8400 a prerequisite? Any other missing pieces? We'd be happy to be a guinea pig/test
case for how to solve this problem from a real application/platform standpoint.

> ClassLoader that loads from hdfs; useful adding filters to classpath without having to
restart services
> -------------------------------------------------------------------------------------------------------
>                 Key: HBASE-1936
>                 URL: https://issues.apache.org/jira/browse/HBASE-1936
>             Project: HBase
>          Issue Type: New Feature
>            Reporter: stack
>            Assignee: Jimmy Xiang
>              Labels: noob
>             Fix For: 0.98.0, 0.94.7, 0.95.1
>         Attachments: 0.94-1936.patch, cp_from_hdfs.patch, HBASE-1936-trunk(forReview).patch,
trunk-1936.patch, trunk-1936_v2.1.patch, trunk-1936_v2.2.patch, trunk-1936_v2.patch, trunk-1936_v3.patch

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message