History log of /5.5.2/kv_engine/engines/ep/src/ep_bucket.cc (Results 1 - 25 of 89)
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, v6.5.1, v6.0.4, v6.5.0, v6.0.3, v5.5.4, v5.5.5, v5.5.6, v6.0.1, v5.5.3, v6.0.0, v5.1.3, v5.5.2, v5.5.1, v5.1.2, v5.1.1
# ddfd3c29 15-May-2018 Dave Rigby <daver@couchbase.com>

MB-29675: Only wakeup ckpt remover if removable checkpoints

Currently we conditionally wake up the ClosedUnrefCheckpointRemoverTask
in two places, based on if there is more than one chec

MB-29675: Only wakeup ckpt remover if removable checkpoints

Currently we conditionally wake up the ClosedUnrefCheckpointRemoverTask
in two places, based on if there is more than one checkpoint in
existence:

a) flushVBucket()
b) ActiveStream::getOutstandingItems

However, this is a optimistic check - just because there is more than
one checkpoint; doesn't mean that any checkpoints can actually be
freed. There is typically at least two cursors (persistence +
replication), and potentially many more. Unless the oldest checkpoint is
actually empty (and closed) can we free anything.

As such this will cause us to schedule and run
ClosedUnrefCheckpointRemoverTask unnecessarily.

Change the wakeup criteria to be based on if the oldest checkpoint
(which is the first one which can be considered to be removed) is both
closed, and has zero cursors in it.

Change-Id: I68be804c6d07a991ad53017c9f4fc14ebb9b9a2e
Reviewed-on: http://review.couchbase.org/94296
Reviewed-by: Jim Walker <jim@couchbase.com>
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Tim Bradgate <tim.bradgate@couchbase.com>

show more ...


# 46b2dd46 23-May-2018 Jim Walker <jim@couchbase.com>

MB-29721: Set hlc_epoch from the min seqno flushed

Using range.start appears to be flawed, as the range.start for a full
snapshot flush is not the min seqno, so some data will lose the

MB-29721: Set hlc_epoch from the min seqno flushed

Using range.start appears to be flawed, as the range.start for a full
snapshot flush is not the min seqno, so some data will lose the
last_modified field.

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

show more ...


# f7a80cbd 22-May-2018 Sriram Ganesan <sriram@couchbase.com>

MB-29583: Catch exceptions from CouchKVStore APIs

Some CouchKVStore APIs get statistics from the underlying couchstore
file. In some cases, the underlying file could be missing, thus

MB-29583: Catch exceptions from CouchKVStore APIs

Some CouchKVStore APIs get statistics from the underlying couchstore
file. In some cases, the underlying file could be missing, thus
resulting in an exception being thrown. In order to prevent memcached
from being taken down by these exceptions, catch the exception in the
caller and either fail the operation being performed or just log the
error

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

show more ...


# a52ce0a4 10-Apr-2018 Jim Walker <jim@couchbase.com>

MB-29119: Replace revSeqno with a 48-bit counter

