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

["John Vines (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/ACCUMULO-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

John Vines updated ACCUMULO-841:
--------------------------------

      Description: 
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>.

  was:
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?

My knowledge on the background of the Randomwalk framework isn't the best, so I'm wondering if I'm overlooking something or if the framework itself is too conservative. At the bare minimum, I believe something needs to be changed with the get functionality. Though there is reasonable suspicion to believe there is a larger change that needs to happen here.

    Fix Version/s:     (was: 1.5.0)
                   1.6.0
          Summary: Randomwalk State should be refactored into multiple classes  (was: Randomwalk State is a strange tuple)

I agree
                
> 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: John Vines
>             Fix For: 1.6.0
>
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira