History log of /6.0.3/kv_engine/ (Results 1 - 25 of 12207)
Revision (<<< Hide revision tags) (Show revision tags >>>)Date Author Comments
(<<< Hide modified files)
(Show modified files >>>)
Revision tags: v6.0.3
a30fd9d520-Sep-2019 Jim Walker <jim@couchbase.com>

MB-36101: deleteWithMeta of xattr doc must result in a deleted item

pruneXattrValue was returning an item which is created using the
input item. If the input is not deleted, then neither

MB-36101: deleteWithMeta of xattr doc must result in a deleted item

pruneXattrValue was returning an item which is created using the
input item. If the input is not deleted, then neither is the
output, resulting in a mutation and not a deletion.

Change-Id: I1fe5b555517dac1573c6cf1ed429c46bbc9dae3d
Reviewed-on: http://review.couchbase.org/115114
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: David Haikney <david.haikney@couchbase.com>
Well-Formed: Build Bot <build@couchbase.com>
Reviewed-by: Daniel Owen <owend@couchbase.com>

show more ...

893b9cdd20-Sep-2019 Jim Walker <jim@couchbase.com>

MB-36087: deleteWithMeta was not always fetching non-resident items

Update the clause which checks if a fetch is needed to be any non
resident xattr document, so it's not just temp-delet

MB-36087: deleteWithMeta was not always fetching non-resident items

Update the clause which checks if a fetch is needed to be any non
resident xattr document, so it's not just temp-deleted items.

Add a test to cover this case for full and value-eviction.

Change-Id: Ifeab50f68197d46746ae5849dc73874fd6f3a02c
Reviewed-on: http://review.couchbase.org/115113
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: David Haikney <david.haikney@couchbase.com>
Well-Formed: Build Bot <build@couchbase.com>
Reviewed-by: Daniel Owen <owend@couchbase.com>

show more ...

a2da054109-Sep-2019 sduvuru <sduvuru@gmail.com>

MB-35724: Merge remote-tracking branch 'couchbase/vulcan'

* couchbase/vulcan:
MB-35058: Couchstore-Trace operations on a file

Change-Id: Ifd71aef3956c64e763b3298e9afe95a2bd381

MB-35724: Merge remote-tracking branch 'couchbase/vulcan'

* couchbase/vulcan:
MB-35058: Couchstore-Trace operations on a file

Change-Id: Ifd71aef3956c64e763b3298e9afe95a2bd381e9b

show more ...


Revision tags: v5.5.4, v5.5.5
90bd9f5519-Mar-2019 sduvuru <sduvuru@gmail.com>

MB-35058: Couchstore-Trace operations on a file

-Tracing support to couchstore and dump trace on detection of corruption
-mprotect of iobuffer
-verify write to buffer cache by readin

MB-35058: Couchstore-Trace operations on a file

-Tracing support to couchstore and dump trace on detection of corruption
-mprotect of iobuffer
-verify write to buffer cache by reading back after write

To compile a kvengine test, need to modify the CMakeLists.txt.

Dynamically turn on/off tracing, write verification and mprotect for
couchstore with cbepctl

For example,
./cbepctl localhost:12000 -u Administrator -p ### -b Test
set flush_param couchstore_tracing true
./cbepctl localhost:12000 -u Administrator -p ### -b Test
set flush_param couchstore_write_validation true
./cbepctl localhost:12000 -u Administrator -p ### -b Test
set flush_param couchstore_mprotect true

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

show more ...

e7ed286227-Aug-2019 Dave Rigby <daver@couchbase.com>

MB-35649: Remove ExecutorThread::waketime

Since the fix for MB-35649, this member variable is no longer used for
thread scheduling (wakeup); sleep time is now directly calculated from

MB-35649: Remove ExecutorThread::waketime

Since the fix for MB-35649, this member variable is no longer used for
thread scheduling (wakeup); sleep time is now directly calculated from
the futureQueue contents.

As such remove it.

Change-Id: Iaff9f9e7d19f12416000dd3a9b31bb41d5e9e12d
Reviewed-on: http://review.couchbase.org/114231
Well-Formed: Build Bot <build@couchbase.com>
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: James Harrison <james.harrison@couchbase.com>

show more ...

e629ac4323-Aug-2019 Dave Rigby <daver@couchbase.com>

MB-35649: Fix lost (delayed) wakeups in ep background tasks

+Summary+

The ExecutorPool scheduler which manages all the background tasks
suffers from a race conditon in task wake

MB-35649: Fix lost (delayed) wakeups in ep background tasks

+Summary+

The ExecutorPool scheduler which manages all the background tasks
suffers from a race conditon in task wakeup which results in lost
task wakeups - i.e. tasks which should be woken immediately are not
waken until the next ExecutorThread polling interval (default 2s).

Amongst the tasks which suffer from this bug are
ActiveStreamCheckpointProcessorTask - recall this is the task
responsible for preparing outbound DCP messages to send to
replicas. As such, this bug results in intermittent 2s "pauses" in
SyncWrites completing (for #replicas > 0), as the DCP_PREPARE messages
are delayed in being sent out by 2s.

By fixing this bug we *significantly* improve the tail scheduler
wakeup latencies (i.e. how 'late' tasks are run compared to when the
task wanted to run), by up to 1000x (3 orders of magnitude). +

+Problem+

The bug is related to how an ExecutorThread's sleep time is
calculated, in the presence of an external caller waking up the task
after it has completed.

Consider a task like ActiveStreamCheckpointProcessorTask (others
behave the same).

* In an idle bucket it will be set to sleep forever as there will be
no DCP mutations to prepare - the Task will be in the AuxIO
futureQueue with a waketime of <FOREVER>.

* When new mutations occur in the frontend, the Task will be woken up
(via TaskQueue::_wake()) which:

a) Updates the Tasks' waketime to <NOW>.

b) Re-sorts the futureQueue if necessary, ensuring the soonest task
(either ActiveStreamCheckpointProcessorTask or another task just
woken) is at the front of the queue.

c) If any threads of the given type (AuxIO) are currently sleeping,
then wakes up threads equal to the number of tasks ready to
execute.

d) Those sleeping thread(s) will then check the futureQueue and pick
the next task to run.

This works correctly assuming that at least 1 AuxIO thread is sleeping
(in fact for simplicity it's sufficient to assume there's only 1 AuxIO
thread) - at (d) the sleeping thread is woken, and the Task is run().

However, consider what happens if the Task has /just/ finished a
previous run() iteration just before the wake() call occurs - there is
a race which results in a lost (delayed) wakeup:

<<<AuxIO Thread>>>

1) Assume Task::run() has just returned to ExecutorThread::run().

2) Task is reschedule()'d back in the futureQueue with a waketime of
<FOREVER>. Assume no other tasks are in the futureQueue.

3) setWaketime() is called with futureQueue min waketime - <FOREVER>.

4) TaskQueue::_nextTask() called. There are no tasks ready to run, so
it is about to call TaskQueue::_sleepThenFetchNextTask()...

<<<Waking thread>>>

5) TaskQueue::_wake() called, which acquires
TaskQueue::mutex, and performs operations
described above, crucially moving Task to the
front of the futureQueue. FutureQueue min waketime
= <NOW>. Releases TaskQueue::mutex.

<<<AuxIO Thread>>

6) ... calls TaskQueue::_sleepThenFetchNextTask(), acquires
TaskQueue::mutex and calls _doSleep. This reads the threads
waketime (as set at 3) which is <FORVER>, then calculates the
Thread's sleep time as min(2, minWaketime) - i.e. min(2, FOREVER)
or 2 seconds.

7) Thread goes to sleep for 2 seconds, even though there's a task in
futureQueue expecting to be run <NOW>.

<END>

While this is a complex scheduling system, arguably the crux of the
problem is the use of an independent member variable
(ExecutorThread::waketime) to determine when to wake the thread, which
is set independently of when the futureQueue is modifed (the
futureQueue contents ultimately dictate when a thread should be
woken).

+Solution+

Instead of pre-calculating a Thread's waketime and then applying it
later on, simply calculate the waketime directly from the contents of
the futureQueue just before we sleep - and crucially with the
TaskQueue::mutex held (which guards the futureQueue), preventing any
other threads racing to update it.

(A follow-up patch will remove ExecutorThread::waketime as it is now
unused).

+Alternative Solutions+

- We _could_ possibly extend the scope of the TaskQueue::mutex to also
guard ExecutorThread::waketime, however this feels complex and
breaks encapsulation - one objects' mutex is guarding state from
another. As such this approach wasn't seriously considered.

+Results+

Scheduler wait time histograms (i.e. how long a task waited to run after
it expected to start), ~100,000 samples for each:

Before:

