[
https://issues.apache.org/jira/browse/ACCUMULO-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Havanki resolved ACCUMULO-841.
-----------------------------------
Resolution: Fixed
> Randomwalk State should be refactored into multiple classes
> -----------------------------------------------------------
>
> Key: ACCUMULO-841
> URL: https://issues.apache.org/jira/browse/ACCUMULO-841
> 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
(v6.1.5#6160)