Prevent a value too large to be stored in couchstore
from being placed into Item/StoredValue and also the
_local document (via vbucke

MB-29119: Replace revSeqno with a 48-bit counter

Prevent a value too large to be stored in couchstore
from being placed into Item/StoredValue and also the
_local document (via vbucket_state).

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

show more ...


# fa374dbe 14-Mar-2018 Dave Rigby <daver@couchbase.com>

MB-28671: UBSan: Remove static_cast<EPBucket&> before object constructed.

UBSan reports the following undefined behaviour when constructing a KVShard object:

kvshard.cc:64:20: r

MB-28671: UBSan: Remove static_cast<EPBucket&> before object constructed.

UBSan reports the following undefined behaviour when constructing a KVShard object:

kvshard.cc:64:20: runtime error: downcast of address 0x000107bb2000 which does not point to an object of type 'EPBucket'
0x000107bb2000: note: object is of type 'KVBucket'
#0 0x10080f058 in KVShard::KVShard(unsigned short, KVBucket&) kvshard.cc:64

KVShard's constructor takes a KVBucket& as parameter; which is casted
to an EPBucket& if the config indicates persistence is enabled. While
the object /is/ indeed of type EPBucket, KVShard's constructor is
called indirectly from EPBucket's constructor; and as such the
EPBucket object hasn't been fully constructed yet.

To avoid this problem, remove the KVBucket& parameter, and instead
have a seperare, explicit enablePersistence() method which performs
the work which was previously done in the constructor.

Change-Id: Iff1b2bd38c3af257fc51f97de4050da85f3b3ac9
Reviewed-on: http://review.couchbase.org/90927
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Jim Walker <jim@couchbase.com>
Reviewed-by: Tim Bradgate <tim.bradgate@couchbase.com>

show more ...


Revision tags: v5.0.1
# dea18910 25-Oct-2017 Jim Walker <jim@couchbase.com>

MB-26455: Allow correct processing of 'old' keys and separator changes

The collection's separator can only be changed when 0 collections
exist. However nothing stops the separator from c

MB-26455: Allow correct processing of 'old' keys and separator changes

The collection's separator can only be changed when 0 collections
exist. However nothing stops the separator from changing if there are
deleted collections (and their keys) in play.

Prior to this commit each separator change resulted in a single system
event being mutated, that event had a static key. Thus a VB could have
the following sequence of keys/events.

1 fruit::1
2 fruit::2
<fruit collection is deleted>
<separator is changed from :: to - >
<fruit collection is recreated>
6 fruit-1
7 fruit-2
<fruit collection is deleted>
<separator is changed from - to # >
9 $collections_separator (the Item value contains the new separator)
10 $collections::fruit (fruit recreated)
11 fruit#1
12 fruit#2

In this sequence, some of the changes are lost historically because a
static key is used for the separator change. Between seqno 2 and 6 the
separator changed from :: to -, but the separator change system event
is currently at seqno 9 with # as its value.

With this setup a problem exists if we were to process the historical
data e.g. whilst backfilling for DCP or performing a compaction
collection erase. The problem is that when we go back to seqno 1 and
2, we have no knowledge of the separator for those items, all we have
is the current # separator. We cannot determine that fruit::1 is a
fruit collection key.

This commit addresses this problem by making each separator change
generate a unique key. The key itself will encode the new separator,
and because the key is unique it will reside at the correct point in
history for each separator change.

The unique key format will be:

$collections_separator:<seqno>:<new_separator>

With this change the above sequence now looks as:

1 fruit::1
2 fruit::2
<fruit collection is deleted>
4 $collections_separator:3:- (change separator to -)
<fruit collection is recreated>
6 fruit-1
7 fruit-2
<fruit collection is deleted>
9 $collections_separator:8:# (change separator to #)
10 $collections::fruit (fruit recreated)
11 fruit#1
12 fruit#2

Now the code which looks at the historical data (e.g. backfill) will
encounter these separator change keys before it encounters collection
keys using that separator. Backfill and collections-erase can just
maintain a current separator and can now correctly split keys to
discover the collection they belong to. The collections eraser and
KVStore scanning code now include a collections context which has data
and associated code for doing this tracking.

A final piece of the commit is the garbage collection of these unique
keys. i.e. if each separator change puts a unique key into the seqno
index, how can we clean these away when they're no longer needed (i.e.
all fruit:: keys purged)?

Whilst the eraser runs it tracks all 'separator change' keys, because
a separator change can only happen when 0 collections exist, it can
assume that all but the latest separator change key are redundant once
the erase has completed. This list of keys are simply deleted in the
normal way by pushing a deleted Item into the checkpoint once
compaction is complete.

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

show more ...


# 93490825 19-Feb-2018 Dave Rigby <daver@couchbase.com>

Use unique_ptr for Configuration::addValueChangedListener

addValueChangedListener() takes ownership of the passed-in listener
object, but only if the specified key exists in the config.

Use unique_ptr for Configuration::addValueChangedListener

addValueChangedListener() takes ownership of the passed-in listener
object, but only if the specified key exists in the config. If not,
then it results in a memory-leak as the listener object is passed as a
raw pointer.

Fix this problem (and in general make resource ownership more
explicit) by passing by a unique_ptr<>.

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

show more ...


# 4fa49052 05-Dec-2017 Dave Rigby <daver@couchbase.com>

MB-26021 [6/6]: Limit #checkpoint items flushed in a single batch

