Re: openjdk, Accumulo master state doesn't change from HAVE_LOCK to NORMAL

[Christopher]

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 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 01, 2016 5:34 PM
> *To:* user@accumulo.apache.org
> *Subject:* Re: openjdk, Accumulo master state doesn't change from
> HAVE_LOCK to NORMAL
>
>
>
> 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 contributions to fix issues relevant to IBM JDK.
>
> Personally, I use OpenJDK 8 exclusively, and haven't seen this 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.  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 difference.
>
>
>
> Here’s what I get in the logs for the master:
>
> 2016-12-01 17:01:07,970 [trace.DistributedTrace] INFO : SpanReceiver
> org.apache.accumulo.tracer.ZooTraceCli
>
> ent was loaded successfully.
>
> 2016-12-01 17:01:07,971 [master.Master] INFO : trying to get master lock
>
> 2016-12-01 17:01:07,987 [master.EventCoordinator] INFO : State changed
> from INITIAL to HAVE_LOCK
>
> 2016-12-01 17:01:08,038 [master.Master] INFO : New servers:
> [instance-accumulo:9997[258ac79197e000d]]
>
>
>
> On the successful install it transitions right away to NORMAL and goes on
> the listen on port :
>
> 2015-06-07 17:50:35,393 [master.Master] INFO : trying to get master lock
>
> 2015-06-07 17:50:35,408 [master.EventCoordinator] INFO : State changed
> from INITIAL to HAVE_LOCK
>
> 2015-06-07 17:50:35,432 [master.EventCoordinator] INFO : State changed
> from HAVE_LOCK to NORMAL
>
> 2015-06-07 17:50:35,524 [balancer.TableLoadBalancer] INFO : Loaded class
> org.apache.accumulo.server.master.balancer.DefaultLoadBalancer for table !0
>
> 2015-06-07 17:50:35,631 [master.Master] INFO : Setting master lock data to
> 127.0.0.1:
> 
>
>
>
> I found ACCUMULO-4513
> ,
> but it doesn’t seem relevant as I didn’t try to stop.
>
>
>
> Any ideas as to what is going on?
>
>
>
> HDFS seems fine based on my limited tests with openjdk 1.8.  I did find
> some old posts about Accumulo issues with IBM JDK.  Should I expect
> Accumulo to work with openjdk?
>
>
>
> Thank you,
> Jayesh
>
>
>
>

RE: openjdk, Accumulo master state doesn't change from HAVE_LOCK to NORMAL

[Jayesh Patel]

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 01, 2016 5:34 PM
To: user@accumulo.apache.org
Subject: Re: openjdk, Accumulo master state doesn't change from HAVE_LOCK to 
NORMAL

 

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 contributions to 
fix issues relevant to IBM JDK.

Personally, I use OpenJDK 8 exclusively, and haven't seen this 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.  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 difference.

 

Here’s what I get in the logs for the master:

2016-12-01 17:01:07,970 [trace.DistributedTrace] INFO : SpanReceiver 
org.apache.accumulo.tracer.ZooTraceCli

ent was loaded successfully.

2016-12-01 17:01:07,971 [master.Master] INFO : trying to get master lock

2016-12-01 17:01:07,987 [master.EventCoordinator] INFO : State changed from 
INITIAL to HAVE_LOCK

2016-12-01 17:01:08,038 [master.Master] INFO : New servers: 
[instance-accumulo:9997[258ac79197e000d]]

 

On the successful install it transitions right away to NORMAL and goes on the 
listen on port :

2015-06-07 17:50:35,393 [master.Master] INFO : trying to get master lock

2015-06-07 17:50:35,408 [master.EventCoordinator] INFO : State changed from 
INITIAL to HAVE_LOCK

2015-06-07 17:50:35,432 [master.EventCoordinator] INFO : State changed from 
HAVE_LOCK to NORMAL

2015-06-07 17:50:35,524 [balancer.TableLoadBalancer] INFO : Loaded class 
org.apache.accumulo.server.master.balancer.DefaultLoadBalancer for table !0

2015-06-07 17:50:35,631 [master.Master] INFO : Setting master lock data to 
127.0.0.1: 

 

 

I found ACCUMULO-4513 

 , but it doesn’t seem relevant as I didn’t try to stop.  

 

Any ideas as to what is going on?

 

HDFS seems fine based on my limited tests with openjdk 1.8.  I did find some 
old posts about Accumulo issues with IBM JDK.  Should I expect Accumulo to work 
with openjdk?

 

