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 whe
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:ctubb...@apache.org]
Sent: Tuesday, February 23, 2016 2:06 PM
To: user@accumulo.apache.org
Subject: Re:
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 tes
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
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 wrote:
> MiniAccumuloCluster spawns
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 t
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 us
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 Native
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 he
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.el...@gmail.com]
Sent: Tuesday, February 23
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 MiniAccumuloConfi
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 gettin
12 matches
Mail list logo