Expand the previous limiting of flusher batch size to also limit the
number of items from the Checkpoint Manager.

MB-26021 [6/6]: Limit #checkpoint items flushed in a single batch

Expand the previous limiting of flusher batch size to also limit the
number of items from the Checkpoint Manager.

In the case of Checkpoint items, we cannot arbitrarily "cut" the batch
in the middle of a checkpoint - as that would result in an
inconsistent state (non-checkpoint boundary) being written in the
couchstore snapshow. In the event of a crash / restart that wouldn't
be a valid state.

This is implemented by adding a new
CheckpointManager::getItemsForCursor() method; which differs from the
existing get*All*ItemsForCursor() in that it takes an approximate
limit argument. Note this is approximate as we only split the batch at
a checkpoint boundary - the "limit" specifies that we will finish
visiting the current checkpoint, but not visit the next.

Results in the following changes to VBucketBench/FlushVBucket - note
reduction in PeakFlushBytes (from 740M to 7.5M); and average bytes per
item (from 775 to 7) at larger DWQ sizes:

Before:

Run on (8 X 2300 MHz CPU s)
2018-02-16 17:23:25
-----------------------------------------------------------------------------------------
Benchmark Time CPU Iterations
UserCounters...-----------------------------------------------------------------------------------------
VBucketBench/FlushVBucket/1 438175 ns 319992 ns 2239 PeakBytesPerItem=175.266k PeakFlushBytes=175.266k 3.05183k items/s
VBucketBench/FlushVBucket/10 537116 ns 365452 ns 2042 PeakBytesPerItem=18.1953k PeakFlushBytes=181.961k 26.722k items/s
VBucketBench/FlushVBucket/100 928924 ns 724770 ns 1013 PeakBytesPerItem=2.82715k PeakFlushBytes=282.727k 134.741k items/s
VBucketBench/FlushVBucket/1000 4414461 ns 4079710 ns 176 PeakBytesPerItem=1000 PeakFlushBytes=977.438k 239.371k items/s
VBucketBench/FlushVBucket/10000 44486851 ns 43265875 ns 16 PeakBytesPerItem=781 PeakFlushBytes=7.45735M 225.712k items/s
VBucketBench/FlushVBucket/100000 429518562 ns 423825500 ns 2 PeakBytesPerItem=759 PeakFlushBytes=72.427M 230.416k items/s
VBucketBench/FlushVBucket/1000000 4025349877 ns 3942721000 ns 1 PeakBytesPerItem=775 PeakFlushBytes=740.04M 247.687k items/s

After:

Run on (8 X 2300 MHz CPU s)
2018-02-16 17:19:51
-----------------------------------------------------------------------------------------
Benchmark Time CPU Iterations
UserCounters...-----------------------------------------------------------------------------------------
VBucketBench/FlushVBucket/1 479525 ns 340742 ns 2023 PeakBytesPerItem=175.281k PeakFlushBytes=175.281k 2.86599k items/s
VBucketBench/FlushVBucket/10 526072 ns 375763 ns 1868 PeakBytesPerItem=18.1943k PeakFlushBytes=181.945k 25.9888k items/s
VBucketBench/FlushVBucket/100 981275 ns 721473 ns 1003 PeakBytesPerItem=2.82617k PeakFlushBytes=282.711k 135.357k items/s
VBucketBench/FlushVBucket/1000 4459568 ns 4118994 ns 173 PeakBytesPerItem=1000 PeakFlushBytes=977.438k 237.088k items/s
VBucketBench/FlushVBucket/10000 45353759 ns 44451063 ns 16 PeakBytesPerItem=781 PeakFlushBytes=7.45737M 219.694k items/s
VBucketBench/FlushVBucket/100000 414823038 ns 406181000 ns 2 PeakBytesPerItem=137 PeakFlushBytes=13.0832M 240.425k items/s
VBucketBench/FlushVBucket/1000000 3116659340 ns 3000999000 ns 1 PeakBytesPerItem=7 PeakFlushBytes=7.57903M 325.412k items/s

Change-Id: I2d3c618557f3f5928879f09f7cba58968abd04db
Reviewed-on: http://review.couchbase.org/86391
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Paolo Cocchi <paolo.cocchi@couchbase.com>

show more ...


