Searched +hist:0 +hist:fb123d8 (Results 1 - 11 of 11) sorted by relevance
/Couchbase_C_Client_v3.0/cmake/Modules/ | ||
H A D | GenerateConfigDotH.cmake | diff 0ec214f1 Mon Aug 07 14:52:34 UTC 2017 Sergey Avseyev <sergey.avseyev@gmail.com> CCBC-816: Fix DNS SRV support on Fedora 26 and FreeBSD Change-Id: I0cbb54b615f5c71c75e91a02145def0df031633d Reviewed-on: http://review.couchbase.org/82000 Tested-by: Build Bot <build@couchbase.com> Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com> diff 0fb123d8 Fri Jan 30 23:35:02 UTC 2015 Mark Nunberg <mnunberg@haskalah.org> CCBC-566: DNS SRV support This adds DNS SRV lookups for bootstrapping. This is provided in two forms: 1. When there is only a single hostname with no port. This is called implicit lookup 2. When the scheme `couchbase+dnssrv://` is used. This is an explicit mode and is considered internal to the library. In both cases the input hostname will be selected and attempted for a DNS SRV query. If it succeeds, then the hosts use for the query will be returned. If the query fails, implicit mode will continue, using the hostname as a couchbase node, whereas explicit mode will fail. Explicit mode is useful for debugging the dns srv feauture itself. Currently support depends on either Windows (which works "out of the box") and libbind/libresolv, which come bundled with glibc on both OS X and Linux. This may fail to function on very ancient systems; in which event these routines are stubbed out with no-op equivalents. Change-Id: I0d54b63c1e6cef64e5a09280343e9aba24ed7a80 Reviewed-on: http://review.couchbase.org/46177 Reviewed-by: Brett Lawson <brett19@gmail.com> Tested-by: buildbot <build@couchbase.com> diff 0fb123d8 Fri Jan 30 23:35:02 UTC 2015 Mark Nunberg <mnunberg@haskalah.org> CCBC-566: DNS SRV support This adds DNS SRV lookups for bootstrapping. This is provided in two forms: 1. When there is only a single hostname with no port. This is called implicit lookup 2. When the scheme `couchbase+dnssrv://` is used. This is an explicit mode and is considered internal to the library. In both cases the input hostname will be selected and attempted for a DNS SRV query. If it succeeds, then the hosts use for the query will be returned. If the query fails, implicit mode will continue, using the hostname as a couchbase node, whereas explicit mode will fail. Explicit mode is useful for debugging the dns srv feauture itself. Currently support depends on either Windows (which works "out of the box") and libbind/libresolv, which come bundled with glibc on both OS X and Linux. This may fail to function on very ancient systems; in which event these routines are stubbed out with no-op equivalents. Change-Id: I0d54b63c1e6cef64e5a09280343e9aba24ed7a80 Reviewed-on: http://review.couchbase.org/46177 Reviewed-by: Brett Lawson <brett19@gmail.com> Tested-by: buildbot <build@couchbase.com> |
/Couchbase_C_Client_v3.0/src/ | ||
H A D | hostlist.h | diff 0b0310e1 Wed Apr 03 07:33:33 UTC 2019 Sergey Avseyev <sergey.avseyev@gmail.com> Reformat sources with clang-format Change-Id: I6d9cdc0ca66b7cd7b75a5e064b64fe0adbc0b106 Reviewed-on: http://review.couchbase.org/107219 Tested-by: Build Bot <build@couchbase.com> Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com> diff 0fb123d8 Fri Jan 30 23:35:02 UTC 2015 Mark Nunberg <mnunberg@haskalah.org> CCBC-566: DNS SRV support This adds DNS SRV lookups for bootstrapping. This is provided in two forms: 1. When there is only a single hostname with no port. This is called implicit lookup 2. When the scheme `couchbase+dnssrv://` is used. This is an explicit mode and is considered internal to the library. In both cases the input hostname will be selected and attempted for a DNS SRV query. If it succeeds, then the hosts use for the query will be returned. If the query fails, implicit mode will continue, using the hostname as a couchbase node, whereas explicit mode will fail. Explicit mode is useful for debugging the dns srv feauture itself. Currently support depends on either Windows (which works "out of the box") and libbind/libresolv, which come bundled with glibc on both OS X and Linux. This may fail to function on very ancient systems; in which event these routines are stubbed out with no-op equivalents. Change-Id: I0d54b63c1e6cef64e5a09280343e9aba24ed7a80 Reviewed-on: http://review.couchbase.org/46177 Reviewed-by: Brett Lawson <brett19@gmail.com> Tested-by: buildbot <build@couchbase.com> diff 0fb123d8 Fri Jan 30 23:35:02 UTC 2015 Mark Nunberg <mnunberg@haskalah.org> CCBC-566: DNS SRV support This adds DNS SRV lookups for bootstrapping. This is provided in two forms: 1. When there is only a single hostname with no port. This is called implicit lookup 2. When the scheme `couchbase+dnssrv://` is used. This is an explicit mode and is considered internal to the library. In both cases the input hostname will be selected and attempted for a DNS SRV query. If it succeeds, then the hosts use for the query will be returned. If the query fails, implicit mode will continue, using the hostname as a couchbase node, whereas explicit mode will fail. Explicit mode is useful for debugging the dns srv feauture itself. Currently support depends on either Windows (which works "out of the box") and libbind/libresolv, which come bundled with glibc on both OS X and Linux. This may fail to function on very ancient systems; in which event these routines are stubbed out with no-op equivalents. Change-Id: I0d54b63c1e6cef64e5a09280343e9aba24ed7a80 Reviewed-on: http://review.couchbase.org/46177 Reviewed-by: Brett Lawson <brett19@gmail.com> Tested-by: buildbot <build@couchbase.com> |
H A D | connspec.cc | diff 0b0310e1 Wed Apr 03 07:33:33 UTC 2019 Sergey Avseyev <sergey.avseyev@gmail.com> Reformat sources with clang-format Change-Id: I6d9cdc0ca66b7cd7b75a5e064b64fe0adbc0b106 Reviewed-on: http://review.couchbase.org/107219 Tested-by: Build Bot <build@couchbase.com> Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com> diff 0e6ccebf Mon Dec 11 20:53:22 UTC 2017 Sergey Avseyev <sergey.avseyev@gmail.com> CCBC-880: implement SSL client certificate authentication Change-Id: I796e21454b4feac3de934c193fc8d7db66a1e710 Reviewed-on: http://review.couchbase.org/87015 Reviewed-by: Ellis Breen <ellis.breen@couchbase.com> Tested-by: Build Bot <build@couchbase.com> diff 0fb123d8 Fri Jan 30 23:35:02 UTC 2015 Mark Nunberg <mnunberg@haskalah.org> CCBC-566: DNS SRV support This adds DNS SRV lookups for bootstrapping. This is provided in two forms: 1. When there is only a single hostname with no port. This is called implicit lookup 2. When the scheme `couchbase+dnssrv://` is used. This is an explicit mode and is considered internal to the library. In both cases the input hostname will be selected and attempted for a DNS SRV query. If it succeeds, then the hosts use for the query will be returned. If the query fails, implicit mode will continue, using the hostname as a couchbase node, whereas explicit mode will fail. Explicit mode is useful for debugging the dns srv feauture itself. Currently support depends on either Windows (which works "out of the box") and libbind/libresolv, which come bundled with glibc on both OS X and Linux. This may fail to function on very ancient systems; in which event these routines are stubbed out with no-op equivalents. Change-Id: I0d54b63c1e6cef64e5a09280343e9aba24ed7a80 Reviewed-on: http://review.couchbase.org/46177 Reviewed-by: Brett Lawson <brett19@gmail.com> Tested-by: buildbot <build@couchbase.com> diff 0fb123d8 Fri Jan 30 23:35:02 UTC 2015 Mark Nunberg <mnunberg@haskalah.org> CCBC-566: DNS SRV support This adds DNS SRV lookups for bootstrapping. This is provided in two forms: 1. When there is only a single hostname with no port. This is called implicit lookup 2. When the scheme `couchbase+dnssrv://` is used. This is an explicit mode and is considered internal to the library. In both cases the input hostname will be selected and attempted for a DNS SRV query. If it succeeds, then the hosts use for the query will be returned. If the query fails, implicit mode will continue, using the hostname as a couchbase node, whereas explicit mode will fail. Explicit mode is useful for debugging the dns srv feauture itself. Currently support depends on either Windows (which works "out of the box") and libbind/libresolv, which come bundled with glibc on both OS X and Linux. This may fail to function on very ancient systems; in which event these routines are stubbed out with no-op equivalents. Change-Id: I0d54b63c1e6cef64e5a09280343e9aba24ed7a80 Reviewed-on: http://review.couchbase.org/46177 Reviewed-by: Brett Lawson <brett19@gmail.com> Tested-by: buildbot <build@couchbase.com> |
H A D | connspec.h | diff 0b0310e1 Wed Apr 03 07:33:33 UTC 2019 Sergey Avseyev <sergey.avseyev@gmail.com> Reformat sources with clang-format Change-Id: I6d9cdc0ca66b7cd7b75a5e064b64fe0adbc0b106 Reviewed-on: http://review.couchbase.org/107219 Tested-by: Build Bot <build@couchbase.com> Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com> diff 0e6ccebf Mon Dec 11 20:53:22 UTC 2017 Sergey Avseyev <sergey.avseyev@gmail.com> CCBC-880: implement SSL client certificate authentication Change-Id: I796e21454b4feac3de934c193fc8d7db66a1e710 Reviewed-on: http://review.couchbase.org/87015 Reviewed-by: Ellis Breen <ellis.breen@couchbase.com> Tested-by: Build Bot <build@couchbase.com> diff 0fb123d8 Fri Jan 30 23:35:02 UTC 2015 Mark Nunberg <mnunberg@haskalah.org> CCBC-566: DNS SRV support This adds DNS SRV lookups for bootstrapping. This is provided in two forms: 1. When there is only a single hostname with no port. This is called implicit lookup 2. When the scheme `couchbase+dnssrv://` is used. This is an explicit mode and is considered internal to the library. In both cases the input hostname will be selected and attempted for a DNS SRV query. If it succeeds, then the hosts use for the query will be returned. If the query fails, implicit mode will continue, using the hostname as a couchbase node, whereas explicit mode will fail. Explicit mode is useful for debugging the dns srv feauture itself. Currently support depends on either Windows (which works "out of the box") and libbind/libresolv, which come bundled with glibc on both OS X and Linux. This may fail to function on very ancient systems; in which event these routines are stubbed out with no-op equivalents. Change-Id: I0d54b63c1e6cef64e5a09280343e9aba24ed7a80 Reviewed-on: http://review.couchbase.org/46177 Reviewed-by: Brett Lawson <brett19@gmail.com> Tested-by: buildbot <build@couchbase.com> diff 0fb123d8 Fri Jan 30 23:35:02 UTC 2015 Mark Nunberg <mnunberg@haskalah.org> CCBC-566: DNS SRV support This adds DNS SRV lookups for bootstrapping. This is provided in two forms: 1. When there is only a single hostname with no port. This is called implicit lookup 2. When the scheme `couchbase+dnssrv://` is used. This is an explicit mode and is considered internal to the library. In both cases the input hostname will be selected and attempted for a DNS SRV query. If it succeeds, then the hosts use for the query will be returned. If the query fails, implicit mode will continue, using the hostname as a couchbase node, whereas explicit mode will fail. Explicit mode is useful for debugging the dns srv feauture itself. Currently support depends on either Windows (which works "out of the box") and libbind/libresolv, which come bundled with glibc on both OS X and Linux. This may fail to function on very ancient systems; in which event these routines are stubbed out with no-op equivalents. Change-Id: I0d54b63c1e6cef64e5a09280343e9aba24ed7a80 Reviewed-on: http://review.couchbase.org/46177 Reviewed-by: Brett Lawson <brett19@gmail.com> Tested-by: buildbot <build@couchbase.com> |
H A D | instance.cc | diff 0a2a74f5 Thu May 06 18:15:24 UTC 2021 Sergey Avseyev <sergey.avseyev@gmail.com> CCBC-861: purge pipelines on lcb_destroy Change-Id: I8dcab68e420f97f4cd994144a2e2051c310315f3 Reviewed-on: http://review.couchbase.org/c/libcouchbase/+/153041 Tested-by: Build Bot <build@couchbase.com> Reviewed-by: Brett Lawson <brett19@gmail.com> diff 0b0310e1 Wed Apr 03 07:33:33 UTC 2019 Sergey Avseyev <sergey.avseyev@gmail.com> Reformat sources with clang-format Change-Id: I6d9cdc0ca66b7cd7b75a5e064b64fe0adbc0b106 Reviewed-on: http://review.couchbase.org/107219 Tested-by: Build Bot <build@couchbase.com> Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com> diff 0e6ccebf Mon Dec 11 20:53:22 UTC 2017 Sergey Avseyev <sergey.avseyev@gmail.com> CCBC-880: implement SSL client certificate authentication Change-Id: I796e21454b4feac3de934c193fc8d7db66a1e710 Reviewed-on: http://review.couchbase.org/87015 Reviewed-by: Ellis Breen <ellis.breen@couchbase.com> Tested-by: Build Bot <build@couchbase.com> diff 0fb123d8 Fri Jan 30 23:35:02 UTC 2015 Mark Nunberg <mnunberg@haskalah.org> CCBC-566: DNS SRV support This adds DNS SRV lookups for bootstrapping. This is provided in two forms: 1. When there is only a single hostname with no port. This is called implicit lookup 2. When the scheme `couchbase+dnssrv://` is used. This is an explicit mode and is considered internal to the library. In both cases the input hostname will be selected and attempted for a DNS SRV query. If it succeeds, then the hosts use for the query will be returned. If the query fails, implicit mode will continue, using the hostname as a couchbase node, whereas explicit mode will fail. Explicit mode is useful for debugging the dns srv feauture itself. Currently support depends on either Windows (which works "out of the box") and libbind/libresolv, which come bundled with glibc on both OS X and Linux. This may fail to function on very ancient systems; in which event these routines are stubbed out with no-op equivalents. Change-Id: I0d54b63c1e6cef64e5a09280343e9aba24ed7a80 Reviewed-on: http://review.couchbase.org/46177 Reviewed-by: Brett Lawson <brett19@gmail.com> Tested-by: buildbot <build@couchbase.com> diff 0fb123d8 Fri Jan 30 23:35:02 UTC 2015 Mark Nunberg <mnunberg@haskalah.org> CCBC-566: DNS SRV support This adds DNS SRV lookups for bootstrapping. This is provided in two forms: 1. When there is only a single hostname with no port. This is called implicit lookup 2. When the scheme `couchbase+dnssrv://` is used. This is an explicit mode and is considered internal to the library. In both cases the input hostname will be selected and attempted for a DNS SRV query. If it succeeds, then the hosts use for the query will be returned. If the query fails, implicit mode will continue, using the hostname as a couchbase node, whereas explicit mode will fail. Explicit mode is useful for debugging the dns srv feauture itself. Currently support depends on either Windows (which works "out of the box") and libbind/libresolv, which come bundled with glibc on both OS X and Linux. This may fail to function on very ancient systems; in which event these routines are stubbed out with no-op equivalents. Change-Id: I0d54b63c1e6cef64e5a09280343e9aba24ed7a80 Reviewed-on: http://review.couchbase.org/46177 Reviewed-by: Brett Lawson <brett19@gmail.com> Tested-by: buildbot <build@couchbase.com> diff 0be6d6b4 Fri Dec 16 17:59:51 UTC 2016 Mark Nunberg <mnunberg@haskalah.org> remove mc_SERVER typedef All components needing to access lcb::Server are now in C++, so there is no need for a C compat layer Change-Id: I2836b58faa49070a3ef52432eec4cc1e28f00b31 Reviewed-on: http://review.couchbase.org/71064 Tested-by: buildbot <build@couchbase.com> Reviewed-by: Brett Lawson <brett19@gmail.com> diff 0ffba2c0 Fri Jul 17 16:19:12 UTC 2015 Mark Nunberg <mnunberg@haskalah.org> CCBC-624: Allow histogram for n1qlback (1/3) This change decouples the histogram information from the instance itself, allowing external consumers. Change-Id: I38ae7980da7433df555c1687fb73f76c6b69abad Reviewed-on: http://review.couchbase.org/53340 Tested-by: buildbot <build@couchbase.com> Reviewed-by: Subhashni Balakrishnan <b.subhashni@gmail.com> diff 0ca95f98 Mon Sep 22 19:33:10 UTC 2014 Mark Nunberg <mnunberg@haskalah.org> Stylistic enhancements for durability This is one of the oldest parts in the codebase. This commit tries to bring the header comments and source code formatting/styling up to sync with the rest of the code. Change-Id: I1e7a5849b0b402c656daa467552895dc5d5f1b47 Reviewed-on: http://review.couchbase.org/41613 Tested-by: Mark Nunberg <mnunberg@haskalah.org> Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com> diff 0ac7fc4b Tue Jul 29 16:56:58 UTC 2014 Mark Nunberg <mnunberg@haskalah.org> Clarify bootstrap API layout This removes all the helper macro entry points into lcb_bootstrap_common() and replaces them with direct calls. Additionally it creates a new file called bootstrap.h which contains a more detailed description of how bootstrap actually works, and is now indexed by Doxygen via `make doc-internal`. Change-Id: Ice53f3b34524ffb41ee0cb58897098ceaefc5206 Reviewed-on: http://review.couchbase.org/40014 Tested-by: Mark Nunberg <mnunberg@haskalah.org> Reviewed-by: Brett Lawson <brett19@gmail.com> diff 86585753 Tue Nov 20 22:21:30 UTC 2012 Sergey Avseyev <sergey.avseyev@gmail.com> CCBC-104 Fix illegal memory access ==19659== General Protection Fault ==19659== at 0x4E93216: ringbuffer_write (ringbuffer.c:127) ==19659== by 0x4E90ACA: relocate_packets (instance.c:523) ==19659== by 0x4E90E5E: lcb_update_serverlist (instance.c:583) ==19659== by 0x4E91B83: vbucket_stream_handler (instance.c:964) ==19659== by 0x60B7599: event_base_loop (in /usr/lib64/libevent-1.4.so.2.1.3) ==19659== by 0x5EB0320: lcb_io_run_event_loop (plugin-libevent.c:320) ==19659== by 0x4E982B4: lcb_wait (wait.c:112) Change-Id: I6d8657433665b74ec5700f7665103f346bcfd46b Reviewed-on: http://review.couchbase.org/22691 Tested-by: Sergey Avseyev <sergey.avseyev@gmail.com> Reviewed-by: Trond Norbye <trond.norbye@gmail.com> diff 86585753 Tue Nov 20 22:21:30 UTC 2012 Sergey Avseyev <sergey.avseyev@gmail.com> CCBC-104 Fix illegal memory access ==19659== General Protection Fault ==19659== at 0x4E93216: ringbuffer_write (ringbuffer.c:127) ==19659== by 0x4E90ACA: relocate_packets (instance.c:523) ==19659== by 0x4E90E5E: lcb_update_serverlist (instance.c:583) ==19659== by 0x4E91B83: vbucket_stream_handler (instance.c:964) ==19659== by 0x60B7599: event_base_loop (in /usr/lib64/libevent-1.4.so.2.1.3) ==19659== by 0x5EB0320: lcb_io_run_event_loop (plugin-libevent.c:320) ==19659== by 0x4E982B4: lcb_wait (wait.c:112) Change-Id: I6d8657433665b74ec5700f7665103f346bcfd46b Reviewed-on: http://review.couchbase.org/22691 Tested-by: Sergey Avseyev <sergey.avseyev@gmail.com> Reviewed-by: Trond Norbye <trond.norbye@gmail.com> diff 86585753 Tue Nov 20 22:21:30 UTC 2012 Sergey Avseyev <sergey.avseyev@gmail.com> CCBC-104 Fix illegal memory access ==19659== General Protection Fault ==19659== at 0x4E93216: ringbuffer_write (ringbuffer.c:127) ==19659== by 0x4E90ACA: relocate_packets (instance.c:523) ==19659== by 0x4E90E5E: lcb_update_serverlist (instance.c:583) ==19659== by 0x4E91B83: vbucket_stream_handler (instance.c:964) ==19659== by 0x60B7599: event_base_loop (in /usr/lib64/libevent-1.4.so.2.1.3) ==19659== by 0x5EB0320: lcb_io_run_event_loop (plugin-libevent.c:320) ==19659== by 0x4E982B4: lcb_wait (wait.c:112) Change-Id: I6d8657433665b74ec5700f7665103f346bcfd46b Reviewed-on: http://review.couchbase.org/22691 Tested-by: Sergey Avseyev <sergey.avseyev@gmail.com> Reviewed-by: Trond Norbye <trond.norbye@gmail.com> diff 86585753 Tue Nov 20 22:21:30 UTC 2012 Sergey Avseyev <sergey.avseyev@gmail.com> CCBC-104 Fix illegal memory access ==19659== General Protection Fault ==19659== at 0x4E93216: ringbuffer_write (ringbuffer.c:127) ==19659== by 0x4E90ACA: relocate_packets (instance.c:523) ==19659== by 0x4E90E5E: lcb_update_serverlist (instance.c:583) ==19659== by 0x4E91B83: vbucket_stream_handler (instance.c:964) ==19659== by 0x60B7599: event_base_loop (in /usr/lib64/libevent-1.4.so.2.1.3) ==19659== by 0x5EB0320: lcb_io_run_event_loop (plugin-libevent.c:320) ==19659== by 0x4E982B4: lcb_wait (wait.c:112) Change-Id: I6d8657433665b74ec5700f7665103f346bcfd46b Reviewed-on: http://review.couchbase.org/22691 Tested-by: Sergey Avseyev <sergey.avseyev@gmail.com> Reviewed-by: Trond Norbye <trond.norbye@gmail.com> diff 86585753 Tue Nov 20 22:21:30 UTC 2012 Sergey Avseyev <sergey.avseyev@gmail.com> CCBC-104 Fix illegal memory access ==19659== General Protection Fault ==19659== at 0x4E93216: ringbuffer_write (ringbuffer.c:127) ==19659== by 0x4E90ACA: relocate_packets (instance.c:523) ==19659== by 0x4E90E5E: lcb_update_serverlist (instance.c:583) ==19659== by 0x4E91B83: vbucket_stream_handler (instance.c:964) ==19659== by 0x60B7599: event_base_loop (in /usr/lib64/libevent-1.4.so.2.1.3) ==19659== by 0x5EB0320: lcb_io_run_event_loop (plugin-libevent.c:320) ==19659== by 0x4E982B4: lcb_wait (wait.c:112) Change-Id: I6d8657433665b74ec5700f7665103f346bcfd46b Reviewed-on: http://review.couchbase.org/22691 Tested-by: Sergey Avseyev <sergey.avseyev@gmail.com> Reviewed-by: Trond Norbye <trond.norbye@gmail.com> diff 86585753 Tue Nov 20 22:21:30 UTC 2012 Sergey Avseyev <sergey.avseyev@gmail.com> CCBC-104 Fix illegal memory access ==19659== General Protection Fault ==19659== at 0x4E93216: ringbuffer_write (ringbuffer.c:127) ==19659== by 0x4E90ACA: relocate_packets (instance.c:523) ==19659== by 0x4E90E5E: lcb_update_serverlist (instance.c:583) ==19659== by 0x4E91B83: vbucket_stream_handler (instance.c:964) ==19659== by 0x60B7599: event_base_loop (in /usr/lib64/libevent-1.4.so.2.1.3) ==19659== by 0x5EB0320: lcb_io_run_event_loop (plugin-libevent.c:320) ==19659== by 0x4E982B4: lcb_wait (wait.c:112) Change-Id: I6d8657433665b74ec5700f7665103f346bcfd46b Reviewed-on: http://review.couchbase.org/22691 Tested-by: Sergey Avseyev <sergey.avseyev@gmail.com> Reviewed-by: Trond Norbye <trond.norbye@gmail.com> diff 86585753 Tue Nov 20 22:21:30 UTC 2012 Sergey Avseyev <sergey.avseyev@gmail.com> CCBC-104 Fix illegal memory access ==19659== General Protection Fault ==19659== at 0x4E93216: ringbuffer_write (ringbuffer.c:127) ==19659== by 0x4E90ACA: relocate_packets (instance.c:523) ==19659== by 0x4E90E5E: lcb_update_serverlist (instance.c:583) ==19659== by 0x4E91B83: vbucket_stream_handler (instance.c:964) ==19659== by 0x60B7599: event_base_loop (in /usr/lib64/libevent-1.4.so.2.1.3) ==19659== by 0x5EB0320: lcb_io_run_event_loop (plugin-libevent.c:320) ==19659== by 0x4E982B4: lcb_wait (wait.c:112) Change-Id: I6d8657433665b74ec5700f7665103f346bcfd46b Reviewed-on: http://review.couchbase.org/22691 Tested-by: Sergey Avseyev <sergey.avseyev@gmail.com> Reviewed-by: Trond Norbye <trond.norbye@gmail.com> |
H A D | internal.h | diff 0b0310e1 Wed Apr 03 07:33:33 UTC 2019 Sergey Avseyev <sergey.avseyev@gmail.com> Reformat sources with clang-format Change-Id: I6d9cdc0ca66b7cd7b75a5e064b64fe0adbc0b106 Reviewed-on: http://review.couchbase.org/107219 Tested-by: Build Bot <build@couchbase.com> Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com> diff 0fb123d8 Fri Jan 30 23:35:02 UTC 2015 Mark Nunberg <mnunberg@haskalah.org> CCBC-566: DNS SRV support This adds DNS SRV lookups for bootstrapping. This is provided in two forms: 1. When there is only a single hostname with no port. This is called implicit lookup 2. When the scheme `couchbase+dnssrv://` is used. This is an explicit mode and is considered internal to the library. In both cases the input hostname will be selected and attempted for a DNS SRV query. If it succeeds, then the hosts use for the query will be returned. If the query fails, implicit mode will continue, using the hostname as a couchbase node, whereas explicit mode will fail. Explicit mode is useful for debugging the dns srv feauture itself. Currently support depends on either Windows (which works "out of the box") and libbind/libresolv, which come bundled with glibc on both OS X and Linux. This may fail to function on very ancient systems; in which event these routines are stubbed out with no-op equivalents. Change-Id: I0d54b63c1e6cef64e5a09280343e9aba24ed7a80 Reviewed-on: http://review.couchbase.org/46177 Reviewed-by: Brett Lawson <brett19@gmail.com> Tested-by: buildbot <build@couchbase.com> diff 0fb123d8 Fri Jan 30 23:35:02 UTC 2015 Mark Nunberg <mnunberg@haskalah.org> CCBC-566: DNS SRV support This adds DNS SRV lookups for bootstrapping. This is provided in two forms: 1. When there is only a single hostname with no port. This is called implicit lookup 2. When the scheme `couchbase+dnssrv://` is used. This is an explicit mode and is considered internal to the library. In both cases the input hostname will be selected and attempted for a DNS SRV query. If it succeeds, then the hosts use for the query will be returned. If the query fails, implicit mode will continue, using the hostname as a couchbase node, whereas explicit mode will fail. Explicit mode is useful for debugging the dns srv feauture itself. Currently support depends on either Windows (which works "out of the box") and libbind/libresolv, which come bundled with glibc on both OS X and Linux. This may fail to function on very ancient systems; in which event these routines are stubbed out with no-op equivalents. Change-Id: I0d54b63c1e6cef64e5a09280343e9aba24ed7a80 Reviewed-on: http://review.couchbase.org/46177 Reviewed-by: Brett Lawson <brett19@gmail.com> Tested-by: buildbot <build@couchbase.com> diff 0be6d6b4 Fri Dec 16 17:59:51 UTC 2016 Mark Nunberg <mnunberg@haskalah.org> remove mc_SERVER typedef All components needing to access lcb::Server are now in C++, so there is no need for a C compat layer Change-Id: I2836b58faa49070a3ef52432eec4cc1e28f00b31 Reviewed-on: http://review.couchbase.org/71064 Tested-by: buildbot <build@couchbase.com> Reviewed-by: Brett Lawson <brett19@gmail.com> diff 0ffba2c0 Fri Jul 17 16:19:12 UTC 2015 Mark Nunberg <mnunberg@haskalah.org> CCBC-624: Allow histogram for n1qlback (1/3) This change decouples the histogram information from the instance itself, allowing external consumers. Change-Id: I38ae7980da7433df555c1687fb73f76c6b69abad Reviewed-on: http://review.couchbase.org/53340 Tested-by: buildbot <build@couchbase.com> Reviewed-by: Subhashni Balakrishnan <b.subhashni@gmail.com> diff 0ca95f98 Mon Sep 22 19:33:10 UTC 2014 Mark Nunberg <mnunberg@haskalah.org> Stylistic enhancements for durability This is one of the oldest parts in the codebase. This commit tries to bring the header comments and source code formatting/styling up to sync with the rest of the code. Change-Id: I1e7a5849b0b402c656daa467552895dc5d5f1b47 Reviewed-on: http://review.couchbase.org/41613 Tested-by: Mark Nunberg <mnunberg@haskalah.org> Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com> diff 0ac7fc4b Tue Jul 29 16:56:58 UTC 2014 Mark Nunberg <mnunberg@haskalah.org> Clarify bootstrap API layout This removes all the helper macro entry points into lcb_bootstrap_common() and replaces them with direct calls. Additionally it creates a new file called bootstrap.h which contains a more detailed description of how bootstrap actually works, and is now indexed by Doxygen via `make doc-internal`. Change-Id: Ice53f3b34524ffb41ee0cb58897098ceaefc5206 Reviewed-on: http://review.couchbase.org/40014 Tested-by: Mark Nunberg <mnunberg@haskalah.org> Reviewed-by: Brett Lawson <brett19@gmail.com> diff 0a7576ad Wed Dec 21 12:01:21 UTC 2011 Trond Norbye <trond.norbye@gmail.com> Update copyright year Change-Id: I6655c26cca406c7d6d383b2716f2ba83cc658cbf Reviewed-on: http://review.couchbase.org/11790 Reviewed-by: Trond Norbye <trond.norbye@gmail.com> Tested-by: Trond Norbye <trond.norbye@gmail.com> |
/Couchbase_C_Client_v3.0/tests/basic/ | ||
H A D | t_connstr.cc | diff 0b0310e1 Wed Apr 03 07:33:33 UTC 2019 Sergey Avseyev <sergey.avseyev@gmail.com> Reformat sources with clang-format Change-Id: I6d9cdc0ca66b7cd7b75a5e064b64fe0adbc0b106 Reviewed-on: http://review.couchbase.org/107219 Tested-by: Build Bot <build@couchbase.com> Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com> diff 0fb123d8 Fri Jan 30 23:35:02 UTC 2015 Mark Nunberg <mnunberg@haskalah.org> CCBC-566: DNS SRV support This adds DNS SRV lookups for bootstrapping. This is provided in two forms: 1. When there is only a single hostname with no port. This is called implicit lookup 2. When the scheme `couchbase+dnssrv://` is used. This is an explicit mode and is considered internal to the library. In both cases the input hostname will be selected and attempted for a DNS SRV query. If it succeeds, then the hosts use for the query will be returned. If the query fails, implicit mode will continue, using the hostname as a couchbase node, whereas explicit mode will fail. Explicit mode is useful for debugging the dns srv feauture itself. Currently support depends on either Windows (which works "out of the box") and libbind/libresolv, which come bundled with glibc on both OS X and Linux. This may fail to function on very ancient systems; in which event these routines are stubbed out with no-op equivalents. Change-Id: I0d54b63c1e6cef64e5a09280343e9aba24ed7a80 Reviewed-on: http://review.couchbase.org/46177 Reviewed-by: Brett Lawson <brett19@gmail.com> Tested-by: buildbot <build@couchbase.com> diff 0fb123d8 Fri Jan 30 23:35:02 UTC 2015 Mark Nunberg <mnunberg@haskalah.org> CCBC-566: DNS SRV support This adds DNS SRV lookups for bootstrapping. This is provided in two forms: 1. When there is only a single hostname with no port. This is called implicit lookup 2. When the scheme `couchbase+dnssrv://` is used. This is an explicit mode and is considered internal to the library. In both cases the input hostname will be selected and attempted for a DNS SRV query. If it succeeds, then the hosts use for the query will be returned. If the query fails, implicit mode will continue, using the hostname as a couchbase node, whereas explicit mode will fail. Explicit mode is useful for debugging the dns srv feauture itself. Currently support depends on either Windows (which works "out of the box") and libbind/libresolv, which come bundled with glibc on both OS X and Linux. This may fail to function on very ancient systems; in which event these routines are stubbed out with no-op equivalents. Change-Id: I0d54b63c1e6cef64e5a09280343e9aba24ed7a80 Reviewed-on: http://review.couchbase.org/46177 Reviewed-by: Brett Lawson <brett19@gmail.com> Tested-by: buildbot <build@couchbase.com> |
/Couchbase_C_Client_v3.0/cmake/ | ||
H A D | config-cmake.h.in | diff 40ff8088 Mon Apr 09 12:18:52 UTC 2018 Guillaume Molleda / Amadeus IT Group <gmolleda@amadeus.com> CCBC-685: Implementation of SCRAM-SHA authentication mechanism Please refer to RFC 5802 for a complete description of the SCRAM-SHA authentication sequence. Basically, the purpose is to base the authentication on exchanges of proofs of identity rather than passwords (in clear text or not). Proofs are hashed using a salted password (the salt being provided by the server) and random nonces (unique to the session), so that only peers knowing the secret password can acknowledge them. The authentication is performed in five steps. Step 1: the client sends the username and his nonce (unique to this session). Step 2: the server returns its nonce (concatenated with the client's nonce), the salt and an iteration count (used when computing the salted password). Step 3: the client computes the client's proof from a combination of the password, the salt, the iteration count and the previous messages (cf RFC 5802 for the complete details). It is sent back to the server. Step 4: the server verifies the validity of the client's proof and generates its own proof based also on the password, the salt, the iteration count and a concatenation of previous messages. This proof is replied to the client as acknowledgement of the authentication. Step 5: the client can verify the validity of the server's proof. The authentication is successful. Three versions of SCRAM-SHA algorithm are currently available: SCRAM-SHA1, SCRAM-SHA256 and SCRAM-SHA512, the difference being on the strength of the hashing. SCRAM-SHA512 is considered as more secure now, so it is used as default by this implementation. This implementation was tested over a Couchbase cluster 4.6.2 (enterprise version). Here is a real example of SCRAM-SHA512 authentication exchange made between the mininal example and the 4.6.2 cluster (captured using tcpdump): Msg 1 (client->server): n,,n=test,r=0c0d2b1a62de9318 Msg 2 (server->client): r=0c0d2b1a62de9318660590ff26368002,s=bGkVWZUpi3OgnkzskW+8YlB7LyFrwETeWI+1seQ+0Y4oP4/FditP6DE/oQ0qdrSKFC4VVlkkSaW34EyhGHzEzA==,i=4096 Msg 3 (client->server): c=biws,r=0c0d2b1a62de9318660590ff26368002,p=f3UTCdYt5pgb5LvkZsdM97crONf7+k8iFZP5/26Z8pIB75I/++L/Vy5FMfAsSDaLNiAo00bzpSz3SFZ9qzR3yw== Msg 4 (server->client): v=i6R3vC0ul0V4XW/jIC1dtayEGPeYBVudp1ay8Ai9R9Mup96B2aP8weU58+C2orgWKPRW0IWGPUMXIW7py/Sfrw== Proofs and salt are encoded in Base64. Other examples can be found in the unit tests (t_scram.cc file). Please note that we rely on OpenSSL for the implementation of SHA, HMAC and PBKDF2 algorithms. If OpenSSL is not linked (or if OpenSSL doesn't implement PBKDF2), then SCRAM-SHA* authentication mecanisms are disabled (only CRAM-MD5 and PLAIN will be used). Change-Id: I4353e791c5e773b8c2fe31b335a05b10d9d499c8 Reviewed-on: http://review.couchbase.org/92497 Tested-by: Build Bot <build@couchbase.com> Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com> diff 40ff8088 Mon Apr 09 12:18:52 UTC 2018 Guillaume Molleda / Amadeus IT Group <gmolleda@amadeus.com> CCBC-685: Implementation of SCRAM-SHA authentication mechanism Please refer to RFC 5802 for a complete description of the SCRAM-SHA authentication sequence. Basically, the purpose is to base the authentication on exchanges of proofs of identity rather than passwords (in clear text or not). Proofs are hashed using a salted password (the salt being provided by the server) and random nonces (unique to the session), so that only peers knowing the secret password can acknowledge them. The authentication is performed in five steps. Step 1: the client sends the username and his nonce (unique to this session). Step 2: the server returns its nonce (concatenated with the client's nonce), the salt and an iteration count (used when computing the salted password). Step 3: the client computes the client's proof from a combination of the password, the salt, the iteration count and the previous messages (cf RFC 5802 for the complete details). It is sent back to the server. Step 4: the server verifies the validity of the client's proof and generates its own proof based also on the password, the salt, the iteration count and a concatenation of previous messages. This proof is replied to the client as acknowledgement of the authentication. Step 5: the client can verify the validity of the server's proof. The authentication is successful. Three versions of SCRAM-SHA algorithm are currently available: SCRAM-SHA1, SCRAM-SHA256 and SCRAM-SHA512, the difference being on the strength of the hashing. SCRAM-SHA512 is considered as more secure now, so it is used as default by this implementation. This implementation was tested over a Couchbase cluster 4.6.2 (enterprise version). Here is a real example of SCRAM-SHA512 authentication exchange made between the mininal example and the 4.6.2 cluster (captured using tcpdump): Msg 1 (client->server): n,,n=test,r=0c0d2b1a62de9318 Msg 2 (server->client): r=0c0d2b1a62de9318660590ff26368002,s=bGkVWZUpi3OgnkzskW+8YlB7LyFrwETeWI+1seQ+0Y4oP4/FditP6DE/oQ0qdrSKFC4VVlkkSaW34EyhGHzEzA==,i=4096 Msg 3 (client->server): c=biws,r=0c0d2b1a62de9318660590ff26368002,p=f3UTCdYt5pgb5LvkZsdM97crONf7+k8iFZP5/26Z8pIB75I/++L/Vy5FMfAsSDaLNiAo00bzpSz3SFZ9qzR3yw== Msg 4 (server->client): v=i6R3vC0ul0V4XW/jIC1dtayEGPeYBVudp1ay8Ai9R9Mup96B2aP8weU58+C2orgWKPRW0IWGPUMXIW7py/Sfrw== Proofs and salt are encoded in Base64. Other examples can be found in the unit tests (t_scram.cc file). Please note that we rely on OpenSSL for the implementation of SHA, HMAC and PBKDF2 algorithms. If OpenSSL is not linked (or if OpenSSL doesn't implement PBKDF2), then SCRAM-SHA* authentication mecanisms are disabled (only CRAM-MD5 and PLAIN will be used). Change-Id: I4353e791c5e773b8c2fe31b335a05b10d9d499c8 Reviewed-on: http://review.couchbase.org/92497 Tested-by: Build Bot <build@couchbase.com> Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com> diff 40ff8088 Mon Apr 09 12:18:52 UTC 2018 Guillaume Molleda / Amadeus IT Group <gmolleda@amadeus.com> CCBC-685: Implementation of SCRAM-SHA authentication mechanism Please refer to RFC 5802 for a complete description of the SCRAM-SHA authentication sequence. Basically, the purpose is to base the authentication on exchanges of proofs of identity rather than passwords (in clear text or not). Proofs are hashed using a salted password (the salt being provided by the server) and random nonces (unique to the session), so that only peers knowing the secret password can acknowledge them. The authentication is performed in five steps. Step 1: the client sends the username and his nonce (unique to this session). Step 2: the server returns its nonce (concatenated with the client's nonce), the salt and an iteration count (used when computing the salted password). Step 3: the client computes the client's proof from a combination of the password, the salt, the iteration count and the previous messages (cf RFC 5802 for the complete details). It is sent back to the server. Step 4: the server verifies the validity of the client's proof and generates its own proof based also on the password, the salt, the iteration count and a concatenation of previous messages. This proof is replied to the client as acknowledgement of the authentication. Step 5: the client can verify the validity of the server's proof. The authentication is successful. Three versions of SCRAM-SHA algorithm are currently available: SCRAM-SHA1, SCRAM-SHA256 and SCRAM-SHA512, the difference being on the strength of the hashing. SCRAM-SHA512 is considered as more secure now, so it is used as default by this implementation. This implementation was tested over a Couchbase cluster 4.6.2 (enterprise version). Here is a real example of SCRAM-SHA512 authentication exchange made between the mininal example and the 4.6.2 cluster (captured using tcpdump): Msg 1 (client->server): n,,n=test,r=0c0d2b1a62de9318 Msg 2 (server->client): r=0c0d2b1a62de9318660590ff26368002,s=bGkVWZUpi3OgnkzskW+8YlB7LyFrwETeWI+1seQ+0Y4oP4/FditP6DE/oQ0qdrSKFC4VVlkkSaW34EyhGHzEzA==,i=4096 Msg 3 (client->server): c=biws,r=0c0d2b1a62de9318660590ff26368002,p=f3UTCdYt5pgb5LvkZsdM97crONf7+k8iFZP5/26Z8pIB75I/++L/Vy5FMfAsSDaLNiAo00bzpSz3SFZ9qzR3yw== Msg 4 (server->client): v=i6R3vC0ul0V4XW/jIC1dtayEGPeYBVudp1ay8Ai9R9Mup96B2aP8weU58+C2orgWKPRW0IWGPUMXIW7py/Sfrw== Proofs and salt are encoded in Base64. Other examples can be found in the unit tests (t_scram.cc file). Please note that we rely on OpenSSL for the implementation of SHA, HMAC and PBKDF2 algorithms. If OpenSSL is not linked (or if OpenSSL doesn't implement PBKDF2), then SCRAM-SHA* authentication mecanisms are disabled (only CRAM-MD5 and PLAIN will be used). Change-Id: I4353e791c5e773b8c2fe31b335a05b10d9d499c8 Reviewed-on: http://review.couchbase.org/92497 Tested-by: Build Bot <build@couchbase.com> Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com> diff 40ff8088 Mon Apr 09 12:18:52 UTC 2018 Guillaume Molleda / Amadeus IT Group <gmolleda@amadeus.com> CCBC-685: Implementation of SCRAM-SHA authentication mechanism Please refer to RFC 5802 for a complete description of the SCRAM-SHA authentication sequence. Basically, the purpose is to base the authentication on exchanges of proofs of identity rather than passwords (in clear text or not). Proofs are hashed using a salted password (the salt being provided by the server) and random nonces (unique to the session), so that only peers knowing the secret password can acknowledge them. The authentication is performed in five steps. Step 1: the client sends the username and his nonce (unique to this session). Step 2: the server returns its nonce (concatenated with the client's nonce), the salt and an iteration count (used when computing the salted password). Step 3: the client computes the client's proof from a combination of the password, the salt, the iteration count and the previous messages (cf RFC 5802 for the complete details). It is sent back to the server. Step 4: the server verifies the validity of the client's proof and generates its own proof based also on the password, the salt, the iteration count and a concatenation of previous messages. This proof is replied to the client as acknowledgement of the authentication. Step 5: the client can verify the validity of the server's proof. The authentication is successful. Three versions of SCRAM-SHA algorithm are currently available: SCRAM-SHA1, SCRAM-SHA256 and SCRAM-SHA512, the difference being on the strength of the hashing. SCRAM-SHA512 is considered as more secure now, so it is used as default by this implementation. This implementation was tested over a Couchbase cluster 4.6.2 (enterprise version). Here is a real example of SCRAM-SHA512 authentication exchange made between the mininal example and the 4.6.2 cluster (captured using tcpdump): Msg 1 (client->server): n,,n=test,r=0c0d2b1a62de9318 Msg 2 (server->client): r=0c0d2b1a62de9318660590ff26368002,s=bGkVWZUpi3OgnkzskW+8YlB7LyFrwETeWI+1seQ+0Y4oP4/FditP6DE/oQ0qdrSKFC4VVlkkSaW34EyhGHzEzA==,i=4096 Msg 3 (client->server): c=biws,r=0c0d2b1a62de9318660590ff26368002,p=f3UTCdYt5pgb5LvkZsdM97crONf7+k8iFZP5/26Z8pIB75I/++L/Vy5FMfAsSDaLNiAo00bzpSz3SFZ9qzR3yw== Msg 4 (server->client): v=i6R3vC0ul0V4XW/jIC1dtayEGPeYBVudp1ay8Ai9R9Mup96B2aP8weU58+C2orgWKPRW0IWGPUMXIW7py/Sfrw== Proofs and salt are encoded in Base64. Other examples can be found in the unit tests (t_scram.cc file). Please note that we rely on OpenSSL for the implementation of SHA, HMAC and PBKDF2 algorithms. If OpenSSL is not linked (or if OpenSSL doesn't implement PBKDF2), then SCRAM-SHA* authentication mecanisms are disabled (only CRAM-MD5 and PLAIN will be used). Change-Id: I4353e791c5e773b8c2fe31b335a05b10d9d499c8 Reviewed-on: http://review.couchbase.org/92497 Tested-by: Build Bot <build@couchbase.com> Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com> diff 0fb123d8 Fri Jan 30 23:35:02 UTC 2015 Mark Nunberg <mnunberg@haskalah.org> CCBC-566: DNS SRV support This adds DNS SRV lookups for bootstrapping. This is provided in two forms: 1. When there is only a single hostname with no port. This is called implicit lookup 2. When the scheme `couchbase+dnssrv://` is used. This is an explicit mode and is considered internal to the library. In both cases the input hostname will be selected and attempted for a DNS SRV query. If it succeeds, then the hosts use for the query will be returned. If the query fails, implicit mode will continue, using the hostname as a couchbase node, whereas explicit mode will fail. Explicit mode is useful for debugging the dns srv feauture itself. Currently support depends on either Windows (which works "out of the box") and libbind/libresolv, which come bundled with glibc on both OS X and Linux. This may fail to function on very ancient systems; in which event these routines are stubbed out with no-op equivalents. Change-Id: I0d54b63c1e6cef64e5a09280343e9aba24ed7a80 Reviewed-on: http://review.couchbase.org/46177 Reviewed-by: Brett Lawson <brett19@gmail.com> Tested-by: buildbot <build@couchbase.com> diff 0fb123d8 Fri Jan 30 23:35:02 UTC 2015 Mark Nunberg <mnunberg@haskalah.org> CCBC-566: DNS SRV support This adds DNS SRV lookups for bootstrapping. This is provided in two forms: 1. When there is only a single hostname with no port. This is called implicit lookup 2. When the scheme `couchbase+dnssrv://` is used. This is an explicit mode and is considered internal to the library. In both cases the input hostname will be selected and attempted for a DNS SRV query. If it succeeds, then the hosts use for the query will be returned. If the query fails, implicit mode will continue, using the hostname as a couchbase node, whereas explicit mode will fail. Explicit mode is useful for debugging the dns srv feauture itself. Currently support depends on either Windows (which works "out of the box") and libbind/libresolv, which come bundled with glibc on both OS X and Linux. This may fail to function on very ancient systems; in which event these routines are stubbed out with no-op equivalents. Change-Id: I0d54b63c1e6cef64e5a09280343e9aba24ed7a80 Reviewed-on: http://review.couchbase.org/46177 Reviewed-by: Brett Lawson <brett19@gmail.com> Tested-by: buildbot <build@couchbase.com> |
H A D | source_files.cmake | diff 0b67f157 Wed Sep 04 14:20:37 UTC 2019 Sergey Avseyev <sergey.avseyev@gmail.com> Remove CAS durability polling Change-Id: I114eceff5918262a9ee5eaebf245afd69629853f Reviewed-on: http://review.couchbase.org/114246 Reviewed-by: Brett Lawson <brett19@gmail.com> Tested-by: Build Bot <build@couchbase.com> diff 0fb123d8 Fri Jan 30 23:35:02 UTC 2015 Mark Nunberg <mnunberg@haskalah.org> CCBC-566: DNS SRV support This adds DNS SRV lookups for bootstrapping. This is provided in two forms: 1. When there is only a single hostname with no port. This is called implicit lookup 2. When the scheme `couchbase+dnssrv://` is used. This is an explicit mode and is considered internal to the library. In both cases the input hostname will be selected and attempted for a DNS SRV query. If it succeeds, then the hosts use for the query will be returned. If the query fails, implicit mode will continue, using the hostname as a couchbase node, whereas explicit mode will fail. Explicit mode is useful for debugging the dns srv feauture itself. Currently support depends on either Windows (which works "out of the box") and libbind/libresolv, which come bundled with glibc on both OS X and Linux. This may fail to function on very ancient systems; in which event these routines are stubbed out with no-op equivalents. Change-Id: I0d54b63c1e6cef64e5a09280343e9aba24ed7a80 Reviewed-on: http://review.couchbase.org/46177 Reviewed-by: Brett Lawson <brett19@gmail.com> Tested-by: buildbot <build@couchbase.com> diff 0fb123d8 Fri Jan 30 23:35:02 UTC 2015 Mark Nunberg <mnunberg@haskalah.org> CCBC-566: DNS SRV support This adds DNS SRV lookups for bootstrapping. This is provided in two forms: 1. When there is only a single hostname with no port. This is called implicit lookup 2. When the scheme `couchbase+dnssrv://` is used. This is an explicit mode and is considered internal to the library. In both cases the input hostname will be selected and attempted for a DNS SRV query. If it succeeds, then the hosts use for the query will be returned. If the query fails, implicit mode will continue, using the hostname as a couchbase node, whereas explicit mode will fail. Explicit mode is useful for debugging the dns srv feauture itself. Currently support depends on either Windows (which works "out of the box") and libbind/libresolv, which come bundled with glibc on both OS X and Linux. This may fail to function on very ancient systems; in which event these routines are stubbed out with no-op equivalents. Change-Id: I0d54b63c1e6cef64e5a09280343e9aba24ed7a80 Reviewed-on: http://review.couchbase.org/46177 Reviewed-by: Brett Lawson <brett19@gmail.com> Tested-by: buildbot <build@couchbase.com> |
/Couchbase_C_Client_v3.0/ | ||
H A D | CMakeLists.txt | diff 31bd2afa Mon Jul 19 13:06:29 UTC 2021 Sergey Avseyev <sergey.avseyev@gmail.com> Update release meta for 3.2.0 Change-Id: I0af9154473a5ba2fa30326475ff9b39ff27d3d94 Reviewed-on: http://review.couchbase.org/c/libcouchbase/+/157772 Tested-by: Build Bot <build@couchbase.com> Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com> diff ed8b57e7 Wed Mar 03 07:31:38 UTC 2021 Sergey Avseyev <sergey.avseyev@gmail.com> Update release meta for 3.1.0 Change-Id: I55e7e823d2a1ae4a47be86bc477f54b7b3b50e5a Reviewed-on: http://review.couchbase.org/c/libcouchbase/+/147552 Tested-by: Build Bot <build@couchbase.com> Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com> diff 0fb5c84a Thu Dec 20 10:55:05 UTC 2018 Sergey Avseyev <sergey.avseyev@gmail.com> Fix subdoc tests against real cluster Change-Id: Ie79a789054290185793d82a06429e832c0110aab Reviewed-on: http://review.couchbase.org/103083 Tested-by: Build Bot <build@couchbase.com> Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com> diff 40ff8088 Mon Apr 09 12:18:52 UTC 2018 Guillaume Molleda / Amadeus IT Group <gmolleda@amadeus.com> CCBC-685: Implementation of SCRAM-SHA authentication mechanism Please refer to RFC 5802 for a complete description of the SCRAM-SHA authentication sequence. Basically, the purpose is to base the authentication on exchanges of proofs of identity rather than passwords (in clear text or not). Proofs are hashed using a salted password (the salt being provided by the server) and random nonces (unique to the session), so that only peers knowing the secret password can acknowledge them. The authentication is performed in five steps. Step 1: the client sends the username and his nonce (unique to this session). Step 2: the server returns its nonce (concatenated with the client's nonce), the salt and an iteration count (used when computing the salted password). Step 3: the client computes the client's proof from a combination of the password, the salt, the iteration count and the previous messages (cf RFC 5802 for the complete details). It is sent back to the server. Step 4: the server verifies the validity of the client's proof and generates its own proof based also on the password, the salt, the iteration count and a concatenation of previous messages. This proof is replied to the client as acknowledgement of the authentication. Step 5: the client can verify the validity of the server's proof. The authentication is successful. Three versions of SCRAM-SHA algorithm are currently available: SCRAM-SHA1, SCRAM-SHA256 and SCRAM-SHA512, the difference being on the strength of the hashing. SCRAM-SHA512 is considered as more secure now, so it is used as default by this implementation. This implementation was tested over a Couchbase cluster 4.6.2 (enterprise version). Here is a real example of SCRAM-SHA512 authentication exchange made between the mininal example and the 4.6.2 cluster (captured using tcpdump): Msg 1 (client->server): n,,n=test,r=0c0d2b1a62de9318 Msg 2 (server->client): r=0c0d2b1a62de9318660590ff26368002,s=bGkVWZUpi3OgnkzskW+8YlB7LyFrwETeWI+1seQ+0Y4oP4/FditP6DE/oQ0qdrSKFC4VVlkkSaW34EyhGHzEzA==,i=4096 Msg 3 (client->server): c=biws,r=0c0d2b1a62de9318660590ff26368002,p=f3UTCdYt5pgb5LvkZsdM97crONf7+k8iFZP5/26Z8pIB75I/++L/Vy5FMfAsSDaLNiAo00bzpSz3SFZ9qzR3yw== Msg 4 (server->client): v=i6R3vC0ul0V4XW/jIC1dtayEGPeYBVudp1ay8Ai9R9Mup96B2aP8weU58+C2orgWKPRW0IWGPUMXIW7py/Sfrw== Proofs and salt are encoded in Base64. Other examples can be found in the unit tests (t_scram.cc file). Please note that we rely on OpenSSL for the implementation of SHA, HMAC and PBKDF2 algorithms. If OpenSSL is not linked (or if OpenSSL doesn't implement PBKDF2), then SCRAM-SHA* authentication mecanisms are disabled (only CRAM-MD5 and PLAIN will be used). Change-Id: I4353e791c5e773b8c2fe31b335a05b10d9d499c8 Reviewed-on: http://review.couchbase.org/92497 Tested-by: Build Bot <build@couchbase.com> Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com> diff 40ff8088 Mon Apr 09 12:18:52 UTC 2018 Guillaume Molleda / Amadeus IT Group <gmolleda@amadeus.com> CCBC-685: Implementation of SCRAM-SHA authentication mechanism Please refer to RFC 5802 for a complete description of the SCRAM-SHA authentication sequence. Basically, the purpose is to base the authentication on exchanges of proofs of identity rather than passwords (in clear text or not). Proofs are hashed using a salted password (the salt being provided by the server) and random nonces (unique to the session), so that only peers knowing the secret password can acknowledge them. The authentication is performed in five steps. Step 1: the client sends the username and his nonce (unique to this session). Step 2: the server returns its nonce (concatenated with the client's nonce), the salt and an iteration count (used when computing the salted password). Step 3: the client computes the client's proof from a combination of the password, the salt, the iteration count and the previous messages (cf RFC 5802 for the complete details). It is sent back to the server. Step 4: the server verifies the validity of the client's proof and generates its own proof based also on the password, the salt, the iteration count and a concatenation of previous messages. This proof is replied to the client as acknowledgement of the authentication. Step 5: the client can verify the validity of the server's proof. The authentication is successful. Three versions of SCRAM-SHA algorithm are currently available: SCRAM-SHA1, SCRAM-SHA256 and SCRAM-SHA512, the difference being on the strength of the hashing. SCRAM-SHA512 is considered as more secure now, so it is used as default by this implementation. This implementation was tested over a Couchbase cluster 4.6.2 (enterprise version). Here is a real example of SCRAM-SHA512 authentication exchange made between the mininal example and the 4.6.2 cluster (captured using tcpdump): Msg 1 (client->server): n,,n=test,r=0c0d2b1a62de9318 Msg 2 (server->client): r=0c0d2b1a62de9318660590ff26368002,s=bGkVWZUpi3OgnkzskW+8YlB7LyFrwETeWI+1seQ+0Y4oP4/FditP6DE/oQ0qdrSKFC4VVlkkSaW34EyhGHzEzA==,i=4096 Msg 3 (client->server): c=biws,r=0c0d2b1a62de9318660590ff26368002,p=f3UTCdYt5pgb5LvkZsdM97crONf7+k8iFZP5/26Z8pIB75I/++L/Vy5FMfAsSDaLNiAo00bzpSz3SFZ9qzR3yw== Msg 4 (server->client): v=i6R3vC0ul0V4XW/jIC1dtayEGPeYBVudp1ay8Ai9R9Mup96B2aP8weU58+C2orgWKPRW0IWGPUMXIW7py/Sfrw== Proofs and salt are encoded in Base64. Other examples can be found in the unit tests (t_scram.cc file). Please note that we rely on OpenSSL for the implementation of SHA, HMAC and PBKDF2 algorithms. If OpenSSL is not linked (or if OpenSSL doesn't implement PBKDF2), then SCRAM-SHA* authentication mecanisms are disabled (only CRAM-MD5 and PLAIN will be used). Change-Id: I4353e791c5e773b8c2fe31b335a05b10d9d499c8 Reviewed-on: http://review.couchbase.org/92497 Tested-by: Build Bot <build@couchbase.com> Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com> diff 40ff8088 Mon Apr 09 12:18:52 UTC 2018 Guillaume Molleda / Amadeus IT Group <gmolleda@amadeus.com> CCBC-685: Implementation of SCRAM-SHA authentication mechanism Please refer to RFC 5802 for a complete description of the SCRAM-SHA authentication sequence. Basically, the purpose is to base the authentication on exchanges of proofs of identity rather than passwords (in clear text or not). Proofs are hashed using a salted password (the salt being provided by the server) and random nonces (unique to the session), so that only peers knowing the secret password can acknowledge them. The authentication is performed in five steps. Step 1: the client sends the username and his nonce (unique to this session). Step 2: the server returns its nonce (concatenated with the client's nonce), the salt and an iteration count (used when computing the salted password). Step 3: the client computes the client's proof from a combination of the password, the salt, the iteration count and the previous messages (cf RFC 5802 for the complete details). It is sent back to the server. Step 4: the server verifies the validity of the client's proof and generates its own proof based also on the password, the salt, the iteration count and a concatenation of previous messages. This proof is replied to the client as acknowledgement of the authentication. Step 5: the client can verify the validity of the server's proof. The authentication is successful. Three versions of SCRAM-SHA algorithm are currently available: SCRAM-SHA1, SCRAM-SHA256 and SCRAM-SHA512, the difference being on the strength of the hashing. SCRAM-SHA512 is considered as more secure now, so it is used as default by this implementation. This implementation was tested over a Couchbase cluster 4.6.2 (enterprise version). Here is a real example of SCRAM-SHA512 authentication exchange made between the mininal example and the 4.6.2 cluster (captured using tcpdump): Msg 1 (client->server): n,,n=test,r=0c0d2b1a62de9318 Msg 2 (server->client): r=0c0d2b1a62de9318660590ff26368002,s=bGkVWZUpi3OgnkzskW+8YlB7LyFrwETeWI+1seQ+0Y4oP4/FditP6DE/oQ0qdrSKFC4VVlkkSaW34EyhGHzEzA==,i=4096 Msg 3 (client->server): c=biws,r=0c0d2b1a62de9318660590ff26368002,p=f3UTCdYt5pgb5LvkZsdM97crONf7+k8iFZP5/26Z8pIB75I/++L/Vy5FMfAsSDaLNiAo00bzpSz3SFZ9qzR3yw== Msg 4 (server->client): v=i6R3vC0ul0V4XW/jIC1dtayEGPeYBVudp1ay8Ai9R9Mup96B2aP8weU58+C2orgWKPRW0IWGPUMXIW7py/Sfrw== Proofs and salt are encoded in Base64. Other examples can be found in the unit tests (t_scram.cc file). Please note that we rely on OpenSSL for the implementation of SHA, HMAC and PBKDF2 algorithms. If OpenSSL is not linked (or if OpenSSL doesn't implement PBKDF2), then SCRAM-SHA* authentication mecanisms are disabled (only CRAM-MD5 and PLAIN will be used). Change-Id: I4353e791c5e773b8c2fe31b335a05b10d9d499c8 Reviewed-on: http://review.couchbase.org/92497 Tested-by: Build Bot <build@couchbase.com> Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com> diff 40ff8088 Mon Apr 09 12:18:52 UTC 2018 Guillaume Molleda / Amadeus IT Group <gmolleda@amadeus.com> CCBC-685: Implementation of SCRAM-SHA authentication mechanism Please refer to RFC 5802 for a complete description of the SCRAM-SHA authentication sequence. Basically, the purpose is to base the authentication on exchanges of proofs of identity rather than passwords (in clear text or not). Proofs are hashed using a salted password (the salt being provided by the server) and random nonces (unique to the session), so that only peers knowing the secret password can acknowledge them. The authentication is performed in five steps. Step 1: the client sends the username and his nonce (unique to this session). Step 2: the server returns its nonce (concatenated with the client's nonce), the salt and an iteration count (used when computing the salted password). Step 3: the client computes the client's proof from a combination of the password, the salt, the iteration count and the previous messages (cf RFC 5802 for the complete details). It is sent back to the server. Step 4: the server verifies the validity of the client's proof and generates its own proof based also on the password, the salt, the iteration count and a concatenation of previous messages. This proof is replied to the client as acknowledgement of the authentication. Step 5: the client can verify the validity of the server's proof. The authentication is successful. Three versions of SCRAM-SHA algorithm are currently available: SCRAM-SHA1, SCRAM-SHA256 and SCRAM-SHA512, the difference being on the strength of the hashing. SCRAM-SHA512 is considered as more secure now, so it is used as default by this implementation. This implementation was tested over a Couchbase cluster 4.6.2 (enterprise version). Here is a real example of SCRAM-SHA512 authentication exchange made between the mininal example and the 4.6.2 cluster (captured using tcpdump): Msg 1 (client->server): n,,n=test,r=0c0d2b1a62de9318 Msg 2 (server->client): r=0c0d2b1a62de9318660590ff26368002,s=bGkVWZUpi3OgnkzskW+8YlB7LyFrwETeWI+1seQ+0Y4oP4/FditP6DE/oQ0qdrSKFC4VVlkkSaW34EyhGHzEzA==,i=4096 Msg 3 (client->server): c=biws,r=0c0d2b1a62de9318660590ff26368002,p=f3UTCdYt5pgb5LvkZsdM97crONf7+k8iFZP5/26Z8pIB75I/++L/Vy5FMfAsSDaLNiAo00bzpSz3SFZ9qzR3yw== Msg 4 (server->client): v=i6R3vC0ul0V4XW/jIC1dtayEGPeYBVudp1ay8Ai9R9Mup96B2aP8weU58+C2orgWKPRW0IWGPUMXIW7py/Sfrw== Proofs and salt are encoded in Base64. Other examples can be found in the unit tests (t_scram.cc file). Please note that we rely on OpenSSL for the implementation of SHA, HMAC and PBKDF2 algorithms. If OpenSSL is not linked (or if OpenSSL doesn't implement PBKDF2), then SCRAM-SHA* authentication mecanisms are disabled (only CRAM-MD5 and PLAIN will be used). Change-Id: I4353e791c5e773b8c2fe31b335a05b10d9d499c8 Reviewed-on: http://review.couchbase.org/92497 Tested-by: Build Bot <build@couchbase.com> Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com> diff 0dc3fd13 Fri Sep 15 08:41:11 UTC 2017 Sergey Avseyev <sergey.avseyev@gmail.com> Allow to defer rebalance for node failover Change-Id: Ibe7e357d6de95ab0ffef9623dce608d8e5f58898 Reviewed-on: http://review.couchbase.org/83424 Tested-by: Build Bot <build@couchbase.com> Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com> diff 7c4988d0 Tue May 02 22:33:01 UTC 2017 Mark Nunberg <mnunberg@haskalah.org> CCBC-774: Update subdoc protocol for Spock - This adds new doc-level flags, manifested as `LCB_CMDSUBDOC_F_` ... - Allow full-doc get/set with `LCB_SDCMD_SET_FULLDOC` and `LCB_SDCMD_GET_FULLDOC` - Update to CouchbaseMock 1.5.0: This also required a minor change to add a new attribute to the list of known error map attributes. Otherwise it results in a parse failure. Change-Id: I34f5c2a0180204133690d5a73638f85c78dfffa5 Reviewed-on: http://review.couchbase.org/77376 Tested-by: Build Bot <build@couchbase.com> Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com> diff 0fb123d8 Fri Jan 30 23:35:02 UTC 2015 Mark Nunberg <mnunberg@haskalah.org> CCBC-566: DNS SRV support This adds DNS SRV lookups for bootstrapping. This is provided in two forms: 1. When there is only a single hostname with no port. This is called implicit lookup 2. When the scheme `couchbase+dnssrv://` is used. This is an explicit mode and is considered internal to the library. In both cases the input hostname will be selected and attempted for a DNS SRV query. If it succeeds, then the hosts use for the query will be returned. If the query fails, implicit mode will continue, using the hostname as a couchbase node, whereas explicit mode will fail. Explicit mode is useful for debugging the dns srv feauture itself. Currently support depends on either Windows (which works "out of the box") and libbind/libresolv, which come bundled with glibc on both OS X and Linux. This may fail to function on very ancient systems; in which event these routines are stubbed out with no-op equivalents. Change-Id: I0d54b63c1e6cef64e5a09280343e9aba24ed7a80 Reviewed-on: http://review.couchbase.org/46177 Reviewed-by: Brett Lawson <brett19@gmail.com> Tested-by: buildbot <build@couchbase.com> diff 0fb123d8 Fri Jan 30 23:35:02 UTC 2015 Mark Nunberg <mnunberg@haskalah.org> CCBC-566: DNS SRV support This adds DNS SRV lookups for bootstrapping. This is provided in two forms: 1. When there is only a single hostname with no port. This is called implicit lookup 2. When the scheme `couchbase+dnssrv://` is used. This is an explicit mode and is considered internal to the library. In both cases the input hostname will be selected and attempted for a DNS SRV query. If it succeeds, then the hosts use for the query will be returned. If the query fails, implicit mode will continue, using the hostname as a couchbase node, whereas explicit mode will fail. Explicit mode is useful for debugging the dns srv feauture itself. Currently support depends on either Windows (which works "out of the box") and libbind/libresolv, which come bundled with glibc on both OS X and Linux. This may fail to function on very ancient systems; in which event these routines are stubbed out with no-op equivalents. Change-Id: I0d54b63c1e6cef64e5a09280343e9aba24ed7a80 Reviewed-on: http://review.couchbase.org/46177 Reviewed-by: Brett Lawson <brett19@gmail.com> Tested-by: buildbot <build@couchbase.com> |
/Couchbase_C_Client_v3.0/include/libcouchbase/ | ||
H A D | couchbase.h | diff 0c4213b9 Wed Jul 21 17:36:20 UTC 2021 Sergey Avseyev <sergey.avseyev@gmail.com> CCBC-1429: fixed positional parameters for query/analtyics * reverts behaviour `lcb_cmdquery_positional_param` and `lcb_cmdanalytics_positional_param` to append single JSON-encoded value to arguments array. * introduces new functions `lcb_cmdquery_positional_params` and `lcb_cmdanalytics_positional_params` that accept all positional arguments at once as JSON-encoded array. * document, that old functions will emit compiler warning since 3.3.0 release and will be removed later. Change-Id: Ia49c74e096682378c00ed4bf37b978a4514ac3fa Reviewed-on: http://review.couchbase.org/c/libcouchbase/+/158001 Tested-by: Build Bot <build@couchbase.com> Reviewed-by: Brett Lawson <brett19@gmail.com> diff 0c4213b9 Wed Jul 21 17:36:20 UTC 2021 Sergey Avseyev <sergey.avseyev@gmail.com> CCBC-1429: fixed positional parameters for query/analtyics * reverts behaviour `lcb_cmdquery_positional_param` and `lcb_cmdanalytics_positional_param` to append single JSON-encoded value to arguments array. * introduces new functions `lcb_cmdquery_positional_params` and `lcb_cmdanalytics_positional_params` that accept all positional arguments at once as JSON-encoded array. * document, that old functions will emit compiler warning since 3.3.0 release and will be removed later. Change-Id: Ia49c74e096682378c00ed4bf37b978a4514ac3fa Reviewed-on: http://review.couchbase.org/c/libcouchbase/+/158001 Tested-by: Build Bot <build@couchbase.com> Reviewed-by: Brett Lawson <brett19@gmail.com> diff 5fb53793 Tue Nov 19 15:23:56 UTC 2019 Sergey Avseyev <sergey.avseyev@gmail.com> CCBC-1123: migrate exists function to GET_META(0xa0) Change-Id: I590d5583ca9112b395ca84ff8308b70453a16972 Reviewed-on: http://review.couchbase.org/118140 Reviewed-by: Ellis Breen <ellis.breen@couchbase.com> Tested-by: Build Bot <build@couchbase.com> Reviewed-by: Brett Lawson <brett19@gmail.com> diff 0b0310e1 Wed Apr 03 07:33:33 UTC 2019 Sergey Avseyev <sergey.avseyev@gmail.com> Reformat sources with clang-format Change-Id: I6d9cdc0ca66b7cd7b75a5e064b64fe0adbc0b106 Reviewed-on: http://review.couchbase.org/107219 Tested-by: Build Bot <build@couchbase.com> Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com> diff 0e6ccebf Mon Dec 11 20:53:22 UTC 2017 Sergey Avseyev <sergey.avseyev@gmail.com> CCBC-880: implement SSL client certificate authentication Change-Id: I796e21454b4feac3de934c193fc8d7db66a1e710 Reviewed-on: http://review.couchbase.org/87015 Reviewed-by: Ellis Breen <ellis.breen@couchbase.com> Tested-by: Build Bot <build@couchbase.com> diff 0fb123d8 Fri Jan 30 23:35:02 UTC 2015 Mark Nunberg <mnunberg@haskalah.org> CCBC-566: DNS SRV support This adds DNS SRV lookups for bootstrapping. This is provided in two forms: 1. When there is only a single hostname with no port. This is called implicit lookup 2. When the scheme `couchbase+dnssrv://` is used. This is an explicit mode and is considered internal to the library. In both cases the input hostname will be selected and attempted for a DNS SRV query. If it succeeds, then the hosts use for the query will be returned. If the query fails, implicit mode will continue, using the hostname as a couchbase node, whereas explicit mode will fail. Explicit mode is useful for debugging the dns srv feauture itself. Currently support depends on either Windows (which works "out of the box") and libbind/libresolv, which come bundled with glibc on both OS X and Linux. This may fail to function on very ancient systems; in which event these routines are stubbed out with no-op equivalents. Change-Id: I0d54b63c1e6cef64e5a09280343e9aba24ed7a80 Reviewed-on: http://review.couchbase.org/46177 Reviewed-by: Brett Lawson <brett19@gmail.com> Tested-by: buildbot <build@couchbase.com> diff 0fb123d8 Fri Jan 30 23:35:02 UTC 2015 Mark Nunberg <mnunberg@haskalah.org> CCBC-566: DNS SRV support This adds DNS SRV lookups for bootstrapping. This is provided in two forms: 1. When there is only a single hostname with no port. This is called implicit lookup 2. When the scheme `couchbase+dnssrv://` is used. This is an explicit mode and is considered internal to the library. In both cases the input hostname will be selected and attempted for a DNS SRV query. If it succeeds, then the hosts use for the query will be returned. If the query fails, implicit mode will continue, using the hostname as a couchbase node, whereas explicit mode will fail. Explicit mode is useful for debugging the dns srv feauture itself. Currently support depends on either Windows (which works "out of the box") and libbind/libresolv, which come bundled with glibc on both OS X and Linux. This may fail to function on very ancient systems; in which event these routines are stubbed out with no-op equivalents. Change-Id: I0d54b63c1e6cef64e5a09280343e9aba24ed7a80 Reviewed-on: http://review.couchbase.org/46177 Reviewed-by: Brett Lawson <brett19@gmail.com> Tested-by: buildbot <build@couchbase.com> diff 810ae36b Tue Feb 02 20:31:20 UTC 2016 Mark Nunberg <mnunberg@haskalah.org> CCBC-667: Allow get-and-touch with an expiry of 0 Change-Id: I03f9a890a7e7cfff6db160d6cb21a945cdc74189 Reviewed-on: http://review.couchbase.org/59479 Reviewed-by: Subhashni Balakrishnan <b.subhashni@gmail.com> Tested-by: Mark Nunberg <mark.nunberg@couchbase.com> diff 0ffba2c0 Fri Jul 17 16:19:12 UTC 2015 Mark Nunberg <mnunberg@haskalah.org> CCBC-624: Allow histogram for n1qlback (1/3) This change decouples the histogram information from the instance itself, allowing external consumers. Change-Id: I38ae7980da7433df555c1687fb73f76c6b69abad Reviewed-on: http://review.couchbase.org/53340 Tested-by: buildbot <build@couchbase.com> Reviewed-by: Subhashni Balakrishnan <b.subhashni@gmail.com> diff 13b0e7fe Sat Nov 08 16:48:42 UTC 2014 Mark Nunberg <mnunberg@haskalah.org> Undocument internal legacy structures from headers - make some older definitions fit in a single line, because they are no longer used internally and are intended for back compat with older code. - Undocument older `lcb_create_st` member structures - Mode `lcb_configuration_callback` stuff to the `deprecated.h` file and deprecate the callback accessors. These functions should not be used in newer code - rather the alternative `lcb_set_bootstrap_callback` should be used. - Undocument internal `IOCREATEOPTS` members. Code should either explicitly create one from external code, or use the builtin struct variant. We should really move a lot of these definitions outside of the header files, but we need to be compatible with code as early as 2.0.0 (two years ago). Change-Id: I75619795e7d4a16248465dd580c3d43d6228f8e6 Reviewed-on: http://review.couchbase.org/43025 Tested-by: Mark Nunberg <mnunberg@haskalah.org> Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com> |
Completed in 239 milliseconds