Also the native map is a Map> ... when doing
updates for a mutation, it gets the Map once and uses
that.This can be much faster than a Map, because for
Map each insert may have to traverse a deeper tree than
inserting into Map
The benefit of using a BatchScanner in the AccumuloRowInputFormat is that
it can fetch multiple ranges in parallel within each Mapper. This may be
able to help you manage your MapReduce job resources a bit better (see the
discussion in the JIRA issue for details). If you don't need to use it, I
Accumulo 1.7.0 with HDFS 2.7.1
I was experimenting with openjdk instead of Oracle JRE for Accumulo and ran
into this issue. It seems like because it never transitions from HAVE_LOCK
to NORMAL, it never gets around to start the thrift server. Changing back
to Oracle JRE didn't make a
Thank you!
What might be going on with the state transition of the master? Looks like the
tservers can’t talk to the master without the thrift interface. Is there
another interface I can enable on the master?
From: Christopher [mailto:ctubb...@apache.org]
Sent: Thursday, December
I use openjdk8 from Ubuntu 16.04 and Centos 7 packages to run Accumulo
all the time without issue.
On Thu, Dec 1, 2016 at 5:24 PM, Jayesh Patel wrote:
> Accumulo 1.7.0 with HDFS 2.7.1
>
>
>
> I was experimenting with openjdk instead of Oracle JRE for Accumulo and ran
> into
This issue described doesn't seem related to the JDK. Yes, you should
expect Accumulo to work with OpenJDK. While we don't prescribe a JDK for
users, most of the developers have an interest in ensuring at least OpenJDK
and Oracle JDK work well. A few people care about IBM JDK also, and we
accept
I can't be sure why the master is stuck in that state. It could be a bug in
1.7.0. Can you reproduce in 1.7.2?
On Thu, Dec 1, 2016 at 5:56 PM Jayesh Patel wrote:
> Thank you!
>
>
>
> What might be going on with the state transition of the master? Looks
> like the tservers