[jira] [Commented] (ACCUMULO-841) Randomwalk State should be refactored into multiple classes

["Bill Havanki (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/ACCUMULO-841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894754#comment-13894754 ] 

Bill Havanki commented on ACCUMULO-841:
---------------------------------------

The node visit counting in randomwalk is not used by anything: nothing sets the maximum, which defaults to {{Integer.MAX_VALUE}}. Meanwhile, the randomwalk {{Module}} class supports a maximum hop count, with the same default. Therefore, the visit counting is redundant and I'm going to eliminate it as part of this refactoring.

> 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)