accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Vines (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (ACCUMULO-841) Randomwalk State should be refactored into multiple classes
Date Mon, 05 Nov 2012 17:56:15 GMT

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

John Vines edited comment on ACCUMULO-841 at 11/5/12 5:55 PM:
--------------------------------------------------------------

I agree. I have done some more extensions to it to do what I need to get the security randomwalk
running well, but it definitely did end up expanding the amount of cruft in it.
                
      was (Author: vines):
    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

Mime
View raw message