accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-841) Randomwalk State should be refactored into multiple classes
Date Mon, 24 Feb 2014 16:03:19 GMT


ASF subversion and git services commented on ACCUMULO-841:

Commit a74f392ea834923b47bf338bbcd8d6484bd02e6f in accumulo's branch refs/heads/master from
[;h=a74f392 ]

ACCUMULO-841 Refactor randomwalk State class

* Create new Environment object, separate from State, for config props and client objects
* Update most randomwalk test nodes and framework to use Environment
* Eliminate State visit counting, which is unused and redundant with Module's maxHops
* Move getMapReduceJars() method to Node
* Move getPid() method out of State
* Eliminate getCredentials() which ends up not useful
* Reduce visibility to several methods in State and Environment

> Randomwalk State should be refactored into multiple classes
> -----------------------------------------------------------
>                 Key: ACCUMULO-841
>                 URL:
>             Project: Accumulo
>          Issue Type: Test
>          Components: test
>            Reporter: John Vines
>            Assignee: Bill Havanki
> So, I'm working on the Security randomwalk test with ACCUMULO-259 and I stumbled across
some strange behavior.
> State seems to be a fancy, but locked down, tuple. It contains a Map, Properties, and
a few other Accumulo related state items. And it has methods for accessing these, which are
a bit more defined. These are necessary because all of the internals are private. 
> The Map specifically has a peculiar point where it will throw a RuntimeException when
getting a non-existant key. At first I found myself wondering how badly would things break
if I changed that behavior. But after talking to Adam, this lead to a larger question of why
does a testing framework have a tuple with locked down internal classes?
> From Eric- We should separate these responsibilities into their own classes. The visit
count should be hoisted into the walking mechanism, the properties into a configuration class
accessible by State, and the named object store into another class, perhaps just exposed as
a Map<String, Object>.

This message was sent by Atlassian JIRA

View raw message