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] [Updated] (ACCUMULO-841) Randomwalk State should be refactored into multiple classes
Date Mon, 05 Nov 2012 17:56:13 GMT

     [ 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

Mime
View raw message