You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@accumulo.apache.org by Dan Blum <db...@bbn.com> on 2016/02/23 17:56:55 UTC

Unable to get Mini to use native maps - 1.6.2

In order to test to make sure we don't have more code that needs a
workaround for https://issues.apache.org/jira/browse/ACCUMULO-4148 I am
trying again to enable the native maps for Mini, which we use for testing.

I set tserver.memory.maps.native.enabled to true in the site XML, and this
is getting picked up since I see this in the Mini logs:

[server.Accumulo] INFO : tserver.memory.maps.native.enabled = true

However, NativeMap should log something when it tries to load the library,
whether it succeeds or fails, but it logs nothing. The obvious conclusion is
that something about how MiniAccumuloCluster starts means that this setting
is ignored or overridden, but I am not finding it. (I see the mergeProp call
in MiniAccumuloConfigImpl.initialize which will set TSERV_NATIVEMAP_ENABLED
to false, but that should only set it if it's not already in the properties,
which it should be, and as far as I can tell the log message above is issued
after this.)

RE: Unable to get Mini to use native maps - 1.6.2

Posted by Dan Blum <db...@bbn.com>.
Got it, thanks. The main problem we had turned out to be the way that MAC was being run, which was too clever by half (it was implemented by a former employee who shall remain nameless). Somehow it managed to filter out a small subset of logging messages including the ones produced by NativeMap – I am still not sure how.

 

From: Michael Wall [mailto:mjwall@gmail.com] 
Sent: Wednesday, February 24, 2016 4:11 PM
To: user@accumulo.apache.org
Subject: Re: Unable to get Mini to use native maps - 1.6.2

 

Dan,

 

I was unable to get Christopher's example to work as posted without steps mentioned earlier in the thread.  In the MiniAccumuloCluster code for version 1.6.2, if I am reading it correctly, you must do a couple of things.

 

1 - build the native libs

2 - call config.setNativeLibPaths(somedirectory)

 

The ProcessBuilder that is used to run the MiniAccumuloCluster does not appear to reset the environment.  But it does overwrite whatever is in DYLIB_LIBRARY_PATH and LD_LIBRARY_PATH with the value set in the config.  So you must call config.setNativeLibPaths and then use that config when you create the MiniAccumuloCluster, as far as I can tell

 

I created the following repo to show how I did it, https://github.com/mjwall/miniaccumulocluster-nativemaps.

 

Hope that helps.

 

Mike

 

 

On Tue, Feb 23, 2016 at 5:14 PM, Christopher <ct...@apache.org> wrote:

Looking at the NativeMap, it looks like it will always log some message at the INFO level if it successfully loaded the native maps, or at the ERROR level if it failed to do so (with some extra DEBUG messages while it searches the path).

I thought maybe there was a class loading race condition where NativeMap.isLoaded() returns false while it's still trying to load... that might still be a possibility (I'm not sure if this can happen with static initializer blocks?), but if it were, you'd still see the log messages about loading or not.

I can't see your code, so I don't know what's wrong, but something like the following should work fine:

 

1. MiniAccumuloConfig config = new MiniAccumuloConfig(new File("/path/to/miniDir"), "rootPassword");

2. HashMap<String,String> map = new HashMap<String,String>();

3. map.put(Property.TSERV_NATIVEMAP_ENABLED.getKey(), "true");

4. config.setSiteConfig(map);

5. MiniAccumuloCluster mini = new MiniAccumuloCluster(config);

 

On Tue, Feb 23, 2016 at 2:21 PM Dan Blum <db...@bbn.com> wrote:

In fact, we are calling that (in Groovy which is why I missed it before, not being that familiar with Groovy). I verified that the path is correct – doesn’t help.

 

From: Christopher [mailto:ctubbsii@apache.org] 
Sent: Tuesday, February 23, 2016 2:06 PM


To: user@accumulo.apache.org
Subject: Re: Unable to get Mini to use native maps - 1.6.2

 

MiniAccumuloConfig has a method, called "setNativeLibPaths(String... nativePathItems)".

You should call that method with the absolute path for your compiled native map shared library file (.so), before you start Mini.

 

On Tue, Feb 23, 2016 at 2:03 PM Josh Elser <jo...@gmail.com> wrote:

MiniAccumuloCluster spawns its own processes, though. Calling
NativeMap.isLoaded() in your test JVM isn't proving anything.

That's why you need to call these methods on MAC, you would need to
check the TabletServer*.log file(s), and make sure that its
configuration is set up properly to find the .so.

Does that make sense? Did I misinterpret you?

Dan Blum wrote:
> I'll see what I can do, but there's no simple way to pull out something
> small we can share (and it would have to be a gradle project).
>
> I confirmed that the path is not the immediate issue by adding an explicit
> call to NativeMap.isLoaded() at the start of my test - that produces logging
> from NativeMap saying it can't find the library, which is what I expect.
> Without this call NativeMap still logs nothing so the setting that should
> cause it to be referenced is getting overridden somewhere. Calling
> InstanceOperations.getSiteConfiguration and getSystemConfiguration shows
> that the native maps are enabled, however.
>
> -----Original Message-----
> From: Josh Elser [mailto:josh.elser@gmail.com]
> Sent: Tuesday, February 23, 2016 12:56 PM
> To: user@accumulo.apache.org
> Subject: Re: Unable to get Mini to use native maps - 1.6.2
>
> Well, I'm near positive that 1.6.2 had native maps working, so there
> must be something unexpected happening :). MAC should be very close to
> what a real standalone instance is doing -- if you have the ability to
> share some end-to-end project with where you are seeing this, that'd be
> extremely helpful (e.g. a Maven project that we can just run would be
> superb).
>
> Dan Blum wrote:
>> I'll take a look but I don't think the path is the problem - NativeMap
>> should try to load the library regardless of whether this path is set and
>> will log if it can't find it. This isn't happening.
>>
>> -----Original Message-----
>> From: Josh Elser [mailto:josh.elser@gmail.com]
>> Sent: Tuesday, February 23, 2016 12:27 PM
>> To: user@accumulo.apache.org
>> Subject: Re: Unable to get Mini to use native maps - 1.6.2
>>
>> Hi Dan,
>>
>> I'm seeing in our internal integration tests that we have some
>> configuration happening which (at least, intends to) configure the
>> native maps for the minicluster.
>>
>> If you're not familiar, the MiniAccumuloConfig and MiniAccumuloCluster
>> classes are thin wrappers around MiniAccumuloConfigImpl and
>> MiniAccumuloClusterImpl. There is a setNativeLibPaths method on
>> MiniAccumuloConfigImpl which you can use to provide the path to the
>> native library shared object (.so). You will probably have to switch
>> from MiniAccumuloConfig/MiniAccumuloCluster to
>> MiniAccumuloConfigImpl/MiniAccumuloClusterImpl to use the "hidden"
> methods.
>> You could also look at MiniClusterHarness.java in>=1.7 if you want a
>> concrete example of how we initialize things for our tests.
>>
>> - Josh
>>
>> Dan Blum wrote:
>>> In order to test to make sure we don't have more code that needs a
>>> workaround for https://issues.apache.org/jira/browse/ACCUMULO-4148 I am
>>> trying again to enable the native maps for Mini, which we use for
> testing.
>>> I set tserver.memory.maps.native.enabled to true in the site XML, and
> this
>>> is getting picked up since I see this in the Mini logs:
>>>
>>> [server.Accumulo] INFO : tserver.memory.maps.native.enabled = true
>>>
>>> However, NativeMap should log something when it tries to load the
> library,
>>> whether it succeeds or fails, but it logs nothing. The obvious conclusion
>> is
>>> that something about how MiniAccumuloCluster starts means that this
>> setting
>>> is ignored or overridden, but I am not finding it. (I see the mergeProp
>> call
>>> in MiniAccumuloConfigImpl.initialize which will set
>> TSERV_NATIVEMAP_ENABLED
>>> to false, but that should only set it if it's not already in the
>> properties,
>>> which it should be, and as far as I can tell the log message above is
>> issued
>>> after this.)
>>>
>

