accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-3974) Modify Randomwalk Bulk module to catch ACCUMULO-3967
Date Tue, 25 Aug 2015 20:01:45 GMT


Josh Elser commented on ACCUMULO-3974:

bq. it shouldn't hold up releasing at all

Yeah, that's why I didn't mark it as blocker as I had initially considered.

bq. so long as the things we're releasing for are themselves tested

That's the hard part of it. I couldn't come up with a reliable IT that caught the failure
(since it requires failure itself to reproduce the bug). I know we really pride ourselves
on the correctness (among other things), so I figured I'd double check. A strong response
via improving tests is the best we can really do to put the emphasis that this is important
to us.

Thanks for taking the time to reply.

> Modify Randomwalk Bulk module to catch ACCUMULO-3967
> ----------------------------------------------------
>                 Key: ACCUMULO-3974
>                 URL:
>             Project: Accumulo
>          Issue Type: Bug
>          Components: test
>            Reporter: Josh Elser
>            Priority: Critical
>             Fix For: 1.6.4, 1.7.1, 1.8.0
> [~ecn] asked me after I committed a fix for ACCUMULO-3967 "why didn't randomwalk catch
this bug?"
> I think we could potentially have caught this if in Setup we pre-split the table to be
a large collection of sequentially increasing tablets. It's not a guarantee catch (since the
bug itself was only shown in the case of import failures and the tablet distribution hasn't
> Alternatively, we could copy the existing bulk module into a new module. In this module,
we remove the splitting and merging, instead keeping a static split distribution. This would
be almost guaranteed to eventually recreate the scenario. Adding in a chaotic balancer, even
more likely to reproduce.

This message was sent by Atlassian JIRA

View raw message