History log of /6.6.0/kv_engine/daemon/connection.cc (Results 1 - 25 of 284)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v7.0.2, v6.6.3, v7.0.1, v7.0.0, v6.6.2, v6.5.2, v6.6.1, v6.0.5, v6.6.0
# 30f89a8d 20-May-2020 Trond Norbye <trond.norbye@gmail.com>

MB-33812: Add audit event when a session is terminated

Add an audit event when a client connection is shut
down. The event includes a textual description
containing the reason the co

MB-33812: Add audit event when a session is terminated

Add an audit event when a client connection is shut
down. The event includes a textual description
containing the reason the connection was closed.

{
"description": "Session to the cluster has terminated",
"id": 20493,
"name": "session terminated",
"peername": "172.17.0.1:58376",
"real_userid": {
"domain": "local",
"user": "Administrator"
},
"reason_for_termination": "client closed connection",
"sockname": "172.17.0.2:11210",
"timestamp": "2020-05-20T11:57:29.430262Z"
}

{
"description": "Session to the cluster has terminated",
"id": 20493,
"name": "session terminated",
"peername": "172.17.0.1:58492",
"real_userid": {
"domain": "local",
"user": "Administrator"
},
"reason_for_termination": "XError not enabled",
"sockname": "172.17.0.2:11210",
"timestamp": "2020-05-20T12:01:40.031630Z"
}

Change-Id: I0075c58e2f023ce1cbbb5d2685c048da22af1c11
Reviewed-on: http://review.couchbase.org/c/kv_engine/+/128604
Well-Formed: Build Bot <build@couchbase.com>
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Daniel Owen <owend@couchbase.com>

show more ...


# c3663847 20-Apr-2020 Paolo Cocchi <paolo.cocchi@couchbase.com>

MB-37374: Add new IncludeDeletedUserXattrs flag at DCP_OPEN

The flag is used at DCP_OPEN(Producer) to enable the related feature.
Ignored at DCP_OPEN(Consumer).

Change-Id: I1e06

MB-37374: Add new IncludeDeletedUserXattrs flag at DCP_OPEN

The flag is used at DCP_OPEN(Producer) to enable the related feature.
Ignored at DCP_OPEN(Consumer).

Change-Id: I1e06f230e0be9c248a61d66db8b50d232848177b
Reviewed-on: http://review.couchbase.org/c/kv_engine/+/126116
Well-Formed: Build Bot <build@couchbase.com>
Reviewed-by: Dave Rigby <daver@couchbase.com>
Tested-by: Build Bot <build@couchbase.com>

show more ...


Revision tags: v6.5.1, v6.0.4, v6.5.0
# cdfa195f 25-Nov-2019 Jim Walker <jim@couchbase.com>

MB-36948: Update dcp.h marker() to take maxVisibleSeqno

dcp.h has the API signature for transmitting a DCP snapshot, update this
to include the optional maxVisibleSeqno.

Change-

MB-36948: Update dcp.h marker() to take maxVisibleSeqno

dcp.h has the API signature for transmitting a DCP snapshot, update this
to include the optional maxVisibleSeqno.

Change-Id: I8ecfb324d4bad30354e715cf5d1673a109a2cc4a
Reviewed-on: http://review.couchbase.org/118459
Well-Formed: Build Bot <build@couchbase.com>
Reviewed-by: Paolo Cocchi <paolo.cocchi@couchbase.com>
Tested-by: Jim Walker <jim@couchbase.com>

show more ...


# 8d8ad4cc 22-Nov-2019 Jim Walker <jim@couchbase.com>

MB-37013: Update DcpSnapShotMarker V2 to allow for an extra seqno

To address MB-36948 a new seqno is required in the snapshot marker.

This commit redefines the V2 format so that the

MB-37013: Update DcpSnapShotMarker V2 to allow for an extra seqno

To address MB-36948 a new seqno is required in the snapshot marker.