ActiveStreamCheckpointProcessorTask[auxIO] (101277 total)
...
12us - 14us : ( 52.2389%) 7852 ███████████████████▏
...
82us - 86us : ( 99.0166%) 142 ▎
...
494us - 510us : ( 99.9832%) 1
510us - 2031ms : (100.0000%) 17
Avg : ( 315us)

* p50 = 14us, p99 = 86us, p99.99 = 2,031,000us, p100= 2,031,000us

After:

ActiveStreamCheckpointProcessorTask[auxIO] (100820 total)
...
17us - 20us : ( 54.7897%) 13725 █████████████████████████████████▊
...
110us - 118us : ( 99.1232%) 218 ▌
...
830us - 862us : ( 99.9901%) 1
...
1854us - 2302us : (100.0000%) 1
Avg : ( 26us)

* p50 = 20us, p99 = 118us, p99.99 = 862us, p100= 2302us

Note that p99.99 is ~1000x better (862 microseconds vs 2031
/milli/seconds).

Additionally the op/s observed with SyncWrites(level=majority) are
much smoother - we no longer see the op/s rate drop to zero for ~2s at
a time; they are ~constant.

+Further Work+

Arguably the only reason this problem has gone unnoticed for so long
is the 2s "fallback" upper bound applied to an ExecutorThread's
sleep time - while the wakeup is lost, the problem will self-correct
itself after 2s. If we hadn't had that "feature" then we would have
spotted this problem long ago (would have manifested as DCP streams
stopping forever and never recovering).

In the interests of creating a targetted, minimal fix, and given we've
have this fallback in place for a long time I'm not removing it in
this patch, however it _should_ be done in a follow-up.

Change-Id: Ie8569589f521c326b4f357bed1ad27c0790e7e88
Reviewed-on: http://review.couchbase.org/113769
Reviewed-by: James Harrison <james.harrison@couchbase.com>
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Trond Norbye <trond.norbye@couchbase.com>
Reviewed-by: Jim Walker <jim@couchbase.com>
(cherry picked from commit 32c0ae9f18a36552761eb307c6fe8ecf349b6f7c)
Reviewed-on: http://review.couchbase.org/114121
Well-Formed: Build Bot <build@couchbase.com>

show more ...

a35b959419-Aug-2019 Jim Walker <jim@couchbase.com>

BP: MB-35599: Warmup dead vbuckets

Change warmup so that dead and pending vbuckets are warmed-up.
It is very possible that a dead or pending vbucket will next
become replica or activ

BP: MB-35599: Warmup dead vbuckets

Change warmup so that dead and pending vbuckets are warmed-up.
It is very possible that a dead or pending vbucket will next
become replica or active, and as such the data inside it is
absolutely part of the bucket and must not be discarded.

The warmup treats these vbuckets though as replica in terms of
the percentage of quota they may consume.

This is a back port of 8c8a260e

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

show more ...

f2ca6c9b29-Aug-2019 Trond Norbye <trond.norbye@gmail.com>

MB-35724: Merge remote-tracking branch 'couchbase/vulcan'

* couchbase/vulcan:
MB-35717: Fix handling of SSL_ERROR_WANT_WRITE

Change-Id: I129e3faa8934e26f91cce92bcf7c82b69d01aa

MB-35724: Merge remote-tracking branch 'couchbase/vulcan'

* couchbase/vulcan:
MB-35717: Fix handling of SSL_ERROR_WANT_WRITE

Change-Id: I129e3faa8934e26f91cce92bcf7c82b69d01aa5c

show more ...


69f44f0329-Aug-2019 Gerrit Code Review <gerrit@li94-158.members.linode.com>

Merge "MB-35724: Merge remote-tracking branch 'couchbase/vulcan'" into alice


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

bc9dc2fa28-Aug-2019 Trond Norbye <trond.norbye@gmail.com>

MB-35395: Delete bucket did not reset cluster config

