HBase
  1. HBase
  2. HBASE-8400

Load coprocessor jar from various protocols (HTTP, HTTPS, FTP, etc.)

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 0.94.3, 0.98.0
    • Fix Version/s: None
    • Component/s: Coprocessors
    • Labels:
      None
    • Tags:
      Phoenix

      Description

      In some application testing and production environment, after developed coprocessors and generated jars, currently we need to transfer them to hdfs first, then specify the URI in table descriptor to point to HDFS compatible addresses of jars. Common used HTTP/HTTPS/FTP or other protocols were not supported yet? To save time and make the life easier without transferring from http/ftp or other servers, just modified the CoprocessorHost to use http/ftp url connection (http and ftp servers are the most cases need to be support) to stream jars to coprocessor jar spaces automatically.

        Issue Links

          Activity

          Hide
          stack added a comment -

          Moving out an improvement that is not being worked on. Move it back if this situation changes.

          Show
          stack added a comment - Moving out an improvement that is not being worked on. Move it back if this situation changes.
          Hide
          James Taylor added a comment -

          We're trying to ease the installation of Phoenix (https://github.com/forcedotcom/phoenix) and this JIRA looks like it may help. Is it actively being worked on?

          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 in our SQL layer, so to speak. There's a lot of shared/foundational phoenix code being used by these coprocessors and filters that come along with them - 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 the feature provided by HBASE-1936, 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 difficult for a user to convince his admin to do, 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

          Would this JIRA get us there? Any other missing pieces? We'd be happy to be a guinea pig/test case for how to solve this issue from an application/platform standpoint.

          Thanks!

          Show
          James Taylor added a comment - We're trying to ease the installation of Phoenix ( https://github.com/forcedotcom/phoenix ) and this JIRA looks like it may help. Is it actively being worked on? 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 in our SQL layer, so to speak. There's a lot of shared/foundational phoenix code being used by these coprocessors and filters that come along with them - 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 the feature provided by HBASE-1936 , 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 difficult for a user to convince his admin to do, 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 Would this JIRA get us there? Any other missing pieces? We'd be happy to be a guinea pig/test case for how to solve this issue from an application/platform standpoint. Thanks!
          Hide
          Lars Hofhansl added a comment -

          Moving out to 0.94.9.

          Show
          Lars Hofhansl added a comment - Moving out to 0.94.9.
          Hide
          Julian Zhou added a comment -

          Thanks Andrew for pointing and connecting.
          Just studied the 8327's patch. Looks like the consolidation in it mainly located in CoprocessorClassLoader. CoprocessorHost invokes CoprocessorClassLoader#getClassLoader, in which, when #init, it invokes #copyToLocalFile to copy the jar to local first, then do #addURL for both jar or jar entries in it if any. Could we be one of the options as below:
          1) in CoprocessorClassLoader#init, check the scheme in the passed in "path", if "http/https/ftp", then use http/ftp connection to fetch remote jars streaming to local first, if not, still goes #copyToLocalFile, later logic remains unchanged. (In my testing environment, I go this way currently);
          2) in CoprocessorClassLoader#init, check the scheme in the passed in "path", if "http/https/ftp", #addURL of it directly for network loading, which would not keep a local copy in coprocessor jar space at runtime. In this approach, logic of getting jar entries within the parent jar would not be support?
          What's your idea for these options or other options?

          Thanks~

          Show
          Julian Zhou added a comment - Thanks Andrew for pointing and connecting. Just studied the 8327's patch. Looks like the consolidation in it mainly located in CoprocessorClassLoader. CoprocessorHost invokes CoprocessorClassLoader#getClassLoader, in which, when #init, it invokes #copyToLocalFile to copy the jar to local first, then do #addURL for both jar or jar entries in it if any. Could we be one of the options as below: 1) in CoprocessorClassLoader#init, check the scheme in the passed in "path", if "http/https/ftp", then use http/ftp connection to fetch remote jars streaming to local first, if not, still goes #copyToLocalFile, later logic remains unchanged. (In my testing environment, I go this way currently); 2) in CoprocessorClassLoader#init, check the scheme in the passed in "path", if "http/https/ftp", #addURL of it directly for network loading, which would not keep a local copy in coprocessor jar space at runtime. In this approach, logic of getting jar entries within the parent jar would not be support? What's your idea for these options or other options? Thanks~
          Hide
          Andrew Purtell added a comment -

          I believe what you are asking for is an alternative classloader that fetches JARs from some other type of storage. I think we can make which classloader to use for coprocessors configurable. We are consolidating classloaders in HBASE-8327. You should start there.

          Show
          Andrew Purtell added a comment - I believe what you are asking for is an alternative classloader that fetches JARs from some other type of storage. I think we can make which classloader to use for coprocessors configurable. We are consolidating classloaders in HBASE-8327 . You should start there.

            People

            • Assignee:
              Julian Zhou
              Reporter:
              Julian Zhou
            • Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:

                Development