[1/2] kudu git commit: [docs] 'xcode-select' and 'xcodebuild -license' steps on OS X

Repository: kudu Updated Branches: refs/heads/branch-1.7.x 00128aea1 -> 29d86fc83 [docs] 'xcode-select' and 'xcodebuild -license' steps on OS X Added a note on accepting the Xcode license and setup command-line tools after installing Xcode. It seems we implicitly assumed those steps were run

[2/2] kudu git commit: KUDU-2343. java: properly reconnect to new leader master after failover

KUDU-2343. java: properly reconnect to new leader master after failover This fixes the "fake" location information returned in response to a ConnectToMaster RPC to include a distinct "fake UUID" for each master. Previously, we were using an empty string for the UUID of the masters. This caused col

[2/3] kudu git commit: KUDU-2153. Servers should not delete tmp files until after locking directories

KUDU-2153. Servers should not delete tmp files until after locking directories This changes the order of FsManager startup to not try to clean tmp files until after successfully locking the data directories. This prevents potential issues such as: - a tserver is already running on some host, and

[1/3] kudu git commit: [docs] 'xcode-select' and 'xcodebuild -license' steps on OS X

Repository: kudu Updated Branches: refs/heads/master 217715aae -> 4c2bb92f1 [docs] 'xcode-select' and 'xcodebuild -license' steps on OS X Added a note on accepting the Xcode license and setup command-line tools after installing Xcode. It seems we implicitly assumed those steps were run as a p

[3/3] kudu git commit: KUDU-2343. java: properly reconnect to new leader master after failover

KUDU-2343. java: properly reconnect to new leader master after failover This fixes the "fake" location information returned in response to a ConnectToMaster RPC to include a distinct "fake UUID" for each master. Previously, we were using an empty string for the UUID of the masters. This caused col

kudu git commit: [release notes]: RYW read mode

Repository: kudu Updated Branches: refs/heads/branch-1.7.x 542cfd9e0 -> 00128aea1 [release notes]: RYW read mode Change-Id: I9906398b0796307c26150f78e0e256e285ded516 Reviewed-on: http://gerrit.cloudera.org:8080/9594 Reviewed-by: Dan Burkert Reviewed-by: Grant Henke Reviewed-by: David Ribeiro

kudu git commit: [release notes]: RYW read mode

Repository: kudu Updated Branches: refs/heads/master ce0db9157 -> 217715aae [release notes]: RYW read mode Change-Id: I9906398b0796307c26150f78e0e256e285ded516 Reviewed-on: http://gerrit.cloudera.org:8080/9594 Reviewed-by: Dan Burkert Reviewed-by: Grant Henke Reviewed-by: David Ribeiro Alves

[1/4] kudu git commit: [tools] KUDU-2331: Allow move tool to work when uninvolved tserver is down

Repository: kudu Updated Branches: refs/heads/branch-1.7.x de57e3c92 -> 542cfd9e0 [tools] KUDU-2331: Allow move tool to work when uninvolved tserver is down The move tool requires a clean ksck for the tablet it's acting on for safety reasons, but the check for this failed if a tablet server wa

[2/4] kudu git commit: Remove tcmalloc_spinlock_contention metric

Remove tcmalloc_spinlock_contention metric Spinlock contention was removed from tcmalloc upstream, so this metric has been set to 0 since we upgraded to tcmalloc 2.6. I looked briefly at reverting its removal upstream, but the revert would be fairly large, so I think it's best to just accept the l

[4/4] kudu git commit: KUDU-2230: java: sync client exception stack traces should make sense

KUDU-2230: java: sync client exception stack traces should make sense Previously the exceptions thrown by the synchronous client always had a stack trace somewhere deep inside our async callback chain. So, when the user eventually caught this exception, it would be very hard to even know what part

[3/4] kudu git commit: KUDU-2322: don't spew logs about behind-log-GC follower

KUDU-2322: don't spew logs about behind-log-GC follower This patch addresses the issue of a leader spewing a lot of INFO log messages about missing logs segments for a follower that falls behind log GC. In the 3-4-3 replica management scheme, such followers linger around until corresponding non-v

[3/4] kudu git commit: KUDU-2322: don't spew logs about behind-log-GC follower

KUDU-2322: don't spew logs about behind-log-GC follower This patch addresses the issue of a leader spewing a lot of INFO log messages about missing logs segments for a follower that falls behind log GC. In the 3-4-3 replica management scheme, such followers linger around until corresponding non-v

[4/4] kudu git commit: KUDU-2230: java: sync client exception stack traces should make sense

KUDU-2230: java: sync client exception stack traces should make sense Previously the exceptions thrown by the synchronous client always had a stack trace somewhere deep inside our async callback chain. So, when the user eventually caught this exception, it would be very hard to even know what part

[1/4] kudu git commit: [tools] KUDU-2331: Allow move tool to work when uninvolved tserver is down

Repository: kudu Updated Branches: refs/heads/master de57e3c92 -> ce0db9157 [tools] KUDU-2331: Allow move tool to work when uninvolved tserver is down The move tool requires a clean ksck for the tablet it's acting on for safety reasons, but the check for this failed if a tablet server was down

[2/4] kudu git commit: Remove tcmalloc_spinlock_contention metric

Remove tcmalloc_spinlock_contention metric Spinlock contention was removed from tcmalloc upstream, so this metric has been set to 0 since we upgraded to tcmalloc 2.6. I looked briefly at reverting its removal upstream, but the revert would be fairly large, so I think it's best to just accept the l

[kudu] Git Push Summary

Repository: kudu Updated Branches: refs/heads/branch-1.7.x [created] de57e3c92

kudu git commit: KUDU-2334: Fix OutboundTransfer::TransferStarted() to work with SSL_write()

Repository: kudu Updated Branches: refs/heads/master 287dc5408 -> de57e3c92 KUDU-2334: Fix OutboundTransfer::TransferStarted() to work with SSL_write() Previously, OutboundTransfer::TransferStarted() returns true iff non-zero bytes have been successfully sent via Writev(). As it turns out, thi