Re: Unable to get Mini to use native maps - 1.6.2

Posted by Michael Wall <mj...@gmail.com>.
Dan,

I was unable to get Christopher's example to work as posted without steps
mentioned earlier in the thread.  In the MiniAccumuloCluster code for
version 1.6.2, if I am reading it correctly, you must do a couple of things.

1 - build the native libs
2 - call config.setNativeLibPaths(somedirectory)

The ProcessBuilder that is used to run the MiniAccumuloCluster does not
appear to reset the environment.  But it does overwrite whatever is in
DYLIB_LIBRARY_PATH and LD_LIBRARY_PATH with the value set in the config.
So you must call config.setNativeLibPaths and then use that config when you
create the MiniAccumuloCluster, as far as I can tell

I created the following repo to show how I did it,
https://github.com/mjwall/miniaccumulocluster-nativemaps.

Hope that helps.

Mike


On Tue, Feb 23, 2016 at 5:14 PM, Christopher <ct...@apache.org> wrote:

> Looking at the NativeMap, it looks like it will always log some message at
> the INFO level if it successfully loaded the native maps, or at the ERROR
> level if it failed to do so (with some extra DEBUG messages while it
> searches the path).
>
> I thought maybe there was a class loading race condition where
> NativeMap.isLoaded() returns false while it's still trying to load... that
> might still be a possibility (I'm not sure if this can happen with static
> initializer blocks?), but if it were, you'd still see the log messages
> about loading or not.
>
> I can't see your code, so I don't know what's wrong, but something like
> the following should work fine:
>
> 1. MiniAccumuloConfig config = new MiniAccumuloConfig(new
> File("/path/to/miniDir"), "rootPassword");
> 2. HashMap<String,String> map = new HashMap<String,String>();
> 3. map.put(Property.TSERV_NATIVEMAP_ENABLED.getKey(), "true");
> 4. config.setSiteConfig(map);
> 5. MiniAccumuloCluster mini = new MiniAccumuloCluster(config);
>
>
> On Tue, Feb 23, 2016 at 2:21 PM Dan Blum <db...@bbn.com> wrote:
>
>> In fact, we are calling that (in Groovy which is why I missed it before,
>> not being that familiar with Groovy). I verified that the path is correct –
>> doesn’t help.
>>
>>
>>
>> *From:* Christopher [mailto:ctubbsii@apache.org]
>> *Sent:* Tuesday, February 23, 2016 2:06 PM
>>
>>
>> *To:* user@accumulo.apache.org
>> *Subject:* Re: Unable to get Mini to use native maps - 1.6.2
>>
>>
>>
>> MiniAccumuloConfig has a method, called "setNativeLibPaths(String...
>> nativePathItems)".
>>
>> You should call that method with the absolute path for your compiled
>> native map shared library file (.so), before you start Mini.
>>
>>
>>
>> On Tue, Feb 23, 2016 at 2:03 PM Josh Elser <jo...@gmail.com> wrote:
>>
>> MiniAccumuloCluster spawns its own processes, though. Calling
>> NativeMap.isLoaded() in your test JVM isn't proving anything.
>>
>> That's why you need to call these methods on MAC, you would need to
>> check the TabletServer*.log file(s), and make sure that its
>> configuration is set up properly to find the .so.
>>
>> Does that make sense? Did I misinterpret you?
>>
>> Dan Blum wrote:
>> > I'll see what I can do, but there's no simple way to pull out something
>> > small we can share (and it would have to be a gradle project).
>> >
>> > I confirmed that the path is not the immediate issue by adding an
>> explicit
>> > call to NativeMap.isLoaded() at the start of my test - that produces
>> logging
>> > from NativeMap saying it can't find the library, which is what I expect.
>> > Without this call NativeMap still logs nothing so the setting that
>> should
>> > cause it to be referenced is getting overridden somewhere. Calling
>> > InstanceOperations.getSiteConfiguration and getSystemConfiguration shows
>> > that the native maps are enabled, however.
>> >
>> > -----Original Message-----
>> > From: Josh Elser [mailto:josh.elser@gmail.com]
>> > Sent: Tuesday, February 23, 2016 12:56 PM
>> > To: user@accumulo.apache.org
>> > Subject: Re: Unable to get Mini to use native maps - 1.6.2
>> >
>> > Well, I'm near positive that 1.6.2 had native maps working, so there
>> > must be something unexpected happening :). MAC should be very close to
>> > what a real standalone instance is doing -- if you have the ability to
>> > share some end-to-end project with where you are seeing this, that'd be
>> > extremely helpful (e.g. a Maven project that we can just run would be
>> > superb).
>> >
>> > Dan Blum wrote:
>> >> I'll take a look but I don't think the path is the problem - NativeMap
>> >> should try to load the library regardless of whether this path is set
>> and
>> >> will log if it can't find it. This isn't happening.
>> >>
>> >> -----Original Message-----
>> >> From: Josh Elser [mailto:josh.elser@gmail.com]
>> >> Sent: Tuesday, February 23, 2016 12:27 PM
>> >> To: user@accumulo.apache.org
>> >> Subject: Re: Unable to get Mini to use native maps - 1.6.2
>> >>
>> >> Hi Dan,
>> >>
>> >> I'm seeing in our internal integration tests that we have some
>> >> configuration happening which (at least, intends to) configure the
>> >> native maps for the minicluster.
>> >>
>> >> If you're not familiar, the MiniAccumuloConfig and MiniAccumuloCluster
>> >> classes are thin wrappers around MiniAccumuloConfigImpl and
>> >> MiniAccumuloClusterImpl. There is a setNativeLibPaths method on
>> >> MiniAccumuloConfigImpl which you can use to provide the path to the
>> >> native library shared object (.so). You will probably have to switch
>> >> from MiniAccumuloConfig/MiniAccumuloCluster to
>> >> MiniAccumuloConfigImpl/MiniAccumuloClusterImpl to use the "hidden"
>> > methods.
>> >> You could also look at MiniClusterHarness.java in>=1.7 if you want a
>> >> concrete example of how we initialize things for our tests.
>> >>
>> >> - Josh
>> >>
>> >> Dan Blum wrote:
>> >>> In order to test to make sure we don't have more code that needs a
>> >>> workaround for https://issues.apache.org/jira/browse/ACCUMULO-4148 I
>> am
>> >>> trying again to enable the native maps for Mini, which we use for
>> > testing.
>> >>> I set tserver.memory.maps.native.enabled to true in the site XML, and
>> > this
>> >>> is getting picked up since I see this in the Mini logs:
>> >>>
>> >>> [server.Accumulo] INFO : tserver.memory.maps.native.enabled = true
>> >>>
>> >>> However, NativeMap should log something when it tries to load the
>> > library,
>> >>> whether it succeeds or fails, but it logs nothing. The obvious
>> conclusion
>> >> is
>> >>> that something about how MiniAccumuloCluster starts means that this
>> >> setting
>> >>> is ignored or overridden, but I am not finding it. (I see the
>> mergeProp
>> >> call
>> >>> in MiniAccumuloConfigImpl.initialize which will set
>> >> TSERV_NATIVEMAP_ENABLED
>> >>> to false, but that should only set it if it's not already in the
>> >> properties,
>> >>> which it should be, and as far as I can tell the log message above is
>> >> issued
>> >>> after this.)
>> >>>
>> >
>>
>>