This commit redefines the V2 format so that the V2 extras is a single
version field (1 byte). The 1 byte version field is used to describe how
the packet is to be decoded, in this MB one V2 encoding is created.

V2.0: The 'value' stores all of the snapshot marker data.
* start (u64)
* end (u64)
* flags (u32)
* maxVisibleSeqno (u64)
* highCompletedSeqno (u64)

With this commit only the V1 and V2.0 encodings are transmitted, but the
V2.0 encoding is only currently transmitted for snapshots with the disk
flag set (and when a sync write has occurred in the vbucket). Because
there is no path yet for the DcpProducer to push down the
maxVisibleSeqno, with this commit V2.0 always transmits 0 for the
maxVisibleSeqno.

On the receipt of a V2.0 message, this patch does tunnel the
maxVisibleSeqno up to KV-engine DCP, this is so the consumer can
calculate the correct number of bytes for buffer acknowledgement.

Note on removal of the following from dcp_snapshot_marker_executor.cc

// HCS should never be sent as 0 or a pre-condition will throw in
// the replicas flusher
if (v2Payload->getHighCompletedSeqno() == 0) {
// Not success so just disconnect
connection.setState(StateMachine::State::closing);
return;
}

This disconnect clause is no longer required because analysis of the
ActiveStream::markDiskSnapshot shows that it would never push down a 0
HCS to the Connection::marker send code.

Extended testing of the committed patch was performed using a multi
node cluster and various failover/rebalance steps to check the
disk-snapshot with the v2.0 encoding was transmitted and successfully
received.

Note: further testing was performed where the Connection::marker local
'maxVisibleSeqno' was initialised to a value to confirm that if all
snapshots used the V2.0 encoding, there is no issue.

Change-Id: I886503d6353d01b284b04af730d581f6be6784c9
Reviewed-on: http://review.couchbase.org/118387
Well-Formed: Build Bot <build@couchbase.com>
Reviewed-by: Paolo Cocchi <paolo.cocchi@couchbase.com>
Reviewed-by: James Harrison <james.harrison@couchbase.com>
Tested-by: Build Bot <build@couchbase.com>

show more ...


# 960c5c7b 10-Oct-2019 Trond Norbye <trond.norbye@gmail.com>

MB-36418: Revert "MB-36028: Flush the SSL socket more aggressively"

This caused a throughput decrease in YCSB Workload E

This reverts commit 79a67213e7278b15cc3429d7eb2546a4d2b8607e

MB-36418: Revert "MB-36028: Flush the SSL socket more aggressively"

This caused a throughput decrease in YCSB Workload E

This reverts commit 79a67213e7278b15cc3429d7eb2546a4d2b8607e.

Change-Id: I067345b56518e92cc76dd0bb318bb2c31d334912
Reviewed-on: http://review.couchbase.org/116206
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Dave Rigby <daver@couchbase.com>

show more ...


# 79a67213 27-Sep-2019 Trond Norbye <trond.norbye@gmail.com>

MB-36028: Flush the SSL socket more aggressively

Push the drain logic down to SslContext and always drain both
the BIO used for send and recv. Whenever we return success for
writing

MB-36028: Flush the SSL socket more aggressively

Push the drain logic down to SslContext and always drain both
the BIO used for send and recv. Whenever we return success for
writing data we should flush it all to the network.

Change-Id: I82680713e061ba4a2696054f754e8dfda55f29be
Reviewed-on: http://review.couchbase.org/115497
Tested-by: Trond Norbye <trond.norbye@couchbase.com>
Reviewed-by: Dave Rigby <daver@couchbase.com>

show more ...


# 4caaa1b8 24-Sep-2019 Trond Norbye <trond.norbye@gmail.com>

[SSL] Add support for using the same TLS frame for DCP

If we've got space in the current write buffer we may
stash the frame in there and avoid having multiple
TLS sections being cre

[SSL] Add support for using the same TLS frame for DCP

If we've got space in the current write buffer we may
stash the frame in there and avoid having multiple
TLS sections being created.