If the new bucket created was a memcached style bucket (which
don't have a cluster config) it would still serve the cluster
confi

MB-35395: Delete bucket did not reset cluster config

If the new bucket created was a memcached style bucket (which
don't have a cluster config) it would still serve the cluster
config from the old bucket.

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

show more ...

d854b14928-Aug-2019 Trond Norbye <trond.norbye@gmail.com>

MB-35724: Merge remote-tracking branch 'couchbase/vulcan'

* couchbase/vulcan:
MB-35702: Propagate SSL write errors from sendmsg
MB-35593: Extend logging for ssl read/write errors

MB-35724: Merge remote-tracking branch 'couchbase/vulcan'

* couchbase/vulcan:
MB-35702: Propagate SSL write errors from sendmsg
MB-35593: Extend logging for ssl read/write errors
MB-35534: Set the correct domain for memcached events

Change-Id: I3d50c156443249baa0bd71f2fd2f6f1a66501b0e

show more ...


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

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

0338b01b12-Aug-2019 Trond Norbye <trond.norbye@gmail.com>

MB-35534: Set the correct domain for memcached events

Ideally the unit test should have been backported, but
we've changed the JSON library and done major enhancements
in the unit te

MB-35534: Set the correct domain for memcached events

Ideally the unit test should have been backported, but
we've changed the JSON library and done major enhancements
in the unit test framework to consume the produced audit
trail which would significantly grow the patch

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

show more ...

b6f27f5708-Aug-2019 James Harrison <00jamesh@gmail.com>

MB-35410: Update datatype on wholedoc operation

Wholedoc ops (as part of a subdoc multimutation) can replace the entire
document - potentially with a new value which does not match the

MB-35410: Update datatype on wholedoc operation

Wholedoc ops (as part of a subdoc multimutation) can replace the entire
document - potentially with a new value which does not match the
current datatype. E.g., existing json document replaced with non-json
raw bytes.

The datatype should be updated in this case.

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

show more ...

027e153e05-Jul-2019 Daniel Owen <owend@couchbase.com>

MB-34879: Ensure correct datatype for uncompressed doc with xattrs

There is a bug that shows up on SDKs that support compression. The
issue is with documents that have xattrs and are co

MB-34879: Ensure correct datatype for uncompressed doc with xattrs

There is a bug that shows up on SDKs that support compression. The
issue is with documents that have xattrs and are compressed. With a get
request the document is uncompressed to allow the xattrs to be stripped
before the document is sent to the client. However we do not clear the
snappy datatype on the document before sending the document.

On a client that does not support compression that is OK because we
set the document datatype based on the intersect of what the document
datatype is and what the client supports and hence the snappy datatype
is cleared. However on a client that supports compression the snappy
datatype is not cleared.

This results in the server sending a document that is marked as snappy
compressed but the payload is not compressed. Therefore the SDK raises
an error when it attempts to decompress the payload.

The fix is to clear the compression datatype on the document when it
is decompressed on the server, before the xattrs are stripped.

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

show more ...

d0399ce103-Jan-2019 Richard de Mellow <richard.demellow@couchbase.com>

MB-32555 [BP 6.0.3] memcached stats scheduler logs negative values

Fix MB-32481, we should only log tasks as having an overhead
when they are woken up later than their expected wake-up t

MB-32555 [BP 6.0.3] memcached stats scheduler logs negative values

Fix MB-32481, we should only log tasks as having an overhead
when they are woken up later than their expected wake-up time.
So if the task is woken up before we should log the overhead as
zero.

Backport of 929d2c719e61caedebdfe36415b19aaebc1c3f57

Change-Id: I1a7236968941e1990f82a58baf700908bf9c7e29
Reviewed-on: http://review.couchbase.org/107355
Reviewed-by: Dave Rigby <daver@couchbase.com>
Tested-by: Build Bot <build@couchbase.com>
Well-Formed: Wayne Siu <wayne@couchbase.com>
Well-Formed: Build Bot <build@couchbase.com>

show more ...

f29b4df812-Jun-2019 Daniel Owen <owend@couchbase.com>

MB-33683: Merge branch 'couchbase/vulcan' into 'couchbase/alice'

* couchbase/vulcan:
MB-34438: Return NOT_MY_VBUCKET for getReplica on pending vbucket

Change-Id: I08c9da488118

MB-33683: Merge branch 'couchbase/vulcan' into 'couchbase/alice'

* couchbase/vulcan:
MB-34438: Return NOT_MY_VBUCKET for getReplica on pending vbucket

Change-Id: I08c9da4881181557645381d481a3f5f0e42f2a4f

show more ...


9ea0523f10-Apr-2019 Daniel Owen <owend@couchbase.com>

MB-34438: Return NOT_MY_VBUCKET for getReplica on pending vbucket

[Backport of MB-33683.]

Currently when a GET_REPLICA operation is sent to a vbucket in a pending
state it is pl

MB-34438: Return NOT_MY_VBUCKET for getReplica on pending vbucket

[Backport of MB-33683.]

Currently when a GET_REPLICA operation is sent to a vbucket in a pending
state it is placed in the pendingOps list and is processed when the
vbucket is moved to the active state.

However given that is is not valid for a GET_REPLICA to be applied to
an active vbucket, when it gets to execute it will just NOT_MY_VBUCKET.

Another issue with placing a GET_REPLICA operation into the pendingOps
list is that if a rebalance fails and the vbucket move from a pending
state back into a replica state, the operation will be held in the
pendingOps list potentially indefinately.

This patch ensures that if a GET_REPLICA operation is sent to a vbucket
in a pending state we immediately return NOT_MY_VBUCKET.

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

show more ...

480cd5f412-Jun-2019 Daniel Owen <owend@couchbase.com>

MB-34507: Merge branch 'couchbase/vulcan' into 'couchbase/alice'

* couchbase/vulcan:
MB-34507: Reset datatype to XATTR when pruning system XATTRs

Change-Id: I454ee6c1a170f104f

MB-34507: Merge branch 'couchbase/vulcan' into 'couchbase/alice'

* couchbase/vulcan:
MB-34507: Reset datatype to XATTR when pruning system XATTRs

Change-Id: I454ee6c1a170f104f4f8eb390a2ed3c223a818a6

show more ...


5b44baab06-Jun-2019 Dave Rigby <daver@couchbase.com>

MB-34507: Reset datatype to XATTR when pruning system XATTRs

When pruning system XATTRs during expiry, if the input document was
compressed then we fail to clear the SNAPPY flag in the d

MB-34507: Reset datatype to XATTR when pruning system XATTRs

When pruning system XATTRs during expiry, if the input document was
compressed then we fail to clear the SNAPPY flag in the datatype -
even though the pruned XATTRs /will/ be uncompressed. This results in
subsequent attempts to manipulate the document body failing as
KV-Engine will think it needs to decompress the body, however that
will fail as Snappy will (correctly) return the data isn't Snappy
compressed.

For example, this manifests when attempting to modify via subdoc:

WARNING <4 ERROR: Failed to determine inflated body size. Key: '<ud>docid</ud>' may have an incorrect datatype of COMPRESSED_JSON.

Fix by reseting the datatype to XATTRs if the pre-expiry callback
returns a non-empty response.

Change-Id: I73db03c329da79ba5261f8af185854324c1c54c3
Reviewed-on: http://review.couchbase.org/110318
Reviewed-by: Jim Walker <jim@couchbase.com>
Well-Formed: Build Bot <build@couchbase.com>
Tested-by: Daniel Owen <owend@couchbase.com>

show more ...

1c072e3604-Jun-2019 Daniel Owen <owend@couchbase.com>

Merge couchbase/vulcan into couchbase/alice

* commit 'd5cbd1c08':
MB-34329: reset snapshot range to be a valid range

Change-Id: I1e96d383a41e1f8cb268503871247e79bf7a4df2


d5cbd1c031-May-2019 Jim Walker <jim@couchbase.com>

MB-34329: reset snapshot range to be a valid range

The original code at fault here (resetSnapshotRange) was added
as a fix for MB-14388. The ep_testsuite (dcp) unit test
test_failove

MB-34329: reset snapshot range to be a valid range

The original code at fault here (resetSnapshotRange) was added
as a fix for MB-14388. The ep_testsuite (dcp) unit test
test_failover_scenario_with_dcp does indeed trigger the same
failure as seen in the MB, revert the entire resetSnapshotRange
function and the test fails. However with the code removed
the failure cannot be observed in system testing. My
conclusion is that the test is bogus, there is no obvious takeover
occurring in the logs of the original MB.

The conclusion is that it is not safe to remove the resetSnapshotRange
function completely, but it should never set the range to be +1 of
the current seqno, so that is the change to make, simplify the function
and generate a legal range.

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

show more ...

80f3e85431-May-2019 Jim Walker <jim@couchbase.com>

MB-34346: Merge branch 'couchbase/vulcan' into 'couchbase/alice'

* couchbase/vulcan:
MB-34346: Allow pruning of compressed xattrs

Change-Id: Ice49295e8f9d8a924f08c603ed8edfabc

MB-34346: Merge branch 'couchbase/vulcan' into 'couchbase/alice'

* couchbase/vulcan:
MB-34346: Allow pruning of compressed xattrs

Change-Id: Ice49295e8f9d8a924f08c603ed8edfabc44fde95

show more ...


12345678910>>...489