History log of /6.6.0/kv_engine/daemon/thread.cc (Results 1 – 25 of 131)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v7.1.1, v7.0.4, v7.1.0, v6.6.5-MP1, v6.6.5, v6.6.4, v7.0.2, v7.0.1, v6.6.3, v7.0.0, v6.6.2, v6.5.2, v6.0.5, v6.6.1, v6.5.1-MP5, v6.6.0, v6.5.1-MP3, v6.5.1, v6.0.4, v6.5.0
# 50429d8c 23-Oct-2019 Dave Rigby <daver@couchbase.com>

Revert "MB-36249: Replace notification pipe FDs with libevent event_active()"

Numbers from daily performance runs (KV : Pillowfight, 20/80 R/W, 256B
binary items) shows that this actually _reduces_

Revert "MB-36249: Replace notification pipe FDs with libevent event_active()"

Numbers from daily performance runs (KV : Pillowfight, 20/80 R/W, 256B
binary items) shows that this actually _reduces_ performance by ~2%
(see build 4631 vs 4632).

A brief look at the libevent code _suggests_ this is due to
event_active() needing to acquire the per-event base mutex, which
wasn't the case with the previous implementation which just wrote to
an FD.

Reverting to restore previous performance.

This reverts commit 4e021f71f7bbc2475657135b374c5fa5b3a37726.

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

show more ...


# 4e021f71 17-Oct-2019 Dave Rigby <daver@couchbase.com>

MB-36249: Replace notification pipe FDs with libevent event_active()

Currently memcached uses a pair of sockets connected to each other to
perform notification between threads. Benchmarking shows th

MB-36249: Replace notification pipe FDs with libevent event_active()

Currently memcached uses a pair of sockets connected to each other to
perform notification between threads. Benchmarking shows this can be
costly - when running a pillowfight test with
durability_level=persist_majority, profiling shows 15% of the NonIO
thread runtime is spent sending notifications (via libc send()) to
front-end threads to inform them to wake up.

Libevent however already provides a mechanism to wake up an event
directly from a different thread via event_active(). This internally
uses the most efficient mechanism available on the platform - which
for Linux is eventfd(), available since 2.6.22 (2007).