Change-Id: If59b4881d50200ef01bfb25ed80b8017ff19faff
Reviewed-on: http://review.couchbase.org/115330
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Dave Rigby <daver@couchbase.com>

show more ...


# d99091ca 26-Sep-2019 Trond Norbye <trond.norbye@gmail.com>

MB-36169: nmeta not initialized in DCP Delete

Introduced in http://review.couchbase.org/#/c/115327/ as the
constructor of the object won't be called as we're casting
to a pointer to

MB-36169: nmeta not initialized in DCP Delete

Introduced in http://review.couchbase.org/#/c/115327/ as the
constructor of the object won't be called as we're casting
to a pointer to the object and not creating an object

Change-Id: Ibc09de3ce58e476c4c400db7679778c37573b936
Reviewed-on: http://review.couchbase.org/115395
Tested-by: Trond Norbye <trond.norbye@couchbase.com>
Reviewed-by: Dave Rigby <daver@couchbase.com>

show more ...


# 05d2e029 25-Sep-2019 Trond Norbye <trond.norbye@gmail.com>

Refactor: split deletionOrExpirationV2

It is not that common anymore (and will get worse when we
squash for TLS frames)

Change-Id: I386867196c1947782f0f24ff98f7eac629370fb4

Refactor: split deletionOrExpirationV2

It is not that common anymore (and will get worse when we
squash for TLS frames)

Change-Id: I386867196c1947782f0f24ff98f7eac629370fb4
Reviewed-on: http://review.couchbase.org/115344
Reviewed-by: Jim Walker <jim@couchbase.com>
Tested-by: Trond Norbye <trond.norbye@couchbase.com>

show more ...


# 8e1a905c 25-Sep-2019 Trond Norbye <trond.norbye@gmail.com>

Remove meta section from DcpDeletion API

It is always being sent as { nullptr, 0 }.

Change-Id: Idd267d531343334dc2778d8493b68a31a9c01108
Reviewed-on: http://review.couchbase.org

Remove meta section from DcpDeletion API

It is always being sent as { nullptr, 0 }.

Change-Id: Idd267d531343334dc2778d8493b68a31a9c01108
Reviewed-on: http://review.couchbase.org/115327
Reviewed-by: Dave Rigby <daver@couchbase.com>
Tested-by: Build Bot <build@couchbase.com>

show more ...


# cef15947 25-Sep-2019 Trond Norbye <trond.norbye@gmail.com>

Remove meta section from DcpMutation API

It is always being sent as { nullptr, 0 } so we don't
need it in the API

Change-Id: I1f5162cfb978aa2ced8dd4e11cfb5f0c0ccc03ec
Review

Remove meta section from DcpMutation API

It is always being sent as { nullptr, 0 } so we don't
need it in the API

Change-Id: I1f5162cfb978aa2ced8dd4e11cfb5f0c0ccc03ec
Reviewed-on: http://review.couchbase.org/115324
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Dave Rigby <daver@couchbase.com>

show more ...


Revision tags: v6.0.3
# fc271938 17-Sep-2019 Trond Norbye <trond.norbye@gmail.com>

MB-36026: Squash adjacent IO entries in addIov

Cookie::sendResponse formats the response packet into
the write buffer by formatting and adding each segment
to the IO vector. Each of

MB-36026: Squash adjacent IO entries in addIov

Cookie::sendResponse formats the response packet into
the write buffer by formatting and adding each segment
to the IO vector. Each of these segments follows
directly after the previous entry, so instead of
having an IO vector looking like:

[0] { .base = 0; .length = 24 } // header
[1] { .base = 24; .length = 4 } // extras
[2] { .base = 28; .length = 32 } // key
[3] { .base = 60; .length = 20 } // body

We can use an IO vector looking like:

[0] { .base = 0; .length = 80 }

Why does this even matter? Short answer is SSL and
TLS framing. There is no SSL_writev in OpenSSLs API
so we've implemented that ourself by looping through
the IO vector and perform SSL_write on each of the
elements. Unfortunately that would cause OpenSSL
to generate a TLS frame for each entry (even if
we requested to send a single byte).

