accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Corey Nolet <cjno...@gmail.com>
Subject Re: [VOTE] Apache Accumulo 1.6.1 RC1
Date Thu, 25 Sep 2014 14:50:45 GMT
I'm seeing the behavior under Max OS X and Fedora 19 and they have been
consistently failing for me. I'm thinking ACCUMULO-3073. Since others are
able to get it to pass, I did not think it should fail the vote solely on
that but I do think it needs attention, quickly.

On Thu, Sep 25, 2014 at 10:43 AM, Bill Havanki <bhavanki@clouderagovt.com>
wrote:

> I haven't had an opportunity to try it again since my +1, but prior to that
> it has been consistently failing.
>
> - I tried extending the timeout on the test, but it would still time out.
> - I see the behavior on Mac OS X and under CentOS. (I wonder if it's a JVM
> thing?)
>
> On Wed, Sep 24, 2014 at 9:06 PM, Corey Nolet <cjnolet@gmail.com> wrote:
>
> > Vote passes with 4 +1's and no -1's.
> >
> > Bill, were you able to get the IT to run yet? I'm still having timeouts
> on
> > my end as well.
> >
> >
> > On Wed, Sep 24, 2014 at 1:41 PM, Josh Elser <josh.elser@gmail.com>
> wrote:
> >
> > > The crux of it is that both of the errors in the CRC where single bit
> > > "variants".
> > >
> > > y instead of 9 and p instead of 0
> > >
> > > Both of these cases are a '1' in the most significant bit of the byte
> > > instead of a '0'. We recognized these because y and p are outside of
> the
> > > hex range. Fixing both of these fixes the CRC error (manually
> verified).
> > >
> > > That's all we know right now. I'm currently running memtest86. I do not
> > > have ECC ram, so it *is* theoretically possible that was the cause.
> After
> > > running memtest for a day or so (or until I need my desktop functional
> > > again), I'll go back and see if I can reproduce this again.
> > >
> > >
> > > Mike Drob wrote:
> > >
> > >> Any chance the IRC chats can make it only the ML for posterity?
> > >>
> > >> Mike
> > >>
> > >> On Wed, Sep 24, 2014 at 12:04 PM, Keith Turner<keith@deenlo.com>
> > wrote:
> > >>
> > >>  On Wed, Sep 24, 2014 at 12:44 PM, Russ Weeks<
> rweeks@newbrightidea.com>
> > >>> wrote:
> > >>>
> > >>>  Interesting that "y" (0x79) and "9" (0x39) are one bit "away" from
> > each
> > >>>> other. I blame cosmic rays!
> > >>>>
> > >>>>  It is interesting, and thats only half of the story.  Its been
> > >>> interesting
> > >>> chatting w/ Josh about this on irc and hearing about his findings.
> > >>>
> > >>>
> > >>>  On Wed, Sep 24, 2014 at 9:05 AM, Josh Elser<josh.elser@gmail.com>
> > >>>>
> > >>> wrote:
> > >>>
> > >>>> The offending keys are:
> > >>>>>>>
> > >>>>>>> 389a85668b6ebf8e 2ff6:4a78 [] 1411499115242
> > >>>>>>>
> > >>>>>>> 3a10885b-d481-4d00-be00-0477e231ey65:000000008576b169:
> > >>>>>>> 0cd98965c9ccc1d0:ba15529e
> > >>>>>>>
> > >>>>>>>  The careful eye will notice that the UUID in the first
component
> > of
> > >>>>> the
> > >>>>> value has a different suffix than the next corrupt key/value
(ends
> > with
> > >>>>> "ey65" instead of "e965"). Fixing this in the Value and re-running
> > the
> > >>>>>
> > >>>> CRC
> > >>>>
> > >>>>> makes it pass.
> > >>>>>
> > >>>>>
> > >>>>>   and
> > >>>>>
> > >>>>>> 7e56b58a0c7df128 5fa0:6249 [] 1411499311578
> > >>>>>>>
> > >>>>>>> 3a10885b-d481-4d00-be00-0477e231e965:0000p000872d60eb:
> > >>>>>>> 499fa72752d82a7c:5c5f19e8
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>
> >
>
>
>
> --
> // Bill Havanki
> // Solutions Architect, Cloudera Govt Solutions
> // 443.686.9283
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message