Re: Unable to get Mini to use native maps - 1.6.2

Posted by Christopher <ct...@apache.org>.
Looking at the NativeMap, it looks like it will always log some message at
the INFO level if it successfully loaded the native maps, or at the ERROR
level if it failed to do so (with some extra DEBUG messages while it
searches the path).

I thought maybe there was a class loading race condition where
NativeMap.isLoaded() returns false while it's still trying to load... that
might still be a possibility (I'm not sure if this can happen with static
initializer blocks?), but if it were, you'd still see the log messages
about loading or not.

I can't see your code, so I don't know what's wrong, but something like the
following should work fine:

1. MiniAccumuloConfig config = new MiniAccumuloConfig(new
File("/path/to/miniDir"), "rootPassword");
2. HashMap<String,String> map = new HashMap<String,String>();
3. map.put(Property.TSERV_NATIVEMAP_ENABLED.getKey(), "true");
4. config.setSiteConfig(map);
5. MiniAccumuloCluster mini = new MiniAccumuloCluster(config);


On Tue, Feb 23, 2016 at 2:21 PM Dan Blum <db...@bbn.com> wrote:

> In fact, we are calling that (in Groovy which is why I missed it before,
> not being that familiar with Groovy). I verified that the path is correct –
> doesn’t help.
>
>
>
> *From:* Christopher [mailto:ctubbsii@apache.org]
> *Sent:* Tuesday, February 23, 2016 2:06 PM
>
>
> *To:* user@accumulo.apache.org
> *Subject:* Re: Unable to get Mini to use native maps - 1.6.2
>
>
>
> MiniAccumuloConfig has a method, called "setNativeLibPaths(String...
> nativePathItems)".
>
> You should call that method with the absolute path for your compiled
> native map shared library file (.so), before you start Mini.
>
>
>
> On Tue, Feb 23, 2016 at 2:03 PM Josh Elser <jo...@gmail.com> wrote:
>
> MiniAccumuloCluster spawns its own processes, though. Calling
> NativeMap.isLoaded() in your test JVM isn't proving anything.
>
> That's why you need to call these methods on MAC, you would need to
> check the TabletServer*.log file(s), and make sure that its
> configuration is set up properly to find the .so.
>
> Does that make sense? Did I misinterpret you?
>
> Dan Blum wrote:
> > I'll see what I can do, but there's no simple way to pull out something
> > small we can share (and it would have to be a gradle project).
> >
> > I confirmed that the path is not the immediate issue by adding an
> explicit
> > call to NativeMap.isLoaded() at the start of my test - that produces
> logging
> > from NativeMap saying it can't find the library, which is what I expect.
> > Without this call NativeMap still logs nothing so the setting that should
> > cause it to be referenced is getting overridden somewhere. Calling
> > InstanceOperations.getSiteConfiguration and getSystemConfiguration shows
> > that the native maps are enabled, however.
> >
> > -----Original Message-----
> > From: Josh Elser [mailto:josh.elser@gmail.com]
> > Sent: Tuesday, February 23, 2016 12:56 PM
> > To: user@accumulo.apache.org
> > Subject: Re: Unable to get Mini to use native maps - 1.6.2
> >
> > Well, I'm near positive that 1.6.2 had native maps working, so there
> > must be something unexpected happening :). MAC should be very close to
> > what a real standalone instance is doing -- if you have the ability to
> > share some end-to-end project with where you are seeing this, that'd be
> > extremely helpful (e.g. a Maven project that we can just run would be
> > superb).
> >
> > Dan Blum wrote:
> >> I'll take a look but I don't think the path is the problem - NativeMap
> >> should try to load the library regardless of whether this path is set
> and
> >> will log if it can't find it. This isn't happening.
> >>
> >> -----Original Message-----
> >> From: Josh Elser [mailto:josh.elser@gmail.com]
> >> Sent: Tuesday, February 23, 2016 12:27 PM
> >> To: user@accumulo.apache.org
> >> Subject: Re: Unable to get Mini to use native maps - 1.6.2
> >>
> >> Hi Dan,
> >>
> >> I'm seeing in our internal integration tests that we have some
> >> configuration happening which (at least, intends to) configure the
> >> native maps for the minicluster.
> >>
> >> If you're not familiar, the MiniAccumuloConfig and MiniAccumuloCluster
> >> classes are thin wrappers around MiniAccumuloConfigImpl and
> >> MiniAccumuloClusterImpl. There is a setNativeLibPaths method on
> >> MiniAccumuloConfigImpl which you can use to provide the path to the
> >> native library shared object (.so). You will probably have to switch
> >> from MiniAccumuloConfig/MiniAccumuloCluster to
> >> MiniAccumuloConfigImpl/MiniAccumuloClusterImpl to use the "hidden"
> > methods.
> >> You could also look at MiniClusterHarness.java in>=1.7 if you want a
> >> concrete example of how we initialize things for our tests.
> >>
> >> - Josh
> >>
> >> Dan Blum wrote:
> >>> In order to test to make sure we don't have more code that needs a
> >>> workaround for https://issues.apache.org/jira/browse/ACCUMULO-4148 I
> am
> >>> trying again to enable the native maps for Mini, which we use for
> > testing.
> >>> I set tserver.memory.maps.native.enabled to true in the site XML, and
> > this
> >>> is getting picked up since I see this in the Mini logs:
> >>>
> >>> [server.Accumulo] INFO : tserver.memory.maps.native.enabled = true
> >>>
> >>> However, NativeMap should log something when it tries to load the
> > library,
> >>> whether it succeeds or fails, but it logs nothing. The obvious
> conclusion
> >> is
> >>> that something about how MiniAccumuloCluster starts means that this
> >> setting
> >>> is ignored or overridden, but I am not finding it. (I see the mergeProp
> >> call
> >>> in MiniAccumuloConfigImpl.initialize which will set
> >> TSERV_NATIVEMAP_ENABLED
> >>> to false, but that should only set it if it's not already in the
> >> properties,
> >>> which it should be, and as far as I can tell the log message above is
> >> issued
> >>> after this.)
> >>>
> >
>
>

RE: Unable to get Mini to use native maps - 1.6.2