Each TLS frame introduce extra resource usage
(more data on the wire, more CPU used etc).

Change-Id: If9c5417e0ec85b6ef9e6a74a16a1b9a60de93af3
Reviewed-on: http://review.couchbase.org/114928
Reviewed-by: Dave Rigby <daver@couchbase.com>
Tested-by: Build Bot <build@couchbase.com>

show more ...


# 302fff65 18-Sep-2019 Trond Norbye <trond.norbye@gmail.com>

MB-36027: Use a single buffer for GET reponse [SSL]

A get response looks like:

+-------------------------------+
| 24 byte header |
+----------------

MB-36027: Use a single buffer for GET reponse [SSL]

A get response looks like:

+-------------------------------+
| 24 byte header |
+-------------------------------+
| 4 byte flags |
+-------------------------------+
| n bytes key (if requested) |
+-------------------------------+
| n byte value |
+-------------------------------+

Before this change we would put each of these segments
in an IO vector and use sendmsg to transfer all of
it back to the client. This was working great for
our plain connections, but when using SSL it had
an unexpected negative sideeffect: It would generate
a separate TLS frame for each segment, even if we
could fit it all in a single frame.

To work around the problem we'll format the entire
packet in a single buffer if the payload (everything
except the packet header) is less than 4k. (It might
be that we want to reduce/increase the 4k limit
depending if the memory copying cost compared to
the extra hashing and increased data to send on
the wire)

Change-Id: I76cc2a2c4d20f8073e34ceb59b48613d696f9f09
Reviewed-on: http://review.couchbase.org/114930
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Dave Rigby <daver@couchbase.com>

show more ...


# fb6944d9 18-Sep-2019 Dave Rigby <daver@couchbase.com>

MB-36051: Make Connection::priority atomic

As reported by TSan, Connection::priority is read and written without a lock:

hreadSanitizer: data race third_party/gsl-lite/include/gsl/g

MB-36051: Make Connection::priority atomic

As reported by TSan, Connection::priority is read and written without a lock:

hreadSanitizer: data race third_party/gsl-lite/include/gsl/gsl-lite.h:472gsl::fail_fast_assert(bool, char const*)

Read of size 1 at 0x7b5c00019738 by thread T23 (mutexes: write M2903806):
#0 gsl::fail_fast_assert(bool, char const*) third_party/gsl-lite/include/gsl/gsl-lite.h:472 (memcached+0x000000465448)
#1 gsl::not_null::get() const third_party/gsl-lite/include/gsl/gsl-lite.h:888 (memcached+0x000000465448)
#2 ServerCookieApi::get_priority(gsl::not_null) kv_engine/daemon/memcached.cc:1640 (memcached+0x000000465448)
#3 EventuallyPersistentEngine::getDCPPriority(void const*) kv_engine/engines/ep/src/ep_engine.cc:5828 (ep.so+0x000000171c57)
#4 ConnHandler::addStats(std::function)> const&, void const*) kv_engine/engines/ep/src/connhandler.cc:327 (ep.so+0x000000092b33)
#5 DcpProducer::addStats(std::function)> const&, void const*) kv_engine/engines/ep/src/dcp/producer.cc:1252 (ep.so+0x000000119b1e)
#6 ConnStatBuilder::operator()(std::shared_ptr) kv_engine/engines/ep/src/ep_engine.cc:3571 (ep.so+0x000000191fbf)
#7 void DcpConnMap::each(ConnStatBuilder) kv_engine/engines/ep/src/dcp/dcpconnmap.h:164 (ep.so+0x000000191fbf)
#8 EventuallyPersistentEngine::doDcpStats(void const*, std::function)> const&, cb::const_char_buffer) kv_engine/engines/ep/src/ep_engine.cc:3728 (ep.so+0x000000191fbf)
#9 EventuallyPersistentEngine::getStats(void const*, cb::const_char_buffer, cb::const_char_buffer, std::function)> const&) kv_engine/engines/ep/src/ep_engine.cc:4398 (ep.so+0x000000192bb8)
#10 KVBucket::snapshotStats() kv_engine/engines/ep/src/kv_bucket.cc:1149 (ep.so+0x0000002116db)
#11 StatSnap::run() kv_engine/engines/ep/src/tasks.cc:72 (ep.so+0x000000258ae2)
#12 ExecutorThread::run() kv_engine/engines/ep/src/executorthread.cc:153 (ep.so+0x0000001d0405)
...