# d0767a8e 16-Feb-2018 Dave Rigby <daver@couchbase.com>

MB-26021 [3/6]: Rename flusher{_backfill_batch_limit -> _batch_split_trigger}

The splitting of flusher commits will be extended to include items
from checkpoints where possible - if ther

MB-26021 [3/6]: Rename flusher{_backfill_batch_limit -> _batch_split_trigger}

The splitting of flusher commits will be extended to include items
from checkpoints where possible - if there are multiple checkpoints
and flushing the first checkpoint would exceed the batch limit then we
will split the commit into multiple. However, checkpoints are
indivisible - we need to flush a complete checkpoint to maintain
consistency. As such, any limit we specify will be approximate; as we
cannot know exactly how many items will be in each batch.

Rename flusher_backfill_batch_limit to flusher_batch_split_trigger and
update documentation, to better reflect the new semantics of the
setting.

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

show more ...


# d6d065d5 05-Dec-2017 Dave Rigby <daver@couchbase.com>

MB-26021 [1/6]: Limit #backfill items flushed in a single batch

Add a new configuration parameter - flusher_backfill_batch_limit -
which allows the flusher to contrain how many backfill

MB-26021 [1/6]: Limit #backfill items flushed in a single batch

Add a new configuration parameter - flusher_backfill_batch_limit -
which allows the flusher to contrain how many backfill items will be
flushed in a single batch. This defaults to zero, which means no limit
and hence behaves as previously.

If a non-zero value is specified then no more than that number of
backfill items will be added to a single vBucket flusher commit; the
given vBucket will be flagged to indicate there's more data available
and hence flusher should be re-scheduled.

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

show more ...


Revision tags: v5.1.0
# 3c8b5eb6 19-Oct-2017 Dave Rigby <daver@couchbase.com>

MB-27554: [BP] Move numTotalItems from HashTable -> VBucket

Originally 04d6809a142a90a6bd8ddbd66e5109925b2b8f12

In Full-Eviction, items may exist in a VBucket without being in the

MB-27554: [BP] Move numTotalItems from HashTable -> VBucket

Originally 04d6809a142a90a6bd8ddbd66e5109925b2b8f12

In Full-Eviction, items may exist in a VBucket without being in the
HashTable, as they may have been fully evicted. As such, numTotalItems
is not a property of the HashTable, it is a property of the VBucket.

Therefore move numTotalItems from HashTable to VBucket, to better
encapsulate the VBucket's state.

Change-Id: Ic45de1ee49468753d7cc76804f8c5cc9eb64f881
Reviewed-on: http://review.couchbase.org/88381
Well-Formed: Build Bot <build@couchbase.com>
Reviewed-by: Jim Walker <jim@couchbase.com>
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Dave Rigby <daver@couchbase.com>

show more ...


# 46152ca1 19-Oct-2017 Dave Rigby <daver@couchbase.com>

MB-27554: [BP] Don't over-count VBucket item counts

Originally 526b3f4e2d4f36e35eead280ceb2c515dc3e5362

TODO: Check what happens in FE if an item is created and deleted in
the s

MB-27554: [BP] Don't over-count VBucket item counts

Originally 526b3f4e2d4f36e35eead280ceb2c515dc3e5362

TODO: Check what happens in FE if an item is created and deleted in
the same flusher step - I believe the create will be de-duplicated
with the delete; so only the delete persistence callback will run. In
that case I think the item count may be incorrect - or at the very
least it may require newCacheItem to handle it correctly.

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

show more ...


# 1ff902e5 12-Oct-2017 Dave Rigby <daver@couchbase.com>

MB-27554: [BP] Move flushing code from KVBucket to EPBucket

Originally d440338b81a768e58ccd6237b2d64fae8a8f78ea

flushVBucket and related code is only applicable to EP buckets, not t

MB-27554: [BP] Move flushing code from KVBucket to EPBucket

Originally d440338b81a768e58ccd6237b2d64fae8a8f78ea

flushVBucket and related code is only applicable to EP buckets, not to
Ephemeral buckets. As such, move all the flushing code from KVBucket
to EPBucket class.

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

show more ...


Revision tags: v5.0.0
# fe355bc9 29-Jun-2017 Dave Rigby <daver@couchbase.com>

