Tags: andyZheng/kudu
Tags
docs: Replace links to github.com/cloudera/kudu with apache/incubator… …-kudu Change-Id: I17d8d28e3f3c72c5bb1032b47f343004b480571b Reviewed-on: http://gerrit.cloudera.org:8080/2403 Tested-by: Kudu Jenkins Reviewed-by: Misty Stanley-Jones <misty@apache.org> (cherry picked from commit e017602) Reviewed-on: http://gerrit.cloudera.org:8080/2461 Reviewed-by: Jean-Daniel Cryans Tested-by: Jean-Daniel Cryans
Make 0.7.1-SNAPSHOT non-shapshot Change-Id: I2a2834318d6ba9e4054a45ee0c67ea67791c185b Reviewed-on: http://gerrit.cloudera.org:8080/2416 Tested-by: Kudu Jenkins Reviewed-by: Adar Dembo <adar@cloudera.com>
KUDU-1328: crash when remote bootstrap session races with tablet dele… …tion An innocuous log statement introduced in commit b841512 can cause a crash if a remote bootstrap request for a particular tablet arrives as the tserver deletes that tablet. I'm still working on an integration test that faithfully reproduces the crash, but until then, here's a low-risk fix for the log statement that can go into 0.7. Change-Id: I6a487ba4f37383479170519866509f3f3d88dc5d Reviewed-on: http://gerrit.cloudera.org:8080/2193 Tested-by: Kudu Jenkins Reviewed-by: Jean-Daniel Cryans (cherry picked from commit 7b1ea74) Reviewed-on: http://gerrit.cloudera.org:8080/2196
Set -rpath in all thirdparty libs for compat with gold Make sure that thirdparty shared libs are built with a -rpath that includes thirdparty/installed-deps* because the GNU gold linker specifies RUNPATH by default, instead of RPATH. This is due to the fact that at the time of this writing, gold defaults to --enable-new-dtags while binutils ld defaults to --disable-new-dtags [1]. Unfortunately, glibc does not search an executable's RUNPATH for transitive dependencies [2], like it does for RPATH. This results in symbol not found errors for full builds done using gold as the linker unless we apply this change. This patch adds the installed-deps directory to the -rpath of thirdparty shared objects so that the correct paths are set and the symbols are resolved. This issue was originally identified by Todd, and here is the text of his email to the dev list: a) I usually use gold rather than binutils ld as my linker. gold generates RUNPATH instead of RPATH by default, which has the difference that RUNPATH doesn't propagate transitively. In other words, even though protoc-gen-insertions has installed-deps/lib in its RUNPATH, it doesn't use _that_ RPATH when looking for dependencies of libglog.so, because libglog.so has its own RUNPATH. b) my libglog.so's RUNPATH doesn't have installed-deps/. It turns out that, after I rebuilt my thirdparty from git completely clean, that one didn't end up with it either. It only got installed-deps/ in its RUNPATH before because I had an old 'libgflags.la' file lying around. c) we no longer generate 'libgflags.la' from the gflags build after 7a68e1f which switched from using autotools to cmake to build and install gflag. This means that we don't generate the libtool control file 'libgflags.la' anymore, though my old one got orphaned in the build directory. [1] http://blog.tremily.us/posts/rpath/ [2] https://sourceware.org/bugzilla/show_bug.cgi?id=13945 Change-Id: Ic50b3667f96cec73497248751e9afc785e3f7979 Reviewed-on: http://gerrit.cloudera.org:8080/2123 Reviewed-by: Adar Dembo <adar@cloudera.com> Tested-by: Kudu Jenkins (cherry picked from commit 2567ed0) Reviewed-on: http://gerrit.cloudera.org:8080/2130 Reviewed-by: Jean-Daniel Cryans Tested-by: Jean-Daniel Cryans
KUDU-1296. Release notes for 0.7.0 Reviewed-on: http://gerrit.cloudera.org:8080/2062 Reviewed-by: Jean-Daniel Cryans Tested-by: Jean-Daniel Cryans Reviewed-by: Adar Dembo <adar@cloudera.com> (cherry picked from commit 2d029b3) Change-Id: I863475c55645897df05b3ce51967abf317ffcf56 Reviewed-on: http://gerrit.cloudera.org:8080/2087 Reviewed-by: Jean-Daniel Cryans Tested-by: Jean-Daniel Cryans
rpc: add a flag for keepalive time, bump default to 65s We're seeing KUDU-279 fairly often in stress tests on a cluster. Until that is fixed, it makes sense to bump the RPC keepalive time significantly. Bumping to 65 seconds should be enough that any "once a minute" type heartbeats would keep the connection alive. In particular, this will be long enough that Impala's scanner keepalive heartbeats will keep RPC connections to the tablet servers alive, hopefully preventing the errors we're seeing in some large Impala queries. Change-Id: I3059ca764447b8073b69972728ad1ebd41b3e8c4 Reviewed-on: http://gerrit.cloudera.org:8080/1497 Reviewed-by: Jean-Daniel Cryans Tested-by: Internal Jenkins (cherry picked from commit ff502b6) Reviewed-on: http://gerrit.cloudera.org:8080/1499 Tested-by: Jean-Daniel Cryans
rpc: add a flag for keepalive time, bump default to 65s We're seeing KUDU-279 fairly often in stress tests on a cluster. Until that is fixed, it makes sense to bump the RPC keepalive time significantly. Bumping to 65 seconds should be enough that any "once a minute" type heartbeats would keep the connection alive. In particular, this will be long enough that Impala's scanner keepalive heartbeats will keep RPC connections to the tablet servers alive, hopefully preventing the errors we're seeing in some large Impala queries. Change-Id: I3059ca764447b8073b69972728ad1ebd41b3e8c4 Reviewed-on: http://gerrit.cloudera.org:8080/1497 Reviewed-by: Jean-Daniel Cryans Tested-by: Internal Jenkins (cherry picked from commit ff502b6) Reviewed-on: http://gerrit.cloudera.org:8080/1499 Tested-by: Jean-Daniel Cryans
[cpp/java client] - Clarify the meaning of the read modes This clarifies the meaning of scanner's read modes in both clients. We were previously pointing users to the explanation in common.proto, which was not a good idea, since users may not have direct access to it. This also makes it clear what the read modes mean in ACID terms, since we've been asked that question a lot. Change-Id: I7512a9c62c7f746b883a670ab48d79fa83febf09 Reviewed-on: http://gerrit.cloudera.org:8080/1427 Reviewed-by: Jean-Daniel Cryans Tested-by: Internal Jenkins (cherry picked from commit c62f40d) Reviewed-on: http://gerrit.cloudera.org:8080/1455 Reviewed-by: David Ribeiro Alves <david.alves@cloudera.com> Tested-by: Jean-Daniel Cryans
PreviousNext