Previous write of size 1 at 0x7b5c00019738 by thread T7 (mutexes: write M1036245144598543240):
#0 Connection::setPriority(Connection::Priority) kv_engine/daemon/connection.cc:1593 (memcached+0x0000004be2f2)
#1 ServerCookieApi::set_priority(gsl::not_null, CONN_PRIORITY) kv_engine/daemon/memcached.cc:1618 (memcached+0x0000004658b9)
#2 EventuallyPersistentEngine::setDCPPriority(void const*, CONN_PRIORITY) kv_engine/engines/ep/src/ep_engine.cc:5835 (ep.so+0x000000171d5f)
#3 DcpProducer::control(unsigned int, cb::const_char_buffer, cb::const_char_buffer) kv_engine/engines/ep/src/dcp/producer.cc:945 (ep.so+0x000000118cc3)
#4 non-virtual thunk to EventuallyPersistentEngine::control(gsl::not_null, unsigned int, cb::const_char_buffer, cb::const_char_buffer) (ep.so+0x00000018f966)
#5 dcpControl(Cookie&, unsigned int, cb::const_char_buffer, cb::const_char_buffer) kv_engine/daemon/protocol/mcbp/engine_wrapper.cc:408 (memcached+0x00000047c981)
#6 dcp_control_executor(Cookie&) kv_engine/daemon/protocol/mcbp/dcp_control_executor.cc:38 (memcached+0x000000513421)
#7 std::_Function_handler::_M_invoke(std::_Any_data const&, Cookie&) /usr/local/include/c++/7.3.0/bits/std_function.h:316 (memcached+0x000000503202)
#8 std::function::operator()(Cookie&) const /usr/local/include/c++/7.3.0/bits/std_function.h:706 (memcached+0x0000005019fe)
#9 execute_client_request_packet(Cookie&, cb::mcbp::Request const&) kv_engine/daemon/mcbp_executors.cc:857 (memcached+0x0000005019fe)
#10 execute_request_packet(Cookie&, cb::mcbp::Request const&) kv_engine/daemon/mcbp_executors.cc:881 (memcached+0x000000501bd7)
...

Fix by changing Connection::priority to be an atomic.

Change-Id: Ia6bae64ec09e1963e55e7cdb614fb17a68ff1726
Reviewed-on: http://review.couchbase.org/114956
Reviewed-by: Trond Norbye <trond.norbye@couchbase.com>
Tested-by: Build Bot <build@couchbase.com>

show more ...


# 9c27fb91 11-Sep-2019 Jim Walker <jim@couchbase.com>

MB-35932: Distinguish a bg-fetch needed vs pending durability

The KVBucket set/add/replace/deleteItem methods were overloading
the meaning of EWOULDBLOCK for pending sync-writes, in EWOU

MB-35932: Distinguish a bg-fetch needed vs pending durability

The KVBucket set/add/replace/deleteItem methods were overloading
the meaning of EWOULDBLOCK for pending sync-writes, in EWOULDBLOCK
was returned for sync-write accepted and bg-fetch needed. The
caller of the method then assumed a pending set for example
returning EWOULDBLOCK was always a sync-write accepted, breaking
SET with CAS in full-eviction (and others).

To address this issue, add a new error code ENGINE_SYNC_WRITE_PENDING
so that the caller of KVBucket methods can distinguish sync-write
accepted vs needs bg-fetch.

