getValidKeyCount() is only used in an assertion in createNewConfigurations() which is called by a disabled test, testManyNewConnectionsDoesnotOOME().
Looks like we can remove getValidKeyCount() and its references. On Sun, Oct 23, 2011 at 12:04 PM, Bright Fulton <[email protected]>wrote: > Maybe get rid of TestHCM.getValidKeyCount in favor of > TestHCM.getHConnectionManagerCacheSize then. > > Bright > > > On Sun, Oct 23, 2011 at 6:34 AM, Ted Yu <[email protected]> wrote: > >> Hi, >> ConcurrentModificationException might be thrown in >> TestHCM.testConnectionUniqueness. >> See >> https://builds.apache.org/view/G-L/view/HBase/job/HBase-TRUNK/2357/testReport/junit/org.apache.hadoop.hbase.client/TestHCM/testConnectionUniqueness >> >> 363 Entry<K,V> nextEntry() { >> 364 if (modCount != expectedModCount) >> 365 throw new >> ConcurrentModificationException<http://kickjava.com/src/java/util/ConcurrentModificationException.java.htm> >> [image: >> JavaDoc] <http://kickjava.com/2487.htm>(); >> >> Read more: >> http://kickjava.com/src/java/util/LinkedHashMap.java.htm#ixzz1bbCC0gaT >> >> HCM uses proper synchronization when accessing HBASE_INSTANCES. >> >> Looking at TestHCM.getValidKeyCount(), it puts values of HBASE_INSTANCES >> in a Set and returns the size of the Set. >> >> However, post HBASE-3777, the values (HConnectionImplementation's) in >> HBASE_INSTANCES would be unique. >> >> I simplified TestHCM.getValidKeyCount() by returning cache.size() directly >> where ConcurrentModificationException isn't thrown. >> The test passed. >> >> Please comment on proposed simplification. >> > >
