[
https://issues.apache.org/jira/browse/HBASE-7856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13579319#comment-13579319
]
nkeywal commented on HBASE-7856:
--------------------------------
We more or less have one, but we're humble on this: if you run the tests with
'mvn test', you have 2 processes with 2 Gb of RAM for each.
I run the tests with 14 processes in parallel. That's a good load test :-), and
that's why I had these errors I think. And often the waitAvailable was called
with a 30s delay, I think it's better to have the same value everywhere.
I don't understand why the jenkins trunk always fails while the jenkins
precommit seems now ok. I checked the errors I have locally and the ones on
jenkins trunk, they're different most of the time. So it's likely something
else, but I don't know what. On precommit, for a few months we've been
checking/killing that there are no remains from previous builds. I expect it
works the same on trunk but may be it's different?
Lastly, I changed some "tableAvailable" to "tableEnabled" in a few cases. I'm
uploading the patch.
> HTU#waitTableAvailable should have a default value of 30s
> ---------------------------------------------------------
>
> Key: HBASE-7856
> URL: https://issues.apache.org/jira/browse/HBASE-7856
> Project: HBase
> Issue Type: Improvement
> Components: test
> Reporter: nkeywal
> Assignee: nkeywal
> Priority: Minor
>
> It's often used with 5s delay. It's not enough in my env as I parallelize
> heavily the tests. 30s default seems to make it.
--
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