Change-Id: I91cc4883dc15c145ff9293ad680beb9063028e66
Reviewed-on: http://review.couchbase.org/114596
Reviewed-by: Trond Norbye <trond.norbye@couchbase.com>
Reviewed-by: Ben Huddleston <ben.huddleston@couchbase.com>
Tested-by: Build Bot <build@couchbase.com>

show more ...


# 67a5e264 27-Aug-2019 Trond Norbye <trond.norbye@gmail.com>

MB-35717: Fix handling of SSL_ERROR_WANT_WRITE

If ssl_write returns SSL_ERROR_WANT_WRITE it has
computed the next segment, but there isn't enough
room in the underlying bio to "send"

MB-35717: Fix handling of SSL_ERROR_WANT_WRITE

If ssl_write returns SSL_ERROR_WANT_WRITE it has
computed the next segment, but there isn't enough
room in the underlying bio to "send" it so it
needs to be drained.

According to the man page for ssl_write it should
be called again with the same parameters (data and size).

Previously we tried to chunk up our writes to ssl_write
so that they would "fit" into the underlying buffer, but
there isn't much point of doing so (except for adding
extra complexity to an already too complex solution).

Change-Id: I52a0f628f0bb0e5a5e76820b18cec02c467edd78
Reviewed-on: http://review.couchbase.org/113896
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Dave Rigby <daver@couchbase.com>
Well-Formed: Build Bot <build@couchbase.com>

show more ...


# 31a4fa96 27-Aug-2019 Trond Norbye <trond.norbye@gmail.com>

Print out cipher name as part of connect

This makes it easier to try to reproduce issues with SSL in
the future as we would know the SSL cipher in use.

Change-Id: Ia408851f3757b

Print out cipher name as part of connect

This makes it easier to try to reproduce issues with SSL in
the future as we would know the SSL cipher in use.

Change-Id: Ia408851f3757bd273292c1955aa0fc9e9e1a2494
Reviewed-on: http://review.couchbase.org/113931
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Dave Rigby <daver@couchbase.com>

show more ...


# 5d35b18f 27-Aug-2019 Trond Norbye <trond.norbye@gmail.com>

MB-35702: Propagate SSL write errors from sendmsg

If a write error occurs on a SSL connection for one
of the entries in the IO vector after a successful
write the error status set fr

MB-35702: Propagate SSL write errors from sendmsg

If a write error occurs on a SSL connection for one
of the entries in the IO vector after a successful
write the error status set from the underlying write
was lost.

Change-Id: I61c7da4f84117f12745fc8b8aa5984352187daef
Reviewed-on: http://review.couchbase.org/113888
Well-Formed: Build Bot <build@couchbase.com>
Reviewed-by: Dave Rigby <daver@couchbase.com>
Tested-by: Build Bot <build@couchbase.com>

show more ...


# 19748396 21-Aug-2019 Dave Rigby <daver@couchbase.com>

Settings: Avoid static initialization fiasco

When building on macOS with clang 8 and ThreadSanitizer enabled,
memcached_testapp crashes when destructing the Settings object:

Settings: Avoid static initialization fiasco

When building on macOS with clang 8 and ThreadSanitizer enabled,
memcached_testapp crashes when destructing the Settings object:

libc++abi.dylib: terminating with uncaught exception of type std::__1::system_error: mutex lock failed: Invalid argument

With the following backtrace from where the system_error exception is thrown:

* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x00007fff7b6411f6 libc++abi.dylib` __cxa_throw
frame #1: 0x00007fff7b6147af libc++.1.dylib` std::__1::__throw_system_error(int, char const*) + 77
frame #2: 0x00007fff7b606c93 libc++.1.dylib` std::__1::mutex::lock() + 29
frame #3: 0x00000001009c27ff memcached_testapp` folly::SharedMutexImpl<...>::annotateLazyCreate() [inlined] std::__1::unique_lock<std::__1::mutex>::unique_lock(__m=<unavailable>) + 191 at __mutex_base:131
frame #4: 0x00000001009c27f7 memcached_testapp` folly::SharedMutexImpl<...>::annotateLazyCreate() [inlined] std::__1::unique_lock<std::__1::mutex>::unique_lock(__m=<unavailable>) at __mutex_base:131
* frame #5: 0x00000001009c27f7 memcached_testapp` folly::SharedMutexImpl<...>::annotateLazyCreate() + 140 at SharedMutex.cpp:33
frame #6: 0x00000001009c276b memcached_testapp` folly::SharedMutexImpl<...>::annotateLazyCreate(this=0x0000000100c7ddc8) + 43 at SharedMutex.h:705
frame #7: 0x00000001009c191a memcached_testapp` folly::SharedMutexImpl<...>::~SharedMutexImpl() [inlined] folly::SharedMutexImpl<...>::annotateDestroy(this=<unavailable>) + 8 at SharedMutex.h:718
frame #8: 0x00000001009c1912 memcached_testapp` folly::SharedMutexImpl<...>::~SharedMutexImpl() + 24 at SharedMutex.h:324
frame #9: 0x00000001009c18fa memcached_testapp` folly::SharedMutexImpl<...>::~SharedMutexImpl(this=0x0000000100c7ddc8) + 26 at SharedMutex.h:300
frame #10: 0x000000010076b837 memcached_testapp` folly::Synchronized<...>::~Synchronized(this=0x0000000100c7ddb0) + 55 at Synchronized.h:484
frame #11: 0x000000010075d1d9 memcached_testapp` folly::Synchronized<...>::~Synchronized(this=0x0000000100c7ddb0) + 41 at Synchronized.h:484
frame #12: 0x000000010075e8fc memcached_testapp` Settings::~Settings(this=0x0000000100c7db10) + 76 at settings.h:51
frame #13: 0x000000010075c8b9 memcached_testapp` Settings::~Settings(this=0x0000000100c7db10) + 41 at settings.h:51
frame #14: 0x0000000102b7d5c1 libclang_rt.tsan_osx_dynamic.dylib` cxa_at_exit_wrapper(void*) + 33
frame #15: 0x00007fff7d72beed libsystem_c.dylib` __cxa_finalize_ranges + 351
frame #16: 0x00007fff7d72c1fe libsystem_c.dylib` exit + 55
frame #17: 0x00007fff7d67f01c libdyld.dylib` start + 8