Posted by Dan Blum <db...@bbn.com>.
In fact, we are calling that (in Groovy which is why I missed it before, not being that familiar with Groovy). I verified that the path is correct – doesn’t help.

 

From: Christopher [mailto:ctubbsii@apache.org] 
Sent: Tuesday, February 23, 2016 2:06 PM
To: user@accumulo.apache.org
Subject: Re: Unable to get Mini to use native maps - 1.6.2

 

MiniAccumuloConfig has a method, called "setNativeLibPaths(String... nativePathItems)".

You should call that method with the absolute path for your compiled native map shared library file (.so), before you start Mini.

 

On Tue, Feb 23, 2016 at 2:03 PM Josh Elser <jo...@gmail.com> wrote:

MiniAccumuloCluster spawns its own processes, though. Calling
NativeMap.isLoaded() in your test JVM isn't proving anything.

That's why you need to call these methods on MAC, you would need to
check the TabletServer*.log file(s), and make sure that its
configuration is set up properly to find the .so.

Does that make sense? Did I misinterpret you?

Dan Blum wrote:
> I'll see what I can do, but there's no simple way to pull out something
> small we can share (and it would have to be a gradle project).
>
> I confirmed that the path is not the immediate issue by adding an explicit
> call to NativeMap.isLoaded() at the start of my test - that produces logging
> from NativeMap saying it can't find the library, which is what I expect.
> Without this call NativeMap still logs nothing so the setting that should
> cause it to be referenced is getting overridden somewhere. Calling
> InstanceOperations.getSiteConfiguration and getSystemConfiguration shows
> that the native maps are enabled, however.
>
> -----Original Message-----
> From: Josh Elser [mailto:josh.elser@gmail.com]
> Sent: Tuesday, February 23, 2016 12:56 PM
> To: user@accumulo.apache.org
> Subject: Re: Unable to get Mini to use native maps - 1.6.2
>
> Well, I'm near positive that 1.6.2 had native maps working, so there
> must be something unexpected happening :). MAC should be very close to
> what a real standalone instance is doing -- if you have the ability to
> share some end-to-end project with where you are seeing this, that'd be
> extremely helpful (e.g. a Maven project that we can just run would be
> superb).
>
> Dan Blum wrote:
>> I'll take a look but I don't think the path is the problem - NativeMap
>> should try to load the library regardless of whether this path is set and
>> will log if it can't find it. This isn't happening.
>>
>> -----Original Message-----
>> From: Josh Elser [mailto:josh.elser@gmail.com]
>> Sent: Tuesday, February 23, 2016 12:27 PM
>> To: user@accumulo.apache.org
>> Subject: Re: Unable to get Mini to use native maps - 1.6.2
>>
>> Hi Dan,
>>
>> I'm seeing in our internal integration tests that we have some
>> configuration happening which (at least, intends to) configure the
>> native maps for the minicluster.
>>
>> If you're not familiar, the MiniAccumuloConfig and MiniAccumuloCluster
>> classes are thin wrappers around MiniAccumuloConfigImpl and
>> MiniAccumuloClusterImpl. There is a setNativeLibPaths method on
>> MiniAccumuloConfigImpl which you can use to provide the path to the
>> native library shared object (.so). You will probably have to switch
>> from MiniAccumuloConfig/MiniAccumuloCluster to
>> MiniAccumuloConfigImpl/MiniAccumuloClusterImpl to use the "hidden"
> methods.
>> You could also look at MiniClusterHarness.java in>=1.7 if you want a
>> concrete example of how we initialize things for our tests.
>>
>> - Josh
>>
>> Dan Blum wrote:
>>> In order to test to make sure we don't have more code that needs a
>>> workaround for https://issues.apache.org/jira/browse/ACCUMULO-4148 I am
>>> trying again to enable the native maps for Mini, which we use for
> testing.
>>> I set tserver.memory.maps.native.enabled to true in the site XML, and
> this
>>> is getting picked up since I see this in the Mini logs:
>>>
>>> [server.Accumulo] INFO : tserver.memory.maps.native.enabled = true
>>>
>>> However, NativeMap should log something when it tries to load the
> library,
>>> whether it succeeds or fails, but it logs nothing. The obvious conclusion
>> is
>>> that something about how MiniAccumuloCluster starts means that this
>> setting
>>> is ignored or overridden, but I am not finding it. (I see the mergeProp
>> call
>>> in MiniAccumuloConfigImpl.initialize which will set
>> TSERV_NATIVEMAP_ENABLED
>>> to false, but that should only set it if it's not already in the
>> properties,
>>> which it should be, and as far as I can tell the log message above is
>> issued
>>> after this.)
>>>
>

Re: Unable to get Mini to use native maps - 1.6.2

Posted by Christopher <ct...@apache.org>.
MiniAccumuloConfig has a method, called "setNativeLibPaths(String...
nativePathItems)".
You should call that method with the absolute path for your compiled native
map shared library file (.so), before you start Mini.

On Tue, Feb 23, 2016 at 2:03 PM Josh Elser <jo...@gmail.com> wrote:

> MiniAccumuloCluster spawns its own processes, though. Calling
> NativeMap.isLoaded() in your test JVM isn't proving anything.
>
> That's why you need to call these methods on MAC, you would need to
> check the TabletServer*.log file(s), and make sure that its
> configuration is set up properly to find the .so.
>
> Does that make sense? Did I misinterpret you?
>
> Dan Blum wrote:
> > I'll see what I can do, but there's no simple way to pull out something
> > small we can share (and it would have to be a gradle project).
> >
> > I confirmed that the path is not the immediate issue by adding an
> explicit
> > call to NativeMap.isLoaded() at the start of my test - that produces
> logging
> > from NativeMap saying it can't find the library, which is what I expect.
> > Without this call NativeMap still logs nothing so the setting that should
> > cause it to be referenced is getting overridden somewhere. Calling
> > InstanceOperations.getSiteConfiguration and getSystemConfiguration shows
> > that the native maps are enabled, however.
> >
> > -----Original Message-----
> > From: Josh Elser [mailto:josh.elser@gmail.com]
> > Sent: Tuesday, February 23, 2016 12:56 PM
> > To: user@accumulo.apache.org
> > Subject: Re: Unable to get Mini to use native maps - 1.6.2
> >
> > Well, I'm near positive that 1.6.2 had native maps working, so there
> > must be something unexpected happening :). MAC should be very close to
> > what a real standalone instance is doing -- if you have the ability to
> > share some end-to-end project with where you are seeing this, that'd be
> > extremely helpful (e.g. a Maven project that we can just run would be
> > superb).
> >
> > Dan Blum wrote:
> >> I'll take a look but I don't think the path is the problem - NativeMap
> >> should try to load the library regardless of whether this path is set
> and
> >> will log if it can't find it. This isn't happening.
> >>
> >> -----Original Message-----
> >> From: Josh Elser [mailto:josh.elser@gmail.com]
> >> Sent: Tuesday, February 23, 2016 12:27 PM
> >> To: user@accumulo.apache.org
> >> Subject: Re: Unable to get Mini to use native maps - 1.6.2
> >>
> >> Hi Dan,
> >>
> >> I'm seeing in our internal integration tests that we have some
> >> configuration happening which (at least, intends to) configure the
> >> native maps for the minicluster.
> >>
> >> If you're not familiar, the MiniAccumuloConfig and MiniAccumuloCluster
> >> classes are thin wrappers around MiniAccumuloConfigImpl and
> >> MiniAccumuloClusterImpl. There is a setNativeLibPaths method on
> >> MiniAccumuloConfigImpl which you can use to provide the path to the
> >> native library shared object (.so). You will probably have to switch
> >> from MiniAccumuloConfig/MiniAccumuloCluster to
> >> MiniAccumuloConfigImpl/MiniAccumuloClusterImpl to use the "hidden"
> > methods.
> >> You could also look at MiniClusterHarness.java in>=1.7 if you want a
> >> concrete example of how we initialize things for our tests.
> >>
> >> - Josh
> >>
> >> Dan Blum wrote:
> >>> In order to test to make sure we don't have more code that needs a
> >>> workaround for https://issues.apache.org/jira/browse/ACCUMULO-4148 I
> am
> >>> trying again to enable the native maps for Mini, which we use for
> > testing.
> >>> I set tserver.memory.maps.native.enabled to true in the site XML, and
> > this
> >>> is getting picked up since I see this in the Mini logs:
> >>>
> >>> [server.Accumulo] INFO : tserver.memory.maps.native.enabled = true
> >>>
> >>> However, NativeMap should log something when it tries to load the
> > library,
> >>> whether it succeeds or fails, but it logs nothing. The obvious
> conclusion
> >> is
> >>> that something about how MiniAccumuloCluster starts means that this
> >> setting
> >>> is ignored or overridden, but I am not finding it. (I see the mergeProp
> >> call
> >>> in MiniAccumuloConfigImpl.initialize which will set
> >> TSERV_NATIVEMAP_ENABLED
> >>> to false, but that should only set it if it's not already in the
> >> properties,
> >>> which it should be, and as far as I can tell the log message above is
> >> issued
> >>> after this.)
> >>>
> >
>