MB-27554: [BP] Move compaction code from KVBucket to EPBucket

Originally 94359a450394f005a6be8401aa00d10743951708

Compaction isn't applicable to all subclasses of KVBucket - Ephemer

MB-27554: [BP] Move compaction code from KVBucket to EPBucket

Originally 94359a450394f005a6be8401aa00d10743951708

Compaction isn't applicable to all subclasses of KVBucket - Ephemeral
buckets don't have any disk files to compact.

As such, move compaction-related code from the KVBucket class to the
EPBucket subclass.

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

show more ...


# cf32544c 19-Jan-2018 Dave Rigby <daver@couchbase.com>

Rollback: Add additional comments to rollback flow

Change-Id: I614212ec826f516c5853a43caecb6fb68c7e0326
Reviewed-on: http://review.couchbase.org/88093
Tested-by: Build Bot <build@cou

Rollback: Add additional comments to rollback flow

Change-Id: I614212ec826f516c5853a43caecb6fb68c7e0326
Reviewed-on: http://review.couchbase.org/88093
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Tim Bradgate <tim.bradgate@couchbase.com>

show more ...


# fdd7414e 09-Jan-2018 Jim Walker <jim@couchbase.com>

MB-25631: Log more details about compaction

Add code so that we can track (via logging)

* tombstones purged
* items erased by collections
* pre/post size, items, deleted ite

MB-25631: Log more details about compaction

Add code so that we can track (via logging)

* tombstones purged
* items erased by collections
* pre/post size, items, deleted items and purge seqno

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

show more ...


# 5ecba1e7 01-Dec-2017 Dave Rigby <daver@couchbase.com>

MB-26021: Add TransactionContext to KVStore [2/2]

Use the new TransactionContext functionality to hold the ep-engine
context which is common to all requests in a transaction - the vbucke

MB-26021: Add TransactionContext to KVStore [2/2]

Use the new TransactionContext functionality to hold the ep-engine
context which is common to all requests in a transaction - the vbucket
and the stats to update.

This reduces the size of all PersistenceCallback objects by 24 byres -
from 72 to 48.

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

show more ...


# bc646842 01-Dec-2017 Dave Rigby <daver@couchbase.com>

MB-26021: Add TransactionContext to KVStore [1/2]

When commiting a transaction in the KVStores, various state needs to
be maintained to ensure that ep-engine is called back when items ha

MB-26021: Add TransactionContext to KVStore [1/2]

When commiting a transaction in the KVStores, various state needs to
be maintained to ensure that ep-engine is called back when items have
successfully been persisted to disk. This is typically handled by the
store maintaining a container of PersistenceCallback objects to be
invoked when the transactionis commited. However much of the state of
PersistenceCallback is identical across all operations in a commit -
for example the VBucket, the Stats object to update.

To reduce the memory cost of maintaing this state, introduce a new
TransactionContext object. Callers of KVStore pass an instance of this
into begin(), and it is owned by the KVStore until commit() or
rollback() is called. Upon commit, all PersistenceCallacks are invoked
with a reference to the TransactionContext; allowing them to make use
of the state stored there.

This initial patch just adds the instructure for the
TransactionContext; it is not yet used by ep-engine.

Change-Id: I8c3704c968270a871849e9c6b5efda22b221d79b
Reviewed-on: http://review.couchbase.org/86285
Reviewed-by: Daniel Owen <owend@couchbase.com>
Tested-by: Build Bot <build@couchbase.com>

show more ...


# 99073f39 30-Nov-2017 Dave Rigby <daver@couchbase.com>

MB-26021: Change persistenceCb from list to deque<unique_ptr>

This both simplies the implementation (no manual deletion needed); and
uses fewer resources - overhead of just 1 ptr per ele

MB-26021: Change persistenceCb from list to deque<unique_ptr>

This both simplies the implementation (no manual deletion needed); and
uses fewer resources - overhead of just 1 ptr per element, compared to
3 for a std::list.

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

show more ...


# 04d6809a 19-Oct-2017 Dave Rigby <daver@couchbase.com>

Move numTotalItems from HashTable -> VBucket

In Full-Eviction, items may exist in a VBucket without being in the
HashTable, as they may have been fully evicted. As such, numTotalItems