The problem is at frame 5, where as part of the destruction of
SharedMutex (as used by a member variable of Settings) we are
attempting to acquire a mutex which has already been destructed (as it
is itself a function-local static) - i.e. we have encountered the
static initialization order fiasco :(

Address this by changing `settings` to no longer be a plain static
(global) variable, and instead be created on first use via a new
Settings::instance() static method.

Change-Id: I40bd44ed0ae32eb55271ce739fdf990d9869c32f
Reviewed-on: http://review.couchbase.org/113640
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Jim Walker <jim@couchbase.com>

show more ...


# ea5da9f2 03-Jul-2019 Trond Norbye <trond.norbye@gmail.com>

MB-35593: Extend logging for ssl read/write errors

Add more of SSL's error variables

Change-Id: I6a85db61765efb221497809808486103af5305ab
Reviewed-on: http://review.couchbase.or

MB-35593: Extend logging for ssl read/write errors

Add more of SSL's error variables

Change-Id: I6a85db61765efb221497809808486103af5305ab
Reviewed-on: http://review.couchbase.org/111537
Tested-by: Build Bot <build@couchbase.com>
Well-Formed: Build Bot <build@couchbase.com>
Reviewed-by: Dave Rigby <daver@couchbase.com>

show more ...


# a6c7e7be 09-Aug-2019 Ben Huddleston <ben.huddleston@couchbase.com>

MB-34017: Add HCS to SnapshotMarker

To correct the replica on disk HCS we need to tell it what pass it
the HCS value from the active when we send a disk snapshot. Add a
HCS field to

MB-34017: Add HCS to SnapshotMarker

To correct the replica on disk HCS we need to tell it what pass it
the HCS value from the active when we send a disk snapshot. Add a
HCS field to SnapshotMarker. In this patch, we should never send the
SnapshotMarkerV2 or expect to receive it.

Change-Id: I9963e49301574ee9b5ae22b043932c09e6e0ab5b
Reviewed-on: http://review.couchbase.org/113134
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Dave Rigby <daver@couchbase.com>

show more ...


# 8564ed04 10-Jul-2019 Trond Norbye <trond.norbye@gmail.com>

MB-34313: Remove timeout value for DCP PREPARE

The durability_timeout field in the DCP_PREPARE message is
unused - once a Prepare has been sent over DCP, the timeout
can no longer be

MB-34313: Remove timeout value for DCP PREPARE

The durability_timeout field in the DCP_PREPARE message is
unused - once a Prepare has been sent over DCP, the timeout
can no longer be applied if the replica was to be promoted,
as it may have already been committed by the old active.

Change-Id: I7f744c2fe9682b096ab58e25e34a55d1f8d32faa
Reviewed-on: http://review.couchbase.org/111998
Reviewed-by: Dave Rigby <daver@couchbase.com>
Tested-by: Trond Norbye <trond.norbye@couchbase.com>

show more ...


# 4eb01eff 05-Jul-2019 Ben Huddleston <ben.huddleston@couchbase.com>

Cleanup: Remove durability todos about not sending keys

We cannot rely on the prepare seqno of aborts and commits due to
deduplication so we need to send the keys. Remove todos for chang

Cleanup: Remove durability todos about not sending keys

We cannot rely on the prepare seqno of aborts and commits due to
deduplication so we need to send the keys. Remove todos for changes
that would have been made were we to stop sending the keys in aborts
and commits.

Change-Id: If0bb54b5e2f74421f351e12b7994a0873471133e
Reviewed-on: http://review.couchbase.org/111640
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Dave Rigby <daver@couchbase.com>

show more ...


# 0e9da2da 19-Jun-2019 Dave Rigby <daver@couchbase.com>

Connection::runEventLoop: Log errors at level ERROR

Change-Id: Ic3010d1a407aab72efb85ade71b2b981fd55a124
Reviewed-on: http://review.couchbase.org/111027
Reviewed-by: Trond Norbye <tr

Connection::runEventLoop: Log errors at level ERROR

Change-Id: Ic3010d1a407aab72efb85ade71b2b981fd55a124
Reviewed-on: http://review.couchbase.org/111027
Reviewed-by: Trond Norbye <trond.norbye@couchbase.com>
Tested-by: Trond Norbye <trond.norbye@couchbase.com>

show more ...


# bca95411 05-Jun-2019 Ben Huddleston <ben.huddleston@couchbase.com>

MB-34687: Add prepareSeqno to DCPCommit

We need the prepared seqno in the case where are replica receives two
commits in a row. In this case it may not have a prepare in the HashTable

MB-34687: Add prepareSeqno to DCPCommit

We need the prepared seqno in the case where are replica receives two
commits in a row. In this case it may not have a prepare in the HashTable
from which to get the prepareSeqno. If it does, the seqno will be wrong.

There exists two issues currently where we still allow 0 prepareSeqnos
which causes the sending of a Mutation instead of a Commit. These are
due to disk backfill doing a CacheLookup and creating an Item from a
StoredValue (which does not have a prepareSeqno so defaults to 0) and
Ephemeral not setting the prepareSeqno on the OrderedStoredValue. These
will be fixed in the following commit as they would cause a unit test
failure that requires a fix that should be highlighted in a separe
commit for MB-34542.

Change-Id: Ifdcdb1b68d12270587267912e307693c43edd705
Reviewed-on: http://review.couchbase.org/111005
Tested-by: Ben Huddleston <ben.huddleston@couchbase.com>
Reviewed-by: Dave Rigby <daver@couchbase.com>

show more ...


12345678910>>...12