Re: Unable to get Mini to use native maps - 1.6.2

Posted by Josh Elser <jo...@gmail.com>.
It would be really helpful if you could write up a minimal Groovy 
project that we can run that is doing exactly what you're trying.

I'm personally not sure what else to tell you: there are specific 
methods exposed which set up the native maps for MAC and these are 
exercised by our internal tests. If there's something we can pull 
down/run, it'll be much easier for us to provide more help/recommendations.

Dan Blum wrote:
> I understand, but I should be seeing the same configuration as the MAC
> process - or if not, why would it be different?
>
> The MAC logs have mostly been what I have been looking at. As noted, they
> have logging from NativeMap at all, which means it isn't even trying to load
> the library. Granted I have to make sure it can find the library, but that
> doesn't help if it never looks for it at all.
>
> -----Original Message-----
> From: Josh Elser [mailto:josh.elser@gmail.com]
> Sent: Tuesday, February 23, 2016 2:03 PM
> To: user@accumulo.apache.org
> Subject: Re: Unable to get Mini to use native maps - 1.6.2
>
> MiniAccumuloCluster spawns its own processes, though. Calling
> NativeMap.isLoaded() in your test JVM isn't proving anything.
>
> That's why you need to call these methods on MAC, you would need to
> check the TabletServer*.log file(s), and make sure that its
> configuration is set up properly to find the .so.
>
> Does that make sense? Did I misinterpret you?
>
> Dan Blum wrote:
>> I'll see what I can do, but there's no simple way to pull out something
>> small we can share (and it would have to be a gradle project).
>>
>> I confirmed that the path is not the immediate issue by adding an explicit
>> call to NativeMap.isLoaded() at the start of my test - that produces
> logging
>> from NativeMap saying it can't find the library, which is what I expect.
>> Without this call NativeMap still logs nothing so the setting that should
>> cause it to be referenced is getting overridden somewhere. Calling
>> InstanceOperations.getSiteConfiguration and getSystemConfiguration shows
>> that the native maps are enabled, however.
>>
>> -----Original Message-----
>> From: Josh Elser [mailto:josh.elser@gmail.com]
>> Sent: Tuesday, February 23, 2016 12:56 PM
>> To: user@accumulo.apache.org
>> Subject: Re: Unable to get Mini to use native maps - 1.6.2
>>
>> Well, I'm near positive that 1.6.2 had native maps working, so there
>> must be something unexpected happening :). MAC should be very close to
>> what a real standalone instance is doing -- if you have the ability to
>> share some end-to-end project with where you are seeing this, that'd be
>> extremely helpful (e.g. a Maven project that we can just run would be
>> superb).
>>
>> Dan Blum wrote:
>>> I'll take a look but I don't think the path is the problem - NativeMap
>>> should try to load the library regardless of whether this path is set and
>>> will log if it can't find it. This isn't happening.
>>>
>>> -----Original Message-----
>>> From: Josh Elser [mailto:josh.elser@gmail.com]
>>> Sent: Tuesday, February 23, 2016 12:27 PM
>>> To: user@accumulo.apache.org
>>> Subject: Re: Unable to get Mini to use native maps - 1.6.2
>>>
>>> Hi Dan,
>>>
>>> I'm seeing in our internal integration tests that we have some
>>> configuration happening which (at least, intends to) configure the
>>> native maps for the minicluster.
>>>
>>> If you're not familiar, the MiniAccumuloConfig and MiniAccumuloCluster
>>> classes are thin wrappers around MiniAccumuloConfigImpl and
>>> MiniAccumuloClusterImpl. There is a setNativeLibPaths method on
>>> MiniAccumuloConfigImpl which you can use to provide the path to the
>>> native library shared object (.so). You will probably have to switch
>>> from MiniAccumuloConfig/MiniAccumuloCluster to
>>> MiniAccumuloConfigImpl/MiniAccumuloClusterImpl to use the "hidden"
>> methods.
>>> You could also look at MiniClusterHarness.java in>=1.7 if you want a
>>> concrete example of how we initialize things for our tests.
>>>
>>> - Josh
>>>
>>> Dan Blum wrote:
>>>> In order to test to make sure we don't have more code that needs a
>>>> workaround for https://issues.apache.org/jira/browse/ACCUMULO-4148 I am
>>>> trying again to enable the native maps for Mini, which we use for
>> testing.
>>>> I set tserver.memory.maps.native.enabled to true in the site XML, and
>> this
>>>> is getting picked up since I see this in the Mini logs:
>>>>
>>>> [server.Accumulo] INFO : tserver.memory.maps.native.enabled = true
>>>>
>>>> However, NativeMap should log something when it tries to load the
>> library,
>>>> whether it succeeds or fails, but it logs nothing. The obvious
> conclusion
>>> is
>>>> that something about how MiniAccumuloCluster starts means that this
>>> setting
>>>> is ignored or overridden, but I am not finding it. (I see the mergeProp
>>> call
>>>> in MiniAccumuloConfigImpl.initialize which will set
>>> TSERV_NATIVEMAP_ENABLED
>>>> to false, but that should only set it if it's not already in the
>>> properties,
>>>> which it should be, and as far as I can tell the log message above is
>>> issued
>>>> after this.)
>>>>
>

RE: Unable to get Mini to use native maps - 1.6.2

