[
https://issues.apache.org/jira/browse/HBASE-4877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-4877:
-------------------------
Attachment: 4877.txt
Patch to set down the number of connections we create when testing for
uniqueness. Also has testConnectionUniqueness clean up after itself.
We are losing testing what happens when we create connections in excess of
maximum to cache but this was broke anyways and the maximum to cache is in
excess of zk connections max so "...we should run into zk issues before the LRU
hit this value of 31" -- as we do on ubuntu (Quote is from head of
HConnectionManager setting up the MAX_CACHED_HBASE_INSTANCES static.
> TestHCM failing sporadically on jenkins and always for me on an ubuntu machine
> ------------------------------------------------------------------------------
>
> Key: HBASE-4877
> URL: https://issues.apache.org/jira/browse/HBASE-4877
> Project: HBase
> Issue Type: Bug
> Reporter: stack
> Fix For: 0.92.0
>
> Attachments: 4877.txt
>
>
> TestHCM takes 13 minutes for me on ubuntu and fails in testClosing. It runs
> fine on a mac. The problem test is not testClosing as I thought originally,
> its the test just previous, testConnectionUniqueness.
> testConnectionUniqueness creates the maximum cached HConnections + 10 to
> verify each is unique if the passed in Configuration has a unique hash.
> Problem comes when zk enforces its default max from single host of 30
> connections which is < (max cached + 10). The max does not seem to be
> enforced on mac for me. The max connections runs up to max of 31 -- zk max +
> 1 -- and works fine until we do the +10. On ubuntu, when we hit the zk max
> of 30, we'll then go into a fail mode where we cannot set up a zk session...
> each attempt takes a while. Test passes, it just takes a while.
> Only, the uniqueness test does not clean up after itself and so all sessions
> to zk are outstanding so then when the subsequent testClosing runs, it can't
> set up connections successfully so fails.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
