I concur that until we determine if there is data loss we should hold off on
this release. Changing vote to -1 as well.
-Original Message-
From: Christopher
Sent: Sunday, August 30, 2020 11:01 PM
To: accumulo-dev
Subject: Re: [VOTE] Apache Accumulo 1.10.0-rc2
I'm changing my vote to
-1
I tested a 10 node cluster (8 workers) with continuous ingest both with and
without agitation and also random walk without agitation, each for 24 hour
periods.
I ran into the same issues mentioned above which is the reasoning behind
the vote. I don't have any additional information to add but
I started investigating this today. I quickly noticed two things.
First when I scanned the table for some of the data reported as
missing by the MR job it was there. Second the range of the supposed
missing data covered the entire table. Then I realized we never
stopped ingest, so during verific
Okay, thanks for the update. I was just about to call the vote on
Mike's behalf (because the vote is currently tied, and can't pass
as-is and this issue needed to be checked first). Mike is unavailable
today due to personal matters, so would be unlikely to call the vote
himself. However, based on t
I don't recall remembering to turn off ingest before running verification.
This is my first time running the tests with these scripts as before I was
using accumulo-testing to handle most of this. So that is definitely my
fault on failing to make sure to do that because I was aware I needed too.
On
I wouldn't personally consider #1695 a blocker. The fix for that can
make it into 1.10.1 if the re-testing of continuous ingest goes well.
On Mon, Aug 31, 2020 at 12:46 PM Jeffrey Manno wrote:
>
> I don't recall remembering to turn off ingest before running verification.
> This is my first time r
On Mon, Aug 31, 2020 at 1:21 PM Christopher wrote:
>
> I wouldn't personally consider #1695 a blocker. The fix for that can
> make it into 1.10.1 if the re-testing of continuous ingest goes well.
If we are only seeing problems w/ the test, then I would not consider
those blockers either. I looke
I wouldn’t necessarily consider it a problem, but I thought I’d mention that
while testing I ran into an IlegalAccessException in the shell if
./hadoop/common/lib/* is added to the classpath because the commons-* versions
are ahead of the Hadoop releases now (incl. both 2.10.x and 3.2.x) [1, 2].
Joey, was the IllegalAccessException a warning, or did it cause a failure?
Also, what version of Java were you using? Some newer versions of Java
report some IllegalAccess issues when some older code tries to access
unsafe internal areas of the JVM, and there's little we can do about
that, except t
Thanks for the reply. I opened #1696.
I first saw this on the candidate source build, but AFAICT it applies to the
convenience binary posted too, Java 8 and 11 runtimes, and different ways of
deploying.
-joey
On Aug 31, 2020, 12:05 PM -0700, Christopher , wrote:
> Joey, was the IllegalAccessExc
Thanks. I'll follow up on that issue.
On Mon, Aug 31, 2020 at 6:18 PM Joey Frazee
wrote:
>
> Thanks for the reply. I opened #1696.
>
> I first saw this on the candidate source build, but AFAICT it applies to the
> convenience binary posted too, Java 8 and 11 runtimes, and different ways of
> de
11 matches
Mail list logo