Posted by Dan Blum <db...@bbn.com>.
I understand, but I should be seeing the same configuration as the MAC
process - or if not, why would it be different?

The MAC logs have mostly been what I have been looking at. As noted, they
have logging from NativeMap at all, which means it isn't even trying to load
the library. Granted I have to make sure it can find the library, but that
doesn't help if it never looks for it at all.

-----Original Message-----
From: Josh Elser [mailto:josh.elser@gmail.com] 
Sent: Tuesday, February 23, 2016 2:03 PM
To: user@accumulo.apache.org
Subject: Re: Unable to get Mini to use native maps - 1.6.2

MiniAccumuloCluster spawns its own processes, though. Calling 
NativeMap.isLoaded() in your test JVM isn't proving anything.

That's why you need to call these methods on MAC, you would need to 
check the TabletServer*.log file(s), and make sure that its 
configuration is set up properly to find the .so.

Does that make sense? Did I misinterpret you?

Dan Blum wrote:
> I'll see what I can do, but there's no simple way to pull out something
> small we can share (and it would have to be a gradle project).
>
> I confirmed that the path is not the immediate issue by adding an explicit
> call to NativeMap.isLoaded() at the start of my test - that produces
logging
> from NativeMap saying it can't find the library, which is what I expect.
> Without this call NativeMap still logs nothing so the setting that should
> cause it to be referenced is getting overridden somewhere. Calling
> InstanceOperations.getSiteConfiguration and getSystemConfiguration shows
> that the native maps are enabled, however.
>
> -----Original Message-----
> From: Josh Elser [mailto:josh.elser@gmail.com]
> Sent: Tuesday, February 23, 2016 12:56 PM
> To: user@accumulo.apache.org
> Subject: Re: Unable to get Mini to use native maps - 1.6.2
>
> Well, I'm near positive that 1.6.2 had native maps working, so there
> must be something unexpected happening :). MAC should be very close to
> what a real standalone instance is doing -- if you have the ability to
> share some end-to-end project with where you are seeing this, that'd be
> extremely helpful (e.g. a Maven project that we can just run would be
> superb).
>
> Dan Blum wrote:
>> I'll take a look but I don't think the path is the problem - NativeMap
>> should try to load the library regardless of whether this path is set and
>> will log if it can't find it. This isn't happening.
>>
>> -----Original Message-----
>> From: Josh Elser [mailto:josh.elser@gmail.com]
>> Sent: Tuesday, February 23, 2016 12:27 PM
>> To: user@accumulo.apache.org
>> Subject: Re: Unable to get Mini to use native maps - 1.6.2
>>
>> Hi Dan,
>>
>> I'm seeing in our internal integration tests that we have some
>> configuration happening which (at least, intends to) configure the
>> native maps for the minicluster.
>>
>> If you're not familiar, the MiniAccumuloConfig and MiniAccumuloCluster
>> classes are thin wrappers around MiniAccumuloConfigImpl and
>> MiniAccumuloClusterImpl. There is a setNativeLibPaths method on
>> MiniAccumuloConfigImpl which you can use to provide the path to the
>> native library shared object (.so). You will probably have to switch
>> from MiniAccumuloConfig/MiniAccumuloCluster to
>> MiniAccumuloConfigImpl/MiniAccumuloClusterImpl to use the "hidden"
> methods.
>> You could also look at MiniClusterHarness.java in>=1.7 if you want a
>> concrete example of how we initialize things for our tests.
>>
>> - Josh
>>
>> Dan Blum wrote:
>>> In order to test to make sure we don't have more code that needs a
>>> workaround for https://issues.apache.org/jira/browse/ACCUMULO-4148 I am
>>> trying again to enable the native maps for Mini, which we use for
> testing.
>>> I set tserver.memory.maps.native.enabled to true in the site XML, and
> this
>>> is getting picked up since I see this in the Mini logs:
>>>
>>> [server.Accumulo] INFO : tserver.memory.maps.native.enabled = true
>>>
>>> However, NativeMap should log something when it tries to load the
> library,
>>> whether it succeeds or fails, but it logs nothing. The obvious
conclusion
>> is
>>> that something about how MiniAccumuloCluster starts means that this
>> setting
>>> is ignored or overridden, but I am not finding it. (I see the mergeProp
>> call
>>> in MiniAccumuloConfigImpl.initialize which will set
>> TSERV_NATIVEMAP_ENABLED
>>> to false, but that should only set it if it's not already in the
>> properties,
>>> which it should be, and as far as I can tell the log message above is
>> issued
>>> after this.)
>>>
>

Re: Unable to get Mini to use native maps - 1.6.2

Posted by Josh Elser <jo...@gmail.com>.
MiniAccumuloCluster spawns its own processes, though. Calling 
NativeMap.isLoaded() in your test JVM isn't proving anything.

That's why you need to call these methods on MAC, you would need to 
check the TabletServer*.log file(s), and make sure that its 
configuration is set up properly to find the .so.

Does that make sense? Did I misinterpret you?

Dan Blum wrote:
> I'll see what I can do, but there's no simple way to pull out something
> small we can share (and it would have to be a gradle project).
>
> I confirmed that the path is not the immediate issue by adding an explicit
> call to NativeMap.isLoaded() at the start of my test - that produces logging
> from NativeMap saying it can't find the library, which is what I expect.
> Without this call NativeMap still logs nothing so the setting that should
> cause it to be referenced is getting overridden somewhere. Calling
> InstanceOperations.getSiteConfiguration and getSystemConfiguration shows
> that the native maps are enabled, however.
>
> -----Original Message-----
> From: Josh Elser [mailto:josh.elser@gmail.com]
> Sent: Tuesday, February 23, 2016 12:56 PM
> To: user@accumulo.apache.org
> Subject: Re: Unable to get Mini to use native maps - 1.6.2
>
> Well, I'm near positive that 1.6.2 had native maps working, so there
> must be something unexpected happening :). MAC should be very close to
> what a real standalone instance is doing -- if you have the ability to
> share some end-to-end project with where you are seeing this, that'd be
> extremely helpful (e.g. a Maven project that we can just run would be
> superb).
>
> Dan Blum wrote:
>> I'll take a look but I don't think the path is the problem - NativeMap
>> should try to load the library regardless of whether this path is set and
>> will log if it can't find it. This isn't happening.
>>
>> -----Original Message-----
>> From: Josh Elser [mailto:josh.elser@gmail.com]
>> Sent: Tuesday, February 23, 2016 12:27 PM
>> To: user@accumulo.apache.org
>> Subject: Re: Unable to get Mini to use native maps - 1.6.2
>>
>> Hi Dan,
>>
>> I'm seeing in our internal integration tests that we have some
>> configuration happening which (at least, intends to) configure the
>> native maps for the minicluster.
>>
>> If you're not familiar, the MiniAccumuloConfig and MiniAccumuloCluster
>> classes are thin wrappers around MiniAccumuloConfigImpl and
>> MiniAccumuloClusterImpl. There is a setNativeLibPaths method on
>> MiniAccumuloConfigImpl which you can use to provide the path to the
>> native library shared object (.so). You will probably have to switch
>> from MiniAccumuloConfig/MiniAccumuloCluster to
>> MiniAccumuloConfigImpl/MiniAccumuloClusterImpl to use the "hidden"
> methods.
>> You could also look at MiniClusterHarness.java in>=1.7 if you want a
>> concrete example of how we initialize things for our tests.
>>
>> - Josh
>>
>> Dan Blum wrote:
>>> In order to test to make sure we don't have more code that needs a
>>> workaround for https://issues.apache.org/jira/browse/ACCUMULO-4148 I am
>>> trying again to enable the native maps for Mini, which we use for
> testing.
>>> I set tserver.memory.maps.native.enabled to true in the site XML, and
> this
>>> is getting picked up since I see this in the Mini logs:
>>>
>>> [server.Accumulo] INFO : tserver.memory.maps.native.enabled = true
>>>
>>> However, NativeMap should log something when it tries to load the
> library,
>>> whether it succeeds or fails, but it logs nothing. The obvious conclusion
>> is
>>> that something about how MiniAccumuloCluster starts means that this
>> setting
>>> is ignored or overridden, but I am not finding it. (I see the mergeProp
>> call
>>> in MiniAccumuloConfigImpl.initialize which will set
>> TSERV_NATIVEMAP_ENABLED
>>> to false, but that should only set it if it's not already in the
>> properties,
>>> which it should be, and as far as I can tell the log message above is
>> issued
>>> after this.)
>>>
>

