accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Newton (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-841) Randomwalk State is a strange tuple
Date Mon, 05 Nov 2012 15:50:12 GMT


Eric Newton commented on ACCUMULO-841:

State has turned into a dumping ground for "Stuff a node might need during it's execution."
 It's not a very big class, but perhaps it is time to refactor it.

Presently, it tracks visits, stores user-specified properties (from the configuration), and
allows the user to set/get arbitrary objects which allows the nodes to communicate resources
and expectations, like counts.  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>}}.
> Randomwalk State is a strange tuple
> -----------------------------------
>                 Key: ACCUMULO-841
>                 URL:
>             Project: Accumulo
>          Issue Type: Test
>          Components: test
>            Reporter: John Vines
>            Assignee: John Vines
>             Fix For: 1.5.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?
> 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.

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:

View raw message