Move numTotalItems from HashTable -> VBucket

In Full-Eviction, items may exist in a VBucket without being in the
HashTable, as they may have been fully evicted. As such, numTotalItems
is not a property of the HashTable, it is a property of the VBucket.

Therefore move numTotalItems from HashTable to VBucket, to better
encapsulate the VBucket's state.

Change-Id: I9d016fd45f393c4d678325471da429dfc1b6d0de
Reviewed-on: http://review.couchbase.org/84883
Reviewed-by: Sriram Ganesan <sriram@couchbase.com>
Tested-by: Build Bot <build@couchbase.com>

show more ...


# 8b25bbfd 24-Oct-2017 Eugen-Alexandru Virtan <eugen.virtan@couchbase.com>

MB-26047:[7-a] Change all stats histograms to use <chrono> durations

Part of a cross repo change.

Replace Histogram<hrtime_t> with MicrosecondHistogram and refactor
realted code

MB-26047:[7-a] Change all stats histograms to use <chrono> durations

Part of a cross repo change.

Replace Histogram<hrtime_t> with MicrosecondHistogram and refactor
realted code to work with durations.
Change various add_stat methods to accomodate the new changes to
templates introduced in histogram.h by the new patch in platform.

Change-Id: Ic061e11a79b09663b980e173dc4191d46d5aa35d
Reviewed-on: http://review.couchbase.org/84743
Reviewed-by: Dave Rigby <daver@couchbase.com>
Tested-by: Dave Rigby <daver@couchbase.com>

show more ...


# 526b3f4e 19-Oct-2017 Dave Rigby <daver@couchbase.com>

MB-266567: Don't over-count VBucket item counts

TODO: Check what happens in FE if an item is created and deleted in
the same flusher step - I believe the create will be de-duplicated

MB-266567: Don't over-count VBucket item counts

TODO: Check what happens in FE if an item is created and deleted in
the same flusher step - I believe the create will be de-duplicated
with the delete; so only the delete persistence callback will run. In
that case I think the item count may be incorrect - or at the very
least it may require newCacheItem to handle it correctly.

Change-Id: I20b53b2c475c75382b84ecad434cf8eabb891378
Reviewed-on: http://review.couchbase.org/84881
Reviewed-by: Daniel Owen <owend@couchbase.com>
Tested-by: Build Bot <build@couchbase.com>

show more ...


# d440338b 12-Oct-2017 Dave Rigby <daver@couchbase.com>

Move flushing code from KVBucket to EPBucket

flushVBucket and related code is only applicable to EP buckets, not to
Ephemeral buckets. As such, move all the flushing code from KVBucket

Move flushing code from KVBucket to EPBucket

flushVBucket and related code is only applicable to EP buckets, not to
Ephemeral buckets. As such, move all the flushing code from KVBucket
to EPBucket class.

Change-Id: I882b7abf25ccf27aa279a13a3bb5d315d605649f
Reviewed-on: http://review.couchbase.org/84880
Reviewed-by: Daniel Owen <owend@couchbase.com>
Tested-by: Build Bot <build@couchbase.com>

show more ...


# a33e0978 20-Sep-2017 Jim Walker <jim@couchbase.com>

MB-25342: Erase deleted collection keys during in compaction

Add a new call back (using std::function) so that the compactor can
check if a key belongs to a deleted collection and should

MB-25342: Erase deleted collection keys during in compaction

Add a new call back (using std::function) so that the compactor can
check if a key belongs to a deleted collection and should be dropped
from the database.

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

show more ...


# 9f926fba 25-Aug-2017 Dave Rigby <daver@couchbase.com>

KVBucket: Use LockedVBucketPtr instead of direct use of vb_mutexes

Use the new RAII-style LockedVBucketPtr class for instances where we
need to acquire both a VBucketPtr and the associat

KVBucket: Use LockedVBucketPtr instead of direct use of vb_mutexes

Use the new RAII-style LockedVBucketPtr class for instances where we
need to acquire both a VBucketPtr and the associated vb_mutex.

In some instances we only want to attempt to lock the mutex, to
support this add a new variant of getLockedVBucket which will not
block (and return false) if the mutex could not be acquired.

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

show more ...


1234