RE: Unable to get Mini to use native maps - 1.6.2

Posted by Dan Blum <db...@bbn.com>.
I'll see what I can do, but there's no simple way to pull out something
small we can share (and it would have to be a gradle project).

I confirmed that the path is not the immediate issue by adding an explicit
call to NativeMap.isLoaded() at the start of my test - that produces logging
from NativeMap saying it can't find the library, which is what I expect.
Without this call NativeMap still logs nothing so the setting that should
cause it to be referenced is getting overridden somewhere. Calling
InstanceOperations.getSiteConfiguration and getSystemConfiguration shows
that the native maps are enabled, however.

-----Original Message-----
From: Josh Elser [mailto:josh.elser@gmail.com] 
Sent: Tuesday, February 23, 2016 12:56 PM
To: user@accumulo.apache.org
Subject: Re: Unable to get Mini to use native maps - 1.6.2

Well, I'm near positive that 1.6.2 had native maps working, so there 
must be something unexpected happening :). MAC should be very close to 
what a real standalone instance is doing -- if you have the ability to 
share some end-to-end project with where you are seeing this, that'd be 
extremely helpful (e.g. a Maven project that we can just run would be 
superb).

Dan Blum wrote:
> I'll take a look but I don't think the path is the problem - NativeMap
> should try to load the library regardless of whether this path is set and
> will log if it can't find it. This isn't happening.
>
> -----Original Message-----
> From: Josh Elser [mailto:josh.elser@gmail.com]
> Sent: Tuesday, February 23, 2016 12:27 PM
> To: user@accumulo.apache.org
> Subject: Re: Unable to get Mini to use native maps - 1.6.2
>
> Hi Dan,
>
> I'm seeing in our internal integration tests that we have some
> configuration happening which (at least, intends to) configure the
> native maps for the minicluster.
>
> If you're not familiar, the MiniAccumuloConfig and MiniAccumuloCluster
> classes are thin wrappers around MiniAccumuloConfigImpl and
> MiniAccumuloClusterImpl. There is a setNativeLibPaths method on
> MiniAccumuloConfigImpl which you can use to provide the path to the
> native library shared object (.so). You will probably have to switch
> from MiniAccumuloConfig/MiniAccumuloCluster to
> MiniAccumuloConfigImpl/MiniAccumuloClusterImpl to use the "hidden"
methods.
>
> You could also look at MiniClusterHarness.java in>=1.7 if you want a
> concrete example of how we initialize things for our tests.
>
> - Josh
>
> Dan Blum wrote:
>> In order to test to make sure we don't have more code that needs a
>> workaround for https://issues.apache.org/jira/browse/ACCUMULO-4148 I am
>> trying again to enable the native maps for Mini, which we use for
testing.
>>
>> I set tserver.memory.maps.native.enabled to true in the site XML, and
this
>> is getting picked up since I see this in the Mini logs:
>>
>> [server.Accumulo] INFO : tserver.memory.maps.native.enabled = true
>>
>> However, NativeMap should log something when it tries to load the
library,
>> whether it succeeds or fails, but it logs nothing. The obvious conclusion
> is
>> that something about how MiniAccumuloCluster starts means that this
> setting
>> is ignored or overridden, but I am not finding it. (I see the mergeProp
> call
>> in MiniAccumuloConfigImpl.initialize which will set
> TSERV_NATIVEMAP_ENABLED
>> to false, but that should only set it if it's not already in the
> properties,
>> which it should be, and as far as I can tell the log message above is
> issued
>> after this.)
>>
>

Re: Unable to get Mini to use native maps - 1.6.2

Posted by Josh Elser <jo...@gmail.com>.
Well, I'm near positive that 1.6.2 had native maps working, so there 
must be something unexpected happening :). MAC should be very close to 
what a real standalone instance is doing -- if you have the ability to 
share some end-to-end project with where you are seeing this, that'd be 
extremely helpful (e.g. a Maven project that we can just run would be 
superb).

Dan Blum wrote:
> I'll take a look but I don't think the path is the problem - NativeMap
> should try to load the library regardless of whether this path is set and
> will log if it can't find it. This isn't happening.
>
> -----Original Message-----
> From: Josh Elser [mailto:josh.elser@gmail.com]
> Sent: Tuesday, February 23, 2016 12:27 PM
> To: user@accumulo.apache.org
> Subject: Re: Unable to get Mini to use native maps - 1.6.2
>
> Hi Dan,
>
> I'm seeing in our internal integration tests that we have some
> configuration happening which (at least, intends to) configure the
> native maps for the minicluster.
>
> If you're not familiar, the MiniAccumuloConfig and MiniAccumuloCluster
> classes are thin wrappers around MiniAccumuloConfigImpl and
> MiniAccumuloClusterImpl. There is a setNativeLibPaths method on
> MiniAccumuloConfigImpl which you can use to provide the path to the
> native library shared object (.so). You will probably have to switch
> from MiniAccumuloConfig/MiniAccumuloCluster to
> MiniAccumuloConfigImpl/MiniAccumuloClusterImpl to use the "hidden" methods.
>
> You could also look at MiniClusterHarness.java in>=1.7 if you want a
> concrete example of how we initialize things for our tests.
>
> - Josh
>
> Dan Blum wrote:
>> In order to test to make sure we don't have more code that needs a
>> workaround for https://issues.apache.org/jira/browse/ACCUMULO-4148 I am
>> trying again to enable the native maps for Mini, which we use for testing.
>>
>> I set tserver.memory.maps.native.enabled to true in the site XML, and this
>> is getting picked up since I see this in the Mini logs:
>>
>> [server.Accumulo] INFO : tserver.memory.maps.native.enabled = true
>>
>> However, NativeMap should log something when it tries to load the library,
>> whether it succeeds or fails, but it logs nothing. The obvious conclusion
> is
>> that something about how MiniAccumuloCluster starts means that this
> setting
>> is ignored or overridden, but I am not finding it. (I see the mergeProp
> call
>> in MiniAccumuloConfigImpl.initialize which will set
> TSERV_NATIVEMAP_ENABLED
>> to false, but that should only set it if it's not already in the
> properties,
>> which it should be, and as far as I can tell the log message above is
> issued
>> after this.)
>>
>

