I was running some similar tests and came across a surprising finding. I
compared reads and write on ConcurrentSkipListMap ( which the memstore uses)
and synchronized TreeMap ( Which was literally treemap synchronized).
Executed concurrent reads, writes and deletes on both of them.
Surprisingly
Values corrected. there was a mistake in the number of records
And here are the details about the test run.
100 Threads each fetching 10,000 records
100 threads each adding 10,000 records.
100 threads each deletin 10,000 records
( Reads, Writes and deletes simultaneously )
Cheers,
Akash
Worked like a charm. Thanks! ;)
Best regards,
Matthew Tovbin =)
On Tue, Oct 18, 2011 at 19:30, Jean-Daniel Cryans jdcry...@apache.orgwrote:
(putting dev@ in bcc, please don't cross-post)
You need to pre-split that table, see
http://hbase.apache.org/book.html#precreate.regions
J-D
Maybe get rid of TestHCM.getValidKeyCount in favor of
TestHCM.getHConnectionManagerCacheSize then.
Bright
On Sun, Oct 23, 2011 at 6:34 AM, Ted Yu yuzhih...@gmail.com wrote:
Hi,
ConcurrentModificationException might be thrown in
TestHCM.testConnectionUniqueness.
See
Very nice experiment, Akash. Keep getting your hands dirty and digging! :)
I think your results might change if you bump the test up to 1000 threads or
so. 100 threads can still perform okay when there's a global lock but the
contention at 1000 threads will kill you and that's when CSLM
I open a file and verify it.
My local test case always fails.
---
Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 22.873 sec
FAILURE!
testConnectionUniqueness(org.apache.hadoop.hbase.client.TestHCM)
