Let's see if adding more network processing threads helps...
Back to at most three network processing threads... Not sure why this casues JProfiler to freak out...
Added a simple limit in HStoreSite.processPeriodicWork() that prevents it from hogging the perioidic work thread CPU forever. The HStoreThreadManager will now attempt to register its own periodic work thread with itself now
Simple typo fix
Simple fix to allow us to start the HStoreSiteStatus before completely initializing all of the PartitionExecutors for the HStoreSite
Broke out the code that cleans up txn handles into a separate thread. Hopefully this will be able to keep up with more partitions per site.
Hackishly add two TransactionCleaner threads. Hopefully this will be enough to rip through our txns as they finish
Added a new CLEANER ThreadGroup. Going to eat lunch now and then track down why the cleaner threads are so slow...
Added swappable queues to allow us to hold on to txnIds for a bit until we restart
We'll make one TransactionCleaner per local partition for now... We really should see about speeding them up though...
Hackishly assign multiple cores for the TransactionCleaner threads
Moved stuff into HStoreThreadManager.Debug. Dump out the CPU->Thread map every time that we register a new thread
Trim the HStoreThreadManager.debug() rows
Minor refactoring in the HStoreThreadManager
Just make the registration methods in HStoreThreadManager synchronized
The HStoreThreadManager can now get the base name of a Thread when registering it. This allows us to easily pin multiple TransactionCleaner threads. This is untested, but that's the way you like it baby...
Make sure we increase the offset for the TransactionCleaner thread names
Use a TreeMap for sorting the CPU Ids. The only reason I have to commit this is get past the MIT firewall...
Simple fix for compilation mistake
Typo mistake for checking the swappable queues in TransactionCleaner