RE: Unable to get Mini to use native maps - 1.6.2

Posted by Dan Blum <db...@bbn.com>.
I'll take a look but I don't think the path is the problem - NativeMap
should try to load the library regardless of whether this path is set and
will log if it can't find it. This isn't happening.

-----Original Message-----
From: Josh Elser [mailto:josh.elser@gmail.com] 
Sent: Tuesday, February 23, 2016 12:27 PM
To: user@accumulo.apache.org
Subject: Re: Unable to get Mini to use native maps - 1.6.2

Hi Dan,

I'm seeing in our internal integration tests that we have some 
configuration happening which (at least, intends to) configure the 
native maps for the minicluster.

If you're not familiar, the MiniAccumuloConfig and MiniAccumuloCluster 
classes are thin wrappers around MiniAccumuloConfigImpl and 
MiniAccumuloClusterImpl. There is a setNativeLibPaths method on 
MiniAccumuloConfigImpl which you can use to provide the path to the 
native library shared object (.so). You will probably have to switch 
from MiniAccumuloConfig/MiniAccumuloCluster to 
MiniAccumuloConfigImpl/MiniAccumuloClusterImpl to use the "hidden" methods.

You could also look at MiniClusterHarness.java in >=1.7 if you want a 
concrete example of how we initialize things for our tests.

- Josh

Dan Blum wrote:
> In order to test to make sure we don't have more code that needs a
> workaround for https://issues.apache.org/jira/browse/ACCUMULO-4148 I am
> trying again to enable the native maps for Mini, which we use for testing.
>
> I set tserver.memory.maps.native.enabled to true in the site XML, and this
> is getting picked up since I see this in the Mini logs:
>
> [server.Accumulo] INFO : tserver.memory.maps.native.enabled = true
>
> However, NativeMap should log something when it tries to load the library,
> whether it succeeds or fails, but it logs nothing. The obvious conclusion
is
> that something about how MiniAccumuloCluster starts means that this
setting
> is ignored or overridden, but I am not finding it. (I see the mergeProp
call
> in MiniAccumuloConfigImpl.initialize which will set
TSERV_NATIVEMAP_ENABLED
> to false, but that should only set it if it's not already in the
properties,
> which it should be, and as far as I can tell the log message above is
issued
> after this.)
>

Re: Unable to get Mini to use native maps - 1.6.2

Posted by Josh Elser <jo...@gmail.com>.
Hi Dan,

I'm seeing in our internal integration tests that we have some 
configuration happening which (at least, intends to) configure the 
native maps for the minicluster.

If you're not familiar, the MiniAccumuloConfig and MiniAccumuloCluster 
classes are thin wrappers around MiniAccumuloConfigImpl and 
MiniAccumuloClusterImpl. There is a setNativeLibPaths method on 
MiniAccumuloConfigImpl which you can use to provide the path to the 
native library shared object (.so). You will probably have to switch 
from MiniAccumuloConfig/MiniAccumuloCluster to 
MiniAccumuloConfigImpl/MiniAccumuloClusterImpl to use the "hidden" methods.

You could also look at MiniClusterHarness.java in >=1.7 if you want a 
concrete example of how we initialize things for our tests.

- Josh

Dan Blum wrote:
> In order to test to make sure we don't have more code that needs a
> workaround for https://issues.apache.org/jira/browse/ACCUMULO-4148 I am
> trying again to enable the native maps for Mini, which we use for testing.
>
> I set tserver.memory.maps.native.enabled to true in the site XML, and this
> is getting picked up since I see this in the Mini logs:
>
> [server.Accumulo] INFO : tserver.memory.maps.native.enabled = true
>
> However, NativeMap should log something when it tries to load the library,
> whether it succeeds or fails, but it logs nothing. The obvious conclusion is
> that something about how MiniAccumuloCluster starts means that this setting
> is ignored or overridden, but I am not finding it. (I see the mergeProp call
> in MiniAccumuloConfigImpl.initialize which will set TSERV_NATIVEMAP_ENABLED
> to false, but that should only set it if it's not already in the properties,
> which it should be, and as far as I can tell the log message above is issued
> after this.)
>

Re: Unable to get Mini to use native maps - 1.6.2

Posted by Michael Wall <mj...@gmail.com>.
Dan,

My first though was are you setting LD_LIBRARY_PATH or
DYLIB_LIBRARY_PATH to a directory that contains the libaccumulo shared
library?  If that didn't work, are you setting
-Djava.library.path=whateverdirectory.

But looking through the code, at least in 1.6, it looks like the NativeMap
is using java.library.path to load that shared library, see
https://github.com/apache/accumulo/blob/1.6/server/tserver/src/main/java/org/apache/accumulo/tserver/NativeMap.java#L77.
I don't see where the environment variables LD_LIBRARY_PATH or
DYLIB_LIBRARY_PATH are automatically setting up the java.library.path for
the MiniAccumuloCluster.  I see where they are read though, at
https://github.com/apache/accumulo/blob/master/minicluster/src/main/java/org/apache/accumulo/minicluster/impl/MiniAccumuloClusterImpl.java#L316
.

To Josh's point, these are used when you call config.getNativeLibPaths()
yourself and then use that config to create a new MiniAccumuloCluster.  See
https://github.com/apache/accumulo/blob/1.6/test/src/test/java/org/apache/accumulo/harness/MiniClusterHarness.java#L81
for
an example.  One thing to note is this harness is in the test module, which
is run after the native module.  The native module builds the shared
library during the integration-test phase, at
https://github.com/apache/accumulo/blob/1.6/server/native/pom.xml#L102.  So
the shared libraries are available when the test module runs, which is why
they can be used to test native functionality.  However, these shared
libraries are not published anywhere, so you will have to build them.  For
instructions on building them from a downloaded version of Accumulo 1.6 see
http://accumulo.apache.org/1.6/accumulo_user_manual.html#_native_map_building
.

Hope that helps.

Mike





On Tue, Feb 23, 2016 at 11:56 AM, Dan Blum <db...@bbn.com> wrote:

> In order to test to make sure we don't have more code that needs a
> workaround for https://issues.apache.org/jira/browse/ACCUMULO-4148 I am
> trying again to enable the native maps for Mini, which we use for testing.
>
> I set tserver.memory.maps.native.enabled to true in the site XML, and this
> is getting picked up since I see this in the Mini logs:
>
> [server.Accumulo] INFO : tserver.memory.maps.native.enabled = true
>
> However, NativeMap should log something when it tries to load the library,
> whether it succeeds or fails, but it logs nothing. The obvious conclusion
> is
> that something about how MiniAccumuloCluster starts means that this setting
> is ignored or overridden, but I am not finding it. (I see the mergeProp
> call
> in MiniAccumuloConfigImpl.initialize which will set TSERV_NATIVEMAP_ENABLED
> to false, but that should only set it if it's not already in the
> properties,
> which it should be, and as far as I can tell the log message above is
> issued
> after this.)
>
>