Profling with using eventfd (via libevent's event_active()) reduces
the cost of notifying other threads from NonIO thread to 9% of total
runtime (down from 15%).

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

show more ...


# 34440eed 16-Oct-2019 Trond Norbye <trond.norbye@gmail.com>

Slow down the logging during shutdown

In MB-36467 we've got a problem deleting a bucket, but due to
ns_server giving up waiting for memcached we end up in a
situation where memcached enters a tight

Slow down the logging during shutdown

In MB-36467 we've got a problem deleting a bucket, but due to
ns_server giving up waiting for memcached we end up in a
situation where memcached enters a tight loop trying to shut
down the connection and log every time. Given that we cycle
the log files and ns_server only keeps 20 of them (~400MB)
we'll only have a few seconds left.

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

show more ...


Revision tags: v6.0.3, v5.5.6
# 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:

libc++abi.dylib: te

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 ...


# 8ba5a899 21-Aug-2019 Trond Norbye <trond.norbye@gmail.com>

Remove duplicate log entry for conn alloc failures

dispatch_new_connections added a "generic" log entry if
conn_new returned nullptr, but conn_new had already
logged the reason why it failed to crea

Remove duplicate log entry for conn alloc failures

dispatch_new_connections added a "generic" log entry if
conn_new returned nullptr, but conn_new had already
logged the reason why it failed to create the new
connection.

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

show more ...


Revision tags: v6.0.2, v5.5.5
# 9e8f5bb7 12-Jun-2019 Trond Norbye <trond.norbye@gmail.com>

Refactor: Make thread a reference in Connection

The connection object is _ALWAYS_ bound to a thread and it
does NEVER change so we should use a reference to make it
easier for the reader to know tha

Refactor: Make thread a reference in Connection

The connection object is _ALWAYS_ bound to a thread and it
does NEVER change so we should use a reference to make it
easier for the reader to know that.

Change-Id: I5b6f239777753ee3693eb0f00911fa61d0e2efe3
Reviewed-on: http://review.couchbase.org/110588
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Richard de Mellow <richard.demellow@couchbase.com>

show more ...


Revision tags: v5.5.4
# 0f1a35e9 08-Mar-2019 Richard de Mellow <richard.demellow@couchbase.com>

MB-22005: Move from Histogram<T> to data size HdrHistograms

Replace the usages of the template class Histogram<T> from
platform/histogram.h with specialised versions of HdrHistogram.
This will allow

MB-22005: Move from Histogram<T> to data size HdrHistograms

Replace the usages of the template class Histogram<T> from
platform/histogram.h with specialised versions of HdrHistogram.
This will allow us to display data with dynamic bucketing
what can be based on percentiles or a logarithmic scale. Unlike
Histogram<T> which uses fixed width buckets. Which makes it hard
to view if all the values fall into the same bucket. With
HdrHistogram we can display the information around the data,
making it easier to understand.

Refactor HdrMicroSecHistogram, to reduce it's memory foot print
by reducing its accuracy from 3 sig fig to 1 sig fig. Taking the
histograms memory foot print from 139472 bytes to 3152 bytes. Also
we've renamed it to Hdr1sfMicroSecHistogram, to help reflect this.

This refactor and the histograms added in this patch will take the
memory used by for an empty bucket to 22.2MB from 21.7MB at the point
before MB-22005 code was added.

Add code to get the memory foot print of structures that use
HdrHistograms. As just using sizeof(struct x) will not give an
accuracy value as HdrHistograms are allocated to the heap.

ep-engine_sizes output showing the relative sizes of histograms:
GIGANTOR 9223372036854775808
StoredValue 56
StoredValue with 15 byte key 72
Ordered Stored Value 72
Blob 12
value_t 8
HashTable 352
Item 104
VBucket 1392
VBucketMap 40
Stats 1640
CheckpointManager 384
Checkpoint 312
CheckpointConfig 32
Histogram<whatever> 1048
HistogramBin<size_t> 24
HistogramBin<int> 16
HistogramBin<microseconds> 24
MicrosecondHistogram 1048
EPStats 466080
FileStats 29056
KVStoreStats 99776
Histogram<size_t>{ExponentialGenerator<size_t>(1, 2), 50} 1688
HdrHistogram frequency histo 16592
Hdr1sfMicroSecHistogram 3152
Hdr2sfMicroSecHistogram 20688
HdrUint8Histogram 16592
Hdr1sfInt32Histogram 3920
HdrHistogram(0, std::numeric_limits<int32_t>::max(), 2) 25808
HdrHistogram(0, std::numeric_limits<int32_t>::max(), 1) 3792
HdrHistogram(0, std::numeric_limits<int64_t>::max(), 2) 58576
HdrHistogram(0, std::numeric_limits<int64_t>::max(), 1) 7888
IORequest 112
CouchRequest 240
PersistenceCallback 16
AtomicUnorderedMap<uint32_t, SingleThreadedRCPtr<Stream>> 480
ProbabilisticCounter<uint8_t> 24
DcpResponse 16
MutationResponse 32
queued_item 8

Histogram Ranges

Default Histo 1048
Commit Histo 1048
Hash table depth histo 3920

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

show more ...


# 26d24b39 01-May-2019 Trond Norbye <trond.norbye@gmail.com>

MB-33971: System connections is bound to system port

There was a misunderstanding when the task to account for system
connections. I thought we wanted to account for all "couchbase
internal componen

MB-33971: System connections is bound to system port

There was a misunderstanding when the task to account for system
connections. I thought we wanted to account for all "couchbase
internal components", but ns_server have no control over the
connection usage for components like eventing, indexing, projector
query, fts etc, and we don't want to end up in a situation where
ns_server can't connect to the cluster because the pool of system
connections is consumed.

To work around this ns_server will mark an interface as "system"
and all connections towards that port is system connections.

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

show more ...


# 18b3ad80 05-Mar-2019 Trond Norbye <trond.norbye@gmail.com>

MB-32687: Backport signalIfIdle refactor

signalIfIdle used to update the event mask in libevent to add
a write event to make the socket available. Libevent would then
pick up that socket next time i

MB-32687: Backport signalIfIdle refactor

signalIfIdle used to update the event mask in libevent to add
a write event to make the socket available. Libevent would then
pick up that socket next time it went down to the OS to do a poll
on the sockets. The problem is that when we try to update the
event mask for a socket libevent will try to acquire the mutex
used by the event base in order to do that. If the code was
called from another worker thread it would hold it's own lock
on the event base (and we're subject for a deadlock).

The new implementation of signalIfIdle push the connection
onto a list of connections to signal for the worker thread,
before it notifies the worker thread by writing to the
notification pipe for the worker thread. The callback for
the worker thread swaps out the list of connections, and
runs the state machine for each of the connections in there.

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

show more ...


# 02d5ff47 10-Apr-2019 Trond Norbye <trond.norbye@gmail.com>

Cleanup: Remove OpenSSL < 1.1 code

Change-Id: I000889e8ce34aab537b2b4d477f20eed341e2a8b
Reviewed-on: http://review.couchbase.org/107609
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Jim Wa

Cleanup: Remove OpenSSL < 1.1 code

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

show more ...


# edd2d65b 04-Apr-2019 Trond Norbye <trond.norbye@gmail.com>

MB-33599: Allow dynamic reconfig of interfaces

Add support for adding / deleting or changing network
interface descriptions. To simplify the implementation
all reconfiguration happens in the dispatc

MB-33599: Allow dynamic reconfig of interfaces

Add support for adding / deleting or changing network
interface descriptions. To simplify the implementation
all reconfiguration happens in the dispatcher thread
and not as part of reloading the config file.

To avoid ending up in a situation where we no longer
can connect to memcached changing the interfaces
works by first enabling all new interface descriptions,
and if no error happens it'll shut down the ones
no longer in the configuration.

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

show more ...


# 63b2de8a 11-Mar-2019 Richard de Mellow <richard.demellow@couchbase.com>

MB-22005 Move from TimingHistogram to HdrHistogram (recommit)

This is a recommit of commit 3aa986fb2a41e8f12480e899b6900a87cec28475
as it was reverted due to a performance regression, caused by cach

MB-22005 Move from TimingHistogram to HdrHistogram (recommit)

This is a recommit of commit 3aa986fb2a41e8f12480e899b6900a87cec28475
as it was reverted due to a performance regression, caused by cache
line contention from memory accesses in hdr_record_values() from
HdrHistogram_c.

This commit also contains an additional fix to remove a race
condition when creating a HdrMicroSecHistogram object in
Timings::get_or_create_timing_histogram. Where two threads could try
and create two HdrMicroSecHistogram objects. This would then cause
one to be destoryed while it was being created. Meaning it would
try and free its counts pointer even though it has not been
allocated yet.

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

show more ...


# 04c1c8ec 20-Mar-2019 Trond Norbye <trond.norbye@gmail.com>

Remove config.h

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

Remove config.h

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

show more ...


# e1a50a94 11-Mar-2019 Trond Norbye <trond.norbye@gmail.com>

MB-33226: Push trace from a dedicated thread

To avoid OpenTracing to potentially block the front-end
threads while the OpenTracing module performs the operations
we'll push the context to a "list" a

MB-33226: Push trace from a dedicated thread

To avoid OpenTracing to potentially block the front-end
threads while the OpenTracing module performs the operations
we'll push the context to a "list" and process those entries
in a dedicated thread.

NOTE: The code assumes that only a subset of the commands
requests OpenTracing otherwise we'll probably get lock
contention (and should migrate over to a "per thread"
list).

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

show more ...


# 24922815 08-Mar-2019 Trond Norbye <trond.norbye@gmail.com>

Include what you use

Include what you use, and remove the C linkage
in cbsasl/util.h (we're all C++)

(prepare to get rid of platform/platform.h)

Change-Id: I6be2912761a34318163f05a1e3be38cf0090932

Include what you use

Include what you use, and remove the C linkage
in cbsasl/util.h (we're all C++)

(prepare to get rid of platform/platform.h)

Change-Id: I6be2912761a34318163f05a1e3be38cf00909320
Reviewed-on: http://review.couchbase.org/105904
Reviewed-by: Daniel Owen <owend@couchbase.com>
Reviewed-by: Dave Rigby <daver@couchbase.com>
Tested-by: Trond Norbye <trond.norbye@couchbase.com>

show more ...


# adbf1ec0 08-Mar-2019 Richard de Mellow <richard.demellow@couchbase.com>

Revert "MB-22005 Move from TimingHistogram to HdrHistogram"

This reverts commit 3aa986fb2a41e8f12480e899b6900a87cec28475. Due to
performance regression with ephemeral buckets (MB-33273).

Change-Id

Revert "MB-22005 Move from TimingHistogram to HdrHistogram"

This reverts commit 3aa986fb2a41e8f12480e899b6900a87cec28475. Due to
performance regression with ephemeral buckets (MB-33273).

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

show more ...


Revision tags: v6.0.1
# 3aa986fb 08-Jan-2019 Richard de Mellow <richard.demellow@couchbase.com>

MB-22005 Move from TimingHistogram to HdrHistogram

Move kv_engine to use HdrHistogram class, where we currently use
TimingHistogram class. This will allow the use of dynamic bucket
ranges and thus a

MB-22005 Move from TimingHistogram to HdrHistogram

Move kv_engine to use HdrHistogram class, where we currently use
TimingHistogram class. This will allow the use of dynamic bucket
ranges and thus allows us to iterate over the data in multiple
different ways.

This patch also changes mctimings to no longer print out buckets
of a fixed width and will now display bucket data based on
percentiles.

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

show more ...


# 8356a8d9 25-Feb-2019 Trond Norbye <trond.norbye@gmail.com>

OpenSSL: Mute deprecated warning when building on OpenSSL 1.1

Change-Id: I22642b7eb6c8cb2d60dced455fd9c55cf844f8f4
Reviewed-on: http://review.couchbase.org/105333
Reviewed-by: Dave Rigby <daver@couc

OpenSSL: Mute deprecated warning when building on OpenSSL 1.1

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

show more ...


# ffb7c145 20-Feb-2019 Trond Norbye <trond.norbye@gmail.com>

Refactor: migrate off cb_mutex/cond in core

Use std::mutex and std::condition_variable instead

Change-Id: Iace666ca47153769c6efd21c88c1d3563777b6d3
Reviewed-on: http://review.couchbase.org/105179
T

Refactor: migrate off cb_mutex/cond in core

Use std::mutex and std::condition_variable instead

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

show more ...


# a2c04e2b 03-Jan-2019 Trond Norbye <trond.norbye@gmail.com>

MB-31402: Back off logging of stuck connections

Change logging of stuck connections during deletion to:

1. Don't log anything the first 30 seconds. Then
dump the state of all stuck connect

MB-31402: Back off logging of stuck connections

Change logging of stuck connections during deletion to:

1. Don't log anything the first 30 seconds. Then
dump the state of all stuck connections.
2. Don't og anything for the next 30 seconds. Then
dump the state of all stuck connections which
changed since the previous dump.
3. goto 2.

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

show more ...


# b4a4f862 07-Jan-2019 Trond Norbye <trond.norbye@gmail.com>

clang-tidy: Clean warnings in daemon/thread.cc

Change-Id: If9c6b6343511137ffe894a56eb854889b77081fe
Reviewed-on: http://review.couchbase.org/103324
Reviewed-by: Dave Rigby <daver@couchbase.com>
Test

clang-tidy: Clean warnings in daemon/thread.cc

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

show more ...


# cad3ea13 04-Jan-2019 Trond Norbye <trond.norbye@gmail.com>

MB-32497: Remove potential deadlock with signalIfIdle

signalIfIdle used to update the event mask in libevent to add
a write event to make the socket available. Libevent would then
pick up that socke

MB-32497: Remove potential deadlock with signalIfIdle

signalIfIdle used to update the event mask in libevent to add
a write event to make the socket available. Libevent would then
pick up that socket next time it went down to the OS to do a poll
on the sockets. The problem is that when we try to update the
event mask for a socket libevent will try to acquire the mutex
used by the event base in order to do that. If the code was
called from another worker thread it would hold it's own lock
on the event base (and we're subject for a deadlock).

The new implementation of signalIfIdle push the connection
onto a list of connections to signal for the worker thread,
before it notifies the worker thread by writing to the
notification pipe for the worker thread. The callback for
the worker thread swaps out the list of connections, and
runs the state machine for each of the connections in there.

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

show more ...


# c6780a7c 07-Jan-2019 Trond Norbye <trond.norbye@gmail.com>

Refactor: Move new connection queue to standard libs

Use std::pair and std::vector instead of our own classes
with unique-ptrs etc.

Change-Id: Ic8a6676992925e76b4fbea642598432c6d9a62ad
Reviewed-on:

Refactor: Move new connection queue to standard libs

Use std::pair and std::vector instead of our own classes
with unique-ptrs etc.

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

show more ...


Revision tags: v5.5.3
# a02cd553 25-Oct-2018 Trond Norbye <trond.norbye@gmail.com>

Refactor: Notification list is on a per-cookie base

When OOO is enabled a connection may have multiple cookies
which needs to be flagged.

Change-Id: I9daec331b37242db23994529e5785fb765f77055
Review

Refactor: Notification list is on a per-cookie base

When OOO is enabled a connection may have multiple cookies
which needs to be flagged.

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

show more ...


# cc43592e 12-Dec-2018 Trond Norbye <trond.norbye@gmail.com>

Retry notification of worker threads during shutdown

When moving over to bufferevents calling signalIfIdle
the actual connection may be run at a later time and
not necessarily immediate. This could

Retry notification of worker threads during shutdown

When moving over to bufferevents calling signalIfIdle
the actual connection may be run at a later time and
not necessarily immediate. This could cause the shutdown
to hang as we've notified the thread, but that notification
what swallowed as part of another "notify_io_complete"
routine causing us to bump back to libevent to wait for
the next event.

Loop and signal the notification pipe until the thread
stops

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

show more ...


123456