[jira] [Updated] (HBASE-10175) 2-thread ChaosMonkey steps on its own toes
[ https://issues.apache.org/jira/browse/HBASE-10175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-10175: --- Fix Version/s: 0.98.0 Committed test improvement to 0.98 branch also. 2-thread ChaosMonkey steps on its own toes -- Key: HBASE-10175 URL: https://issues.apache.org/jira/browse/HBASE-10175 Project: HBase Issue Type: Improvement Components: test Reporter: Sergey Shelukhin Assignee: Sergey Shelukhin Priority: Minor Fix For: 0.98.0, 0.99.0 Attachments: HBASE-10175.patch ChaosMonkey with one destructive and one volatility (flush-compact-split-etc.) threads steps on its own toes and logs a lot of exceptions. A simple solution would be to catch most (or all), like NotServingRegionException, and log less (not a full callstack for example, it's not very useful anyway). A more complicated/complementary one would be to keep track which regions the destructive thread affects and use other regions for volatile one. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10175) 2-thread ChaosMonkey steps on its own toes
[ https://issues.apache.org/jira/browse/HBASE-10175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-10175: - Resolution: Fixed Fix Version/s: 0.99.0 Status: Resolved (was: Patch Available) committed to trunk 2-thread ChaosMonkey steps on its own toes -- Key: HBASE-10175 URL: https://issues.apache.org/jira/browse/HBASE-10175 Project: HBase Issue Type: Improvement Components: test Reporter: Sergey Shelukhin Assignee: Sergey Shelukhin Priority: Minor Fix For: 0.99.0 Attachments: HBASE-10175.patch ChaosMonkey with one destructive and one volatility (flush-compact-split-etc.) threads steps on its own toes and logs a lot of exceptions. A simple solution would be to catch most (or all), like NotServingRegionException, and log less (not a full callstack for example, it's not very useful anyway). A more complicated/complementary one would be to keep track which regions the destructive thread affects and use other regions for volatile one. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10175) 2-thread ChaosMonkey steps on its own toes
[ https://issues.apache.org/jira/browse/HBASE-10175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-10175: - Status: Patch Available (was: Open) 2-thread ChaosMonkey steps on its own toes -- Key: HBASE-10175 URL: https://issues.apache.org/jira/browse/HBASE-10175 Project: HBase Issue Type: Improvement Components: test Reporter: Sergey Shelukhin Assignee: Sergey Shelukhin Priority: Minor Attachments: HBASE-10175.patch ChaosMonkey with one destructive and one volatility (flush-compact-split-etc.) threads steps on its own toes and logs a lot of exceptions. A simple solution would be to catch most (or all), like NotServingRegionException, and log less (not a full callstack for example, it's not very useful anyway). A more complicated/complementary one would be to keep track which regions the destructive thread affects and use other regions for volatile one. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (HBASE-10175) 2-thread ChaosMonkey steps on its own toes
[ https://issues.apache.org/jira/browse/HBASE-10175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-10175: - Attachment: HBASE-10175.patch The first option; simple patch. ChaosMonkey is now so abstract that I wouldn't venture to spend the time needed to make the actions talk to each other... ;) 2-thread ChaosMonkey steps on its own toes -- Key: HBASE-10175 URL: https://issues.apache.org/jira/browse/HBASE-10175 Project: HBase Issue Type: Improvement Components: test Reporter: Sergey Shelukhin Assignee: Sergey Shelukhin Priority: Minor Attachments: HBASE-10175.patch ChaosMonkey with one destructive and one volatility (flush-compact-split-etc.) threads steps on its own toes and logs a lot of exceptions. A simple solution would be to catch most (or all), like NotServingRegionException, and log less (not a full callstack for example, it's not very useful anyway). A more complicated/complementary one would be to keep track which regions the destructive thread affects and use other regions for volatile one. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