Thank you,
Jayesh

 



smime.p7s
Description: S/MIME cryptographic signature

Re: openjdk, Accumulo master state doesn't change from HAVE_LOCK to NORMAL

[Christopher]

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 contributions to fix issues relevant to IBM JDK.

Personally, I use OpenJDK 8 exclusively, and haven't seen this 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.  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 difference.
>
>
>
> Here’s what I get in the logs for the master:
>
> 2016-12-01 17:01:07,970 [trace.DistributedTrace] INFO : SpanReceiver
> org.apache.accumulo.tracer.ZooTraceCli
>
> ent was loaded successfully.
>
> 2016-12-01 17:01:07,971 [master.Master] INFO : trying to get master lock
>
> 2016-12-01 17:01:07,987 [master.EventCoordinator] INFO : State changed
> from INITIAL to HAVE_LOCK
>
> 2016-12-01 17:01:08,038 [master.Master] INFO : New servers:
> [instance-accumulo:9997[258ac79197e000d]]
>
>
>
> On the successful install it transitions right away to NORMAL and goes on
> the listen on port :
>
> 2015-06-07 17:50:35,393 [master.Master] INFO : trying to get master lock
>
> 2015-06-07 17:50:35,408 [master.EventCoordinator] INFO : State changed
> from INITIAL to HAVE_LOCK
>
> 2015-06-07 17:50:35,432 [master.EventCoordinator] INFO : State changed
> from HAVE_LOCK to NORMAL
>
> 2015-06-07 17:50:35,524 [balancer.TableLoadBalancer] INFO : Loaded class
> org.apache.accumulo.server.master.balancer.DefaultLoadBalancer for table !0
>
> 2015-06-07 17:50:35,631 [master.Master] INFO : Setting master lock data to
> 127.0.0.1:
>
>
>
> I found ACCUMULO-4513
> , but it doesn’t
> seem relevant as I didn’t try to stop.
>
>
>
> Any ideas as to what is going on?
>
>
>
> HDFS seems fine based on my limited tests with openjdk 1.8.  I did find
> some old posts about Accumulo issues with IBM JDK.  Should I expect
> Accumulo to work with openjdk?
>
>
>
> Thank you,
> Jayesh
>
>
>

Re: openjdk, Accumulo master state doesn't change from HAVE_LOCK to NORMAL

[Keith Turner]

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.  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 difference.
>
>
>
> Here’s what I get in the logs for the master:
>
> 2016-12-01 17:01:07,970 [trace.DistributedTrace] INFO : SpanReceiver
> org.apache.accumulo.tracer.ZooTraceCli
>
> ent was loaded successfully.
>
> 2016-12-01 17:01:07,971 [master.Master] INFO : trying to get master lock
>
> 2016-12-01 17:01:07,987 [master.EventCoordinator] INFO : State changed from
> INITIAL to HAVE_LOCK
>
> 2016-12-01 17:01:08,038 [master.Master] INFO : New servers:
> [instance-accumulo:9997[258ac79197e000d]]
>
>
>
> On the successful install it transitions right away to NORMAL and goes on
> the listen on port :
>
> 2015-06-07 17:50:35,393 [master.Master] INFO : trying to get master lock
>
> 2015-06-07 17:50:35,408 [master.EventCoordinator] INFO : State changed from
> INITIAL to HAVE_LOCK
>
> 2015-06-07 17:50:35,432 [master.EventCoordinator] INFO : State changed from
> HAVE_LOCK to NORMAL
>
> 2015-06-07 17:50:35,524 [balancer.TableLoadBalancer] INFO : Loaded class
> org.apache.accumulo.server.master.balancer.DefaultLoadBalancer for table !0
>
> 2015-06-07 17:50:35,631 [master.Master] INFO : Setting master lock data to
> 127.0.0.1:
>
>
>
> I found ACCUMULO-4513, but it doesn’t seem relevant as I didn’t try to stop.
>
>
>
> Any ideas as to what is going on?
>
>
>
> HDFS seems fine based on my limited tests with openjdk 1.8.  I did find some
> old posts about Accumulo issues with IBM JDK.  Should I expect Accumulo to
> work with openjdk?
>
>
>
> Thank you,
> Jayesh
>
>

openjdk, Accumulo master state doesn't change from HAVE_LOCK to NORMAL

[Jayesh Patel]

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 difference.

 

Here's what I get in the logs for the master:

2016-12-01 17:01:07,970 [trace.DistributedTrace] INFO : SpanReceiver
org.apache.accumulo.tracer.ZooTraceCli

ent was loaded successfully.

2016-12-01 17:01:07,971 [master.Master] INFO : trying to get master lock

2016-12-01 17:01:07,987 [master.EventCoordinator] INFO : State changed from
INITIAL to HAVE_LOCK

2016-12-01 17:01:08,038 [master.Master] INFO : New servers:
[instance-accumulo:9997[258ac79197e000d]]

 

On the successful install it transitions right away to NORMAL and goes on
the listen on port :

2015-06-07 17:50:35,393 [master.Master] INFO : trying to get master lock

2015-06-07 17:50:35,408 [master.EventCoordinator] INFO : State changed from
INITIAL to HAVE_LOCK

2015-06-07 17:50:35,432 [master.EventCoordinator] INFO : State changed from
HAVE_LOCK to NORMAL

2015-06-07 17:50:35,524 [balancer.TableLoadBalancer] INFO : Loaded class
org.apache.accumulo.server.master.balancer.DefaultLoadBalancer for table !0

2015-06-07 17:50:35,631 [master.Master] INFO : Setting master lock data to
127.0.0.1:

 

I found ACCUMULO-4513 
, but it doesn't seem relevant as I didn't try to stop.  

 

Any ideas as to what is going on?

 

HDFS seems fine based on my limited tests with openjdk 1.8.  I did find some
old posts about Accumulo issues with IBM JDK.  Should I expect Accumulo to
work with openjdk?

 

Thank you,
Jayesh

 



smime.p7s
Description: S/MIME cryptographic signature

Re: BatchScanner behavior with AccumuloRowInputFormat

[Christopher]

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
wouldn't use that option. If you have to use it because of performance
issues, then you can mitigate the row-splitting problem using the
WholeRowIterator, but that will come with its own performance implications.
You might also be able to mitigate by resolving the
single-row-represented-as-multiple-rows problem with a Combiner or in your
Reducer.

On Thu, Dec 1, 2016 at 1:51 AM Massimilian Mattetti 
wrote:

> I see, so the only solution here would be either to use a WholeRowIterator
> or to avoid enabling the BatchScanner. Since each executor will work on a
> single tablet I guess that the benefit of using a BatchScanner is that it
> can fetch multiple ranges over the same tablet in parallel, am I correct?
> Thanks,
> Max
>
>
>
>
> From:Christopher 
> To:user@accumulo.apache.org
> Date:30/11/2016 18:48
> Subject:Re: BatchScanner behavior with AccumuloRowInputFormat
> --
>
>
>
> You'd only have to worry about this behavior if you set
> RowInputFormat.setBatchScan(job, true), available since 1.7.0.
> By default, our InputFormats use a regular Accumulo Scanner.
>
> See *https://issues.apache.org/jira/browse/ACCUMULO-3602*
>  and
> *https://static.javadoc.io/org.apache.accumulo/accumulo-core/1.7.0/org/apache/accumulo/core/client/mapreduce/InputFormatBase.html#setBatchScan(org.apache.hadoop.mapreduce.Job,%20boolean)*
> 
>
>
> On Wed, Nov 30, 2016 at 9:42 AM Massimilian Mattetti <
> *massi...@il.ibm.com* > wrote:
> Hi all,
>
> as you already know, the AccumuloRowInputFormat is internally using a
> RowIterator for iterating over all the key value pairs of a single row. In
> the past when I was using the RowIterator together with a BatchScanner I
> had the problem of a single row be split into multiple rows due to the fact
> that a BatchScanner can interleave key-value pairs of different rows.
> Should I expect the same behavior when using the AccumuloRowInputFormat
> with a BatchScanner (enabled via setBatchScan)?
> Thanks,
> Max
>
>
>
>

Re: Accumulo Tip: Batch your Mutations

[Keith Turner]

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.

On Wed, Nov 30, 2016 at 11:47 PM, Dylan Hutchison
 wrote:
> Hi folks,
>
> I'd like to share a tip that ~doubled BatchWriter ingest performance in my
> application.
>
> When inserting multiple entries to the same Accumulo row, put them into the
> same Mutation object.  Add that one large Mutation to a BatchWriter rather
> than an individual Mutation for each entry. The result reduces the amount of
> data transferred.
>
> The tip seems obvious enough, but hey, I used Accumulo for a couple years
> without realizing it, so I thought y'all might benefit too.
>
> Enjoy!
> Dylan