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. >
