[5/5] kudu git commit: KUDU-2393. Fix flaky DebugUtilTest.TestSnapshot

KUDU-2393. Fix flaky DebugUtilTest.TestSnapshot This test was flaky with two different failure modes which I believe have the same root cause: when the test starts, it's possible that there is still some thread from a prior test case in the process of shutting down. Even though we join() on our

[3/5] kudu git commit: KUDU-1977. Avoid extra reference counting for fast-path MetaCache lookups

KUDU-1977. Avoid extra reference counting for fast-path MetaCache lookups This does a bit of refactoring of MetaCache so that fast-path lookups can occur without allocating a LookupRpc object. This avoids an allocation/deallocation pair as well as reference counting overhead on various objects.

[4/5] kudu git commit: KUDU-2388. Fix TSAN race in MaintenanceManager::UnregisterOp

KUDU-2388. Fix TSAN race in MaintenanceManager::UnregisterOp This fixes the following TSAN race: WARNING: ThreadSanitizer: data race (pid=17822) Read of size 1 at 0x7b4c54e8 by thread T59 (mutexes: write M1750): ... #3

[2/5] kudu git commit: rpc-test: fix multi-threaded test from running too long

rpc-test: fix multi-threaded test from running too long In TSAN builds this test was taking several minutes. This makes the test run based on a timer rather than an explicit count. Change-Id: I827a07d5b1d2463cb845ef6b04ec36036b2ddfbb Reviewed-on: http://gerrit.cloudera.org:8080/9856 Reviewed-by:

[1/5] kudu git commit: util: use uint64_t values for resource limits and adjust usages

Repository: kudu Updated Branches: refs/heads/master 61d3fff2f -> 3634672e8 util: use uint64_t values for resource limits and adjust usages Turns out rlim_t is an unsigned 64-bit type, and although a root shell on my laptop won't let me set RLIMIT_NOFILE particularly high, I can set

[2/3] kudu git commit: KUDU-2361. Fix flaky MasterTest.TestDumpStacksOnRpcQueueOverflow

KUDU-2361. Fix flaky MasterTest.TestDumpStacksOnRpcQueueOverflow This test was flaky in TSAN builds for two reasons: (1) even though taking the stack trace is always pretty fast, symbolization can sometimes take more than a second. If that was the case, the assertion that looked at the

kudu git commit: docs: add troubleshooting info on detecting ext2 and ext3 filesystems

Repository: kudu Updated Branches: refs/heads/master 4ebfbe418 -> ba955733d docs: add troubleshooting info on detecting ext2 and ext3 filesystems Change-Id: Ic4917e144690943e43bf5aa380b59379669846d9 Reviewed-on: http://gerrit.cloudera.org:8080/9871 Reviewed-by: Todd Lipcon

[1/3] kudu git commit: thirdparty: add patch to fix printing large span stats in /memz

Repository: kudu Updated Branches: refs/heads/master 3634672e8 -> 4ebfbe418 thirdparty: add patch to fix printing large span stats in /memz This fixes a bug that I introduced upstream in gperftools by importing the upstream patch that fixed it. The issue was mismatched arguments to printf()

[3/3] kudu git commit: meta_cache: improve multi-threaded scalability

meta_cache: improve multi-threaded scalability When profiling a multi-threaded 'kudu perf loadgen' I found the bottleneck was on the rw_spinlock acquisition in MetaCache::LookupTabletByKeyFastPath as well as some contention in RemoteTablet::stale(). This fixes the first by switching to a