You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@accumulo.apache.org by Dylan Hutchison <dh...@stevens.edu> on 2014/10/24 00:44:55 UTC
Accumulo version at runtime?
Easy question Accumulators:
Is there an easy way to grab the version of a running Accumulo instance
programmatically from Java code in a class that connects to the instance?
Something like:
Instance instance = new
ZooKeeperInstance("instanceName","zookeeper_address");
String version = instance.getInstanceVersion();
Thanks, Dylan
--
www.cs.stevens.edu/~dhutchis
Re: Accumulo version at runtime?
Posted by Keith Turner <ke...@deenlo.com>.
On Fri, Oct 24, 2014 at 6:00 PM, Dylan Hutchison <dh...@stevens.edu>
wrote:
> Keith, I'm confused as to how you would run reflection
>
> Constants.class.getDeclaredField("VERSION").get(String.class)
>
> on the Accumulo server. Wouldn't we need to compile in a function
> returning that into the server for a custom Accumulo server build?
>
Didn't realize you were looking for the info from a server. Thats
certainly not going to work for that case. The approach is for getting
client lib version.
>
> Say we have a 1.6 Accumulo instance live. A client needs to know the
> version in order to load the appropriate class. How would you execute that
> code on the server if it is built from the standard Accumulo 1.6 binaries?
>
> On Fri, Oct 24, 2014 at 10:22 AM, Keith Turner <ke...@deenlo.com> wrote:
>
>> Below is something I wrote for 1.4 that would grab the version using
>> reflection. If the constant has moved in later versions, could gracefully
>> handle class not found and field not found exceptions and look in other
>> places.
>>
>>
>> https://github.com/keith-turner/instamo/blob/master/src/main/java/instamo/MiniAccumuloCluster.java#L357
>>
>> On Fri, Oct 24, 2014 at 1:38 AM, Dylan Hutchison <dh...@stevens.edu>
>> wrote:
>>
>>> How about a compromise: create *two classes *for the two versions, both
>>> implementing the same interface. Instantiate the class for the correct
>>> version either from (1) static configuration file or (2) runtime "hack"
>>> lookup to the version on the Monitor.
>>>
>>> (1) gives safety at the expense of the user having to specify another
>>> parameter. (2) looks like it will work at least in the near future going
>>> to 1.7, as well as for past versions.
>>>
>>> Thanks for the suggestions! I like the two classes approach better both
>>> as a developer and as a user; no need to juggle JARs.
>>>
>>> ~Dylan
>>>
>>>
>>> On Fri, Oct 24, 2014 at 12:41 AM, Sean Busbey <bu...@cloudera.com>
>>> wrote:
>>>
>>>>
>>>> On Thu, Oct 23, 2014 at 10:38 PM, Dylan Hutchison <dhutchis@stevens.edu
>>>> > wrote:
>>>>
>>>>>
>>>>>> I'm working on a clean way to handle getting Accumulo monitor info
>>>>> for different versions of Accumulo, since I used methods to extract that
>>>>> information from Accumulo's internals which are version-dependent. As Sean
>>>>> wrote, these are not things one should do, but if it's a choice between
>>>>> getting the info or not...
>>>>> We're thinking of building separate JARs for each 1.x version.
>>>>>
>>>>>
>>>> Why not just take the version of Accumulo you're going to talk to as
>>>> configuration information that's given to you as a part of deploying your
>>>> software?
>>>>
>>>> It'll make your life much simpler in the long run.
>>>>
>>>>
>>>> --
>>>> Sean
>>>>
>>>
>>>
>>>
>>> --
>>> www.cs.stevens.edu/~dhutchis
>>>
>>
>>
>
>
> --
> www.cs.stevens.edu/~dhutchis
>
Re: Accumulo version at runtime?
Posted by Corey Nolet <cj...@gmail.com>.
Dylan,
I know your original post mentioned grabbing it through the client API but
there's not currently a way to do that. As Sean mentioned, you can do it if
you have access to the cluster. You can run the reflection Keith provided
by adding the files in $ACCUMULO_HOME/lib/ to your classpath and running
your code on the cluster. I definitely think exposing the server version
should make it into 1.7.
On Fri, Oct 24, 2014 at 6:00 PM, Dylan Hutchison <dh...@stevens.edu>
wrote:
> Keith, I'm confused as to how you would run reflection
>
> Constants.class.getDeclaredField("VERSION").get(String.class)
>
> on the Accumulo server. Wouldn't we need to compile in a function
> returning that into the server for a custom Accumulo server build?
>
> Say we have a 1.6 Accumulo instance live. A client needs to know the
> version in order to load the appropriate class. How would you execute that
> code on the server if it is built from the standard Accumulo 1.6 binaries?
>
> On Fri, Oct 24, 2014 at 10:22 AM, Keith Turner <ke...@deenlo.com> wrote:
>
>> Below is something I wrote for 1.4 that would grab the version using
>> reflection. If the constant has moved in later versions, could gracefully
>> handle class not found and field not found exceptions and look in other
>> places.
>>
>>
>> https://github.com/keith-turner/instamo/blob/master/src/main/java/instamo/MiniAccumuloCluster.java#L357
>>
>> On Fri, Oct 24, 2014 at 1:38 AM, Dylan Hutchison <dh...@stevens.edu>
>> wrote:
>>
>>> How about a compromise: create *two classes *for the two versions, both
>>> implementing the same interface. Instantiate the class for the correct
>>> version either from (1) static configuration file or (2) runtime "hack"
>>> lookup to the version on the Monitor.
>>>
>>> (1) gives safety at the expense of the user having to specify another
>>> parameter. (2) looks like it will work at least in the near future going
>>> to 1.7, as well as for past versions.
>>>
>>> Thanks for the suggestions! I like the two classes approach better both
>>> as a developer and as a user; no need to juggle JARs.
>>>
>>> ~Dylan
>>>
>>>
>>> On Fri, Oct 24, 2014 at 12:41 AM, Sean Busbey <bu...@cloudera.com>
>>> wrote:
>>>
>>>>
>>>> On Thu, Oct 23, 2014 at 10:38 PM, Dylan Hutchison <dhutchis@stevens.edu
>>>> > wrote:
>>>>
>>>>>
>>>>>> I'm working on a clean way to handle getting Accumulo monitor info
>>>>> for different versions of Accumulo, since I used methods to extract that
>>>>> information from Accumulo's internals which are version-dependent. As Sean
>>>>> wrote, these are not things one should do, but if it's a choice between
>>>>> getting the info or not...
>>>>> We're thinking of building separate JARs for each 1.x version.
>>>>>
>>>>>
>>>> Why not just take the version of Accumulo you're going to talk to as
>>>> configuration information that's given to you as a part of deploying your
>>>> software?
>>>>
>>>> It'll make your life much simpler in the long run.
>>>>
>>>>
>>>> --
>>>> Sean
>>>>
>>>
>>>
>>>
>>> --
>>> www.cs.stevens.edu/~dhutchis
>>>
>>
>>
>
>
> --
> www.cs.stevens.edu/~dhutchis
>
Re: Accumulo version at runtime?
Posted by Dylan Hutchison <dh...@stevens.edu>.
Keith, I'm confused as to how you would run reflection
Constants.class.getDeclaredField("VERSION").get(String.class)
on the Accumulo server. Wouldn't we need to compile in a function
returning that into the server for a custom Accumulo server build?
Say we have a 1.6 Accumulo instance live. A client needs to know the
version in order to load the appropriate class. How would you execute that
code on the server if it is built from the standard Accumulo 1.6 binaries?
On Fri, Oct 24, 2014 at 10:22 AM, Keith Turner <ke...@deenlo.com> wrote:
> Below is something I wrote for 1.4 that would grab the version using
> reflection. If the constant has moved in later versions, could gracefully
> handle class not found and field not found exceptions and look in other
> places.
>
>
> https://github.com/keith-turner/instamo/blob/master/src/main/java/instamo/MiniAccumuloCluster.java#L357
>
> On Fri, Oct 24, 2014 at 1:38 AM, Dylan Hutchison <dh...@stevens.edu>
> wrote:
>
>> How about a compromise: create *two classes *for the two versions, both
>> implementing the same interface. Instantiate the class for the correct
>> version either from (1) static configuration file or (2) runtime "hack"
>> lookup to the version on the Monitor.
>>
>> (1) gives safety at the expense of the user having to specify another
>> parameter. (2) looks like it will work at least in the near future going
>> to 1.7, as well as for past versions.
>>
>> Thanks for the suggestions! I like the two classes approach better both
>> as a developer and as a user; no need to juggle JARs.
>>
>> ~Dylan
>>
>>
>> On Fri, Oct 24, 2014 at 12:41 AM, Sean Busbey <bu...@cloudera.com>
>> wrote:
>>
>>>
>>> On Thu, Oct 23, 2014 at 10:38 PM, Dylan Hutchison <dh...@stevens.edu>
>>> wrote:
>>>
>>>>
>>>>> I'm working on a clean way to handle getting Accumulo monitor info for
>>>> different versions of Accumulo, since I used methods to extract that
>>>> information from Accumulo's internals which are version-dependent. As Sean
>>>> wrote, these are not things one should do, but if it's a choice between
>>>> getting the info or not...
>>>> We're thinking of building separate JARs for each 1.x version.
>>>>
>>>>
>>> Why not just take the version of Accumulo you're going to talk to as
>>> configuration information that's given to you as a part of deploying your
>>> software?
>>>
>>> It'll make your life much simpler in the long run.
>>>
>>>
>>> --
>>> Sean
>>>
>>
>>
>>
>> --
>> www.cs.stevens.edu/~dhutchis
>>
>
>
--
www.cs.stevens.edu/~dhutchis
Re: Accumulo version at runtime?
Posted by Keith Turner <ke...@deenlo.com>.
Below is something I wrote for 1.4 that would grab the version using
reflection. If the constant has moved in later versions, could gracefully
handle class not found and field not found exceptions and look in other
places.
https://github.com/keith-turner/instamo/blob/master/src/main/java/instamo/MiniAccumuloCluster.java#L357
On Fri, Oct 24, 2014 at 1:38 AM, Dylan Hutchison <dh...@stevens.edu>
wrote:
> How about a compromise: create *two classes *for the two versions, both
> implementing the same interface. Instantiate the class for the correct
> version either from (1) static configuration file or (2) runtime "hack"
> lookup to the version on the Monitor.
>
> (1) gives safety at the expense of the user having to specify another
> parameter. (2) looks like it will work at least in the near future going
> to 1.7, as well as for past versions.
>
> Thanks for the suggestions! I like the two classes approach better both
> as a developer and as a user; no need to juggle JARs.
>
> ~Dylan
>
>
> On Fri, Oct 24, 2014 at 12:41 AM, Sean Busbey <bu...@cloudera.com> wrote:
>
>>
>> On Thu, Oct 23, 2014 at 10:38 PM, Dylan Hutchison <dh...@stevens.edu>
>> wrote:
>>
>>>
>>>> I'm working on a clean way to handle getting Accumulo monitor info for
>>> different versions of Accumulo, since I used methods to extract that
>>> information from Accumulo's internals which are version-dependent. As Sean
>>> wrote, these are not things one should do, but if it's a choice between
>>> getting the info or not...
>>> We're thinking of building separate JARs for each 1.x version.
>>>
>>>
>> Why not just take the version of Accumulo you're going to talk to as
>> configuration information that's given to you as a part of deploying your
>> software?
>>
>> It'll make your life much simpler in the long run.
>>
>>
>> --
>> Sean
>>
>
>
>
> --
> www.cs.stevens.edu/~dhutchis
>
Re: Accumulo version at runtime?
Posted by Dylan Hutchison <dh...@stevens.edu>.
How about a compromise: create *two classes *for the two versions, both
implementing the same interface. Instantiate the class for the correct
version either from (1) static configuration file or (2) runtime "hack"
lookup to the version on the Monitor.
(1) gives safety at the expense of the user having to specify another
parameter. (2) looks like it will work at least in the near future going
to 1.7, as well as for past versions.
Thanks for the suggestions! I like the two classes approach better both as
a developer and as a user; no need to juggle JARs.
~Dylan
On Fri, Oct 24, 2014 at 12:41 AM, Sean Busbey <bu...@cloudera.com> wrote:
>
> On Thu, Oct 23, 2014 at 10:38 PM, Dylan Hutchison <dh...@stevens.edu>
> wrote:
>
>>
>>> I'm working on a clean way to handle getting Accumulo monitor info for
>> different versions of Accumulo, since I used methods to extract that
>> information from Accumulo's internals which are version-dependent. As Sean
>> wrote, these are not things one should do, but if it's a choice between
>> getting the info or not...
>> We're thinking of building separate JARs for each 1.x version.
>>
>>
> Why not just take the version of Accumulo you're going to talk to as
> configuration information that's given to you as a part of deploying your
> software?
>
> It'll make your life much simpler in the long run.
>
>
> --
> Sean
>
--
www.cs.stevens.edu/~dhutchis
Re: Accumulo version at runtime?
Posted by Sean Busbey <bu...@cloudera.com>.
On Thu, Oct 23, 2014 at 10:38 PM, Dylan Hutchison <dh...@stevens.edu>
wrote:
>
>> I'm working on a clean way to handle getting Accumulo monitor info for
> different versions of Accumulo, since I used methods to extract that
> information from Accumulo's internals which are version-dependent. As Sean
> wrote, these are not things one should do, but if it's a choice between
> getting the info or not...
> We're thinking of building separate JARs for each 1.x version.
>
>
Why not just take the version of Accumulo you're going to talk to as
configuration information that's given to you as a part of deploying your
software?
It'll make your life much simpler in the long run.
--
Sean
Re: Accumulo version at runtime?
Posted by Dylan Hutchison <dh...@stevens.edu>.
>
> There is https://issues.apache.org/jira/browse/ACCUMULO-1826 which you
> could follow and help get into 1.7.0 :)
>
Thanks, I should remember to check JIRA first =)
I'm working on a clean way to handle getting Accumulo monitor info for
different versions of Accumulo, since I used methods to extract that
information from Accumulo's internals which are version-dependent. As Sean
wrote, these are not things one should do, but if it's a choice between
getting the info or not...
We're thinking of building separate JARs for each 1.x version.
Seems that ACCUMULO-3005
<https://issues.apache.org/jira/browse/ACCUMULO-3005> will solve all these
monitor-info-related issues. Too bad that doesn't help with 1.5 and 1.6
which we need to support.
On Thu, Oct 23, 2014 at 11:26 PM, Sean Busbey <bu...@cloudera.com> wrote:
> If you need something now and are willing to do some hackiness, there are
> a couple of options depending on what kind of access to the cluster you
> have.
>
> These are not things one should do, so drop me a note off list if you want
> to pursue it.
>
> On Thu, Oct 23, 2014 at 9:18 PM, Josh Elser <jo...@gmail.com> wrote:
>
>> There is https://issues.apache.org/jira/browse/ACCUMULO-1826 which you
>> could follow and help get into 1.7.0 :)
>>
>> Mike Drob wrote:
>>
>>> Unfortunately, I don't think we have a way to do this. Are you trying to
>>> check for the existence of a particular feature, or what is your goal?
>>>
>>> On Thu, Oct 23, 2014 at 6:44 PM, Dylan Hutchison <dhutchis@stevens.edu
>>> <ma...@stevens.edu>> wrote:
>>>
>>> Easy question Accumulators:
>>>
>>> Is there an easy way to grab the version of a running Accumulo
>>> instance programmatically from Java code in a class that connects
>>> to the instance?
>>>
>>> Something like:
>>>
>>> Instance instance = new
>>> ZooKeeperInstance("instanceName","zookeeper_address");
>>> String version = instance.getInstanceVersion();
>>>
>>>
>>> Thanks, Dylan
>>>
>>> -- www.cs.stevens.edu/~dhutchis <http://www.cs.stevens.edu/~
>>> dhutchis>
>>>
>>>
>>>
>
>
> --
> Sean
>
--
www.cs.stevens.edu/~dhutchis
Re: Accumulo version at runtime?
Posted by Sean Busbey <bu...@cloudera.com>.
If you need something now and are willing to do some hackiness, there are a
couple of options depending on what kind of access to the cluster you have.
These are not things one should do, so drop me a note off list if you want
to pursue it.
On Thu, Oct 23, 2014 at 9:18 PM, Josh Elser <jo...@gmail.com> wrote:
> There is https://issues.apache.org/jira/browse/ACCUMULO-1826 which you
> could follow and help get into 1.7.0 :)
>
> Mike Drob wrote:
>
>> Unfortunately, I don't think we have a way to do this. Are you trying to
>> check for the existence of a particular feature, or what is your goal?
>>
>> On Thu, Oct 23, 2014 at 6:44 PM, Dylan Hutchison <dhutchis@stevens.edu
>> <ma...@stevens.edu>> wrote:
>>
>> Easy question Accumulators:
>>
>> Is there an easy way to grab the version of a running Accumulo
>> instance programmatically from Java code in a class that connects
>> to the instance?
>>
>> Something like:
>>
>> Instance instance = new
>> ZooKeeperInstance("instanceName","zookeeper_address");
>> String version = instance.getInstanceVersion();
>>
>>
>> Thanks, Dylan
>>
>> -- www.cs.stevens.edu/~dhutchis <http://www.cs.stevens.edu/~
>> dhutchis>
>>
>>
>>
--
Sean
Re: Accumulo version at runtime?
Posted by Josh Elser <jo...@gmail.com>.
There is https://issues.apache.org/jira/browse/ACCUMULO-1826 which you could follow and help get into 1.7.0 :)
Mike Drob wrote:
> Unfortunately, I don't think we have a way to do this. Are you trying
> to check for the existence of a particular feature, or what is your goal?
>
> On Thu, Oct 23, 2014 at 6:44 PM, Dylan Hutchison <dhutchis@stevens.edu
> <ma...@stevens.edu>> wrote:
>
> Easy question Accumulators:
>
> Is there an easy way to grab the version of a running Accumulo
> instance programmatically from Java code in a class that connects
> to the instance?
>
> Something like:
>
> Instance instance = new
> ZooKeeperInstance("instanceName","zookeeper_address");
> String version = instance.getInstanceVersion();
>
>
> Thanks, Dylan
>
> --
> www.cs.stevens.edu/~dhutchis <http://www.cs.stevens.edu/~dhutchis>
>
>
Re: Accumulo version at runtime?
Posted by Mike Drob <ma...@cloudera.com>.
Unfortunately, I don't think we have a way to do this. Are you trying to
check for the existence of a particular feature, or what is your goal?
On Thu, Oct 23, 2014 at 6:44 PM, Dylan Hutchison <dh...@stevens.edu>
wrote:
> Easy question Accumulators:
>
> Is there an easy way to grab the version of a running Accumulo instance
> programmatically from Java code in a class that connects to the instance?
>
> Something like:
>
> Instance instance = new
> ZooKeeperInstance("instanceName","zookeeper_address");
> String version = instance.getInstanceVersion();
>
>
> Thanks, Dylan
>
> --
> www.cs.stevens.edu/~dhutchis
>