You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@accumulo.apache.org by "John Vines (JIRA)" <ji...@apache.org> on 2012/10/31 19:08:14 UTC
[jira] [Created] (ACCUMULO-841) Randomwalk State is a strange tuple
John Vines created ACCUMULO-841:
-----------------------------------
Summary: Randomwalk State is a strange tuple
Key: ACCUMULO-841
URL: https://issues.apache.org/jira/browse/ACCUMULO-841
Project: Accumulo
Issue Type: Bug
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: http://www.atlassian.com/software/jira
[jira] [Updated] (ACCUMULO-841) Randomwalk State is a strange tuple
Posted by "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:
--------------------------------
Issue Type: Test (was: Bug)
> Randomwalk State is a strange tuple
> -----------------------------------
>
> 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.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: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (ACCUMULO-841) Randomwalk State should be
refactored into multiple classes
Posted by "John Vines (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Updated] (ACCUMULO-841) Randomwalk State should be
refactored into multiple classes
Posted by "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
[jira] [Commented] (ACCUMULO-841) Randomwalk State is a strange
tuple
Posted by "Eric Newton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ACCUMULO-841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490692#comment-13490692 ]
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: https://issues.apache.org/jira/browse/ACCUMULO-841
> 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: http://www.atlassian.com/software/jira