MB-37529: Permit locking of multiple ranges of seqList

Backfilling from the seqList requires a range of items to be
"protected" from being updated and moved during the lifetime of the

MB-37529: Permit locking of multiple ranges of seqList

Backfilling from the seqList requires a range of items to be
"protected" from being updated and moved during the lifetime of the
backfill. This is to ensure the resulting set of items is consistent at
the end of the backfill.

To do this, backfills take a range read marking seqnos X to Y, and
front end ops will not relocate items from inside this range. Instead,
a new item will be appended, and the old one marked as stale, to be
cleaned up later after the backfill has completed.

However, previously only a single range read was allowed at a given
time. This means that an ephemeral vbucket can only serve a single
backfill at a time, all others will be delayed. This can have a
significant impact, given that a vbucket might need to backfill for 3
replicas, indexer nodes, the projector for XCDR etc. all at the same
time. This is made more likely under high memory usage, if cursor
dropping is triggered (as in-memory streams will be forced back to
backfill).

This patch allows concurrent read-only access to ranges of the seqList,
allowing concurrent backfills.

There is also specific support for exclusive write access to ranges of
the seqList; this is required for tombstone purging. Exclusive range
locks block shared range locks that would overlap the exclusive range.
Exclusive locks will not succeed if a shared range lock exists which
would overlap it.

As described above, range locks still do not block front end ops.

The "locking" is read-preferring; as a consequence the tombstone purger
will be prevented from locking the needed seqno range as long as a
single backfill holds a lock covering any of those seqnos. As constant
backfills are not normally expected read-preference is acceptable for
now. However, given the importance of purging tombstones/stale items in
terms of managing memory usage (as noted briefly in MB-25218)
write-preference in this situation may be worth assessing.

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

show more ...

Remove config.h

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

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

MB-30552: Convert type of vBucket id's from uint16_t to Vbid [8/n]

(Stage 8 of n) This commit changes to the type of Vbid for
ep's tests, including mock.
Vbid allows greater control

MB-30552: Convert type of vBucket id's from uint16_t to Vbid [8/n]

(Stage 8 of n) This commit changes to the type of Vbid for
ep's tests, including mock.
Vbid allows greater control over what operations can be performed
on a vBucket id, as well as ensuring the output formatting is
consistent. To support the splitting of this into multiple stages,
Vbid can currently be implicitly converted back to uint16_t to
cover elements that have not yet been converted. During this,
there may be logs or prints with "vb:vb:", which should be fixed
within this set of changes.

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

show more ...

Move ep-engine to engines/ep

MB-24246: Combine 'writeLock' & 'highSeqnosLock' into one in BasicLinkedList

Functionally 'writeLock' and 'highSeqnosLock' both result in the
serialization of the BasicLinkedList write a

MB-24246: Combine 'writeLock' & 'highSeqnosLock' into one in BasicLinkedList

Functionally 'writeLock' and 'highSeqnosLock' both result in the
serialization of the BasicLinkedList write and other list operations.
Hence this commit combines the 2 locks into one lock.

As a consequence this commit ensures that the writeLock is held on
the BasicLinkedList until the sequence number for the newly added,
updated and soft-deleted is generated. While this is strictly not
needed in new add, it is necessary in update and soft delete as
explained below.

(a) New Add :
A1, B2, C3 and we are trying to add D4
A1, B2, C3, D? added but no seqno yet.
Now we don't really care if range read starts here as it can read
only A1, B2, C3 in the snapshot.

But to maintain uniformity (hence simpler code) with update
and soft-delete we grab writeLock such that we append to list
+ update highSeqno as an atomic operation.

(b) Update (and Soft-delete):
A1, B2, C3 and we are trying to update B to B4
A1, B2, C3, B? added but no seqno yet and/or no B2_stale yet
Now we cannot start the range read here because we do not wait
for range read to finish to mark the item stale (note that we
are planning to not send stale(duplicate) items in a snapshot).

This was already in case (b) using highSeqnosLock, this commit
uses just writeLock for the same.

The commit also adds documentation regarding the desired heirarchy of
the lock acquisition in BasicLinkedList.

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

show more ...

Fix typo in MockBasicLinkedList::getWriteLock

Change-Id: I7f7ceda0195549b89e3b317224c2eeebf80153b4
Reviewed-on: http://review.couchbase.org/76777
Reviewed-by: Manu Dhundi <manu@couch

Fix typo in MockBasicLinkedList::getWriteLock

Change-Id: I7f7ceda0195549b89e3b317224c2eeebf80153b4
Reviewed-on: http://review.couchbase.org/76777
Reviewed-by: Manu Dhundi <manu@couchbase.com>
Tested-by: Build Bot <build@couchbase.com>

show more ...

MB-23795: Ephemeral Tombstone purging (VBucket-level)

Add Ephemeral Tombstone purging for Ephemeral VBuckets. This patch
adds two purge operations - one for the HashTable, and one for th

MB-23795: Ephemeral Tombstone purging (VBucket-level)

Add Ephemeral Tombstone purging for Ephemeral VBuckets. This patch
adds two purge operations - one for the HashTable, and one for the
sequenceList:

a) The HashTable visitor (EphemeralVBucket::HTTombstonePurger) visits
all items in the HashTable, and identifies any deletes which are
old enough to be purged (age > ephemeral_metadata_purge_age). Such
items are marked as stale, and transferred from the HashTable to
the SequenceList.

b) The SequenceList purger (BasicLinkedList::purgeTombstones()) then
iterates over the sequencelist, and hard-deletes any items marked
stale - both Alive and Deleted items. It is at this stage that the
OSVs are actually deleted.

Note the SequenceList purging is somewhat delicate, to ensure
correctness while not blocking front-end writes. See the inline
comments in BasicLinkedList::purgeTombstones() for further details.

Note this isn't yet driven by any tasks - only by the unit
tests. Subsequent patches will connect into tasks.

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

show more ...

MB-23795: Move StoredValue::stale to OSV; guard with SeqList::writeLock

The stale flag in (Ordered)StoredValue needs to be read by the
tombstone purger when iterating the sequenceList; h

MB-23795: Move StoredValue::stale to OSV; guard with SeqList::writeLock

The stale flag in (Ordered)StoredValue needs to be read by the
tombstone purger when iterating the sequenceList; however at this
point there is no HashTable lock available - the OSV has been released
from the hashTable and hence we have no way to determine it's bucket
(without reading the key to recalculate - and that's not possible
without first acquiring the lock!).

To allow us to safely access the stale flag, move it from being
protected by the HT locks to the SequenceList::writeLock, and move to
OSV so it doesn't share with the other bitfields in the same
byte. While on the face of it this might seen like a serious
performance degredation having to serialise on a single lock, it
actually doesn't appear to be /that/ bad:

1) The stale flag is only accessed rarely:

a) Set to false when a StoredValue is initially created (and this
doesn't need the lock as the item isn't in the SeqList yet)

b) Set to true when an item becomes stale (result of concurrent
update & rangeRead, or deleted item is aged out and marked Stale).

c) Read during tombStone purging.

2) Even when we *do* need to access the stale flag, we have already
acquired the writeLock in the hot path
(updateStoredValue/markItemStale).

Note: This will increase contention during a tombstone purge, as it
will need to acquire and release the writeLock for every seqList
element; this is an area which should be looked at for future
performance improvement - for example can the stale flag be made
atomic, or can we add lightweight, per-OSV lock?

Note(2): This increases the size of OSV by 8 bytes, as moving Stale to
it pushes up the alignment requirements (it was previously aligned to
8 bytes), although we've only added 1 bit to it. Better solution would
be to pack this into the boost_list hook, // or introduce per-OSV
microlock to guard the whole object.

Change-Id: If814b966a10c64fada204998410dafc5ad255351
Reviewed-on: http://review.couchbase.org/76715
Reviewed-by: Jim Walker <jim@couchbase.com>
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Manu Dhundi <manu@couchbase.com>

show more ...

MB-23435: [Ephemeral] Add seqlist statistics

Add per-vBucket sequence list statistics for Ephemeral buckets:

* seqlist_count - number of documents in this VBucket's sequence list.

MB-23435: [Ephemeral] Add seqlist statistics

Add per-vBucket sequence list statistics for Ephemeral buckets:

* seqlist_count - number of documents in this VBucket's sequence list.

* seqlist_deleted_count - Count of deleted documents in this VBucket's
sequence list.

* seqlist_high_seqno - High sequence number in sequence list for this
VBucket. We need to keep track of the highest seqno separately
because there is a small window wherein the last element of the list
(though in correct order) does not have a seqno. High seqno is
monotonically increasing and is reset to a lower value only in case
of a rollback.

* seqlist_highest_deduped_seqno - Highest de-duplicated sequence
number in sequence list for this VBucket. We need to this to send
out point-in-time snapshots in range read. highest_deduped_seqno is
monotonically increasing and is reset to a lower value only in case
of a rollback.

* seqlist_read_range_begin - Starting sequence number for this
VBucket's sequence list read range. Marks the lower bound of
possible stale documents in the sequence list.

* seqlist_read_range_end - Ending sequence number for this VBucket's
sequence list read range. Marks the upper bound of possible stale
documents in the sequence list.

* seqlist_read_range_count - Count of elements for this VBucket's
sequence list read range (i.e. end - begin).

* seqlist_stale_count - Count of stale documents in this VBucket's
sequence list.

* seqlist_stale_value_bytes - Number of bytes of stale values in this
VBucket's sequence list.

* seqlist_stale_metadata_bytes - Number of bytes of stale metadata
(key + fixed metadata) in this VBucket's sequence list.

Change-Id: Ia4e3ee062185e162fd8d1386edcd34724768a78f
Reviewed-on: http://review.couchbase.org/75501
Reviewed-by: Manu Dhundi <manu@couchbase.com>
Tested-by: Build Bot <build@couchbase.com>

show more ...

[Ephemeral]: Track memory usage of the items owned by the sequence list

In ephemeral buckets we can have stale items which are not owned by the
hash table, but owned by the sequence list

[Ephemeral]: Track memory usage of the items owned by the sequence list

In ephemeral buckets we can have stale items which are not owned by the
hash table, but owned by the sequence list. We need to track the
memory usage of these items in the list for overall memory tracking.

This commit only tracks memory used in the list. This is yet to be
exported out to all the necessary global stats.

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

show more ...

[Ephemeral Bucket]: Allow updates on sequential storage (linkedlist)

When an item in hashtable (in an Ephemeral vbucket) is updated, the
updated item must be placed in the right position

[Ephemeral Bucket]: Allow updates on sequential storage (linkedlist)

When an item in hashtable (in an Ephemeral vbucket) is updated, the
updated item must be placed in the right position (at the end) in
the sequential storage data structure, linkedlist.

If there are no range reads (backfills) during an update we just
update the hash table element and move the item to the end of the
list. This is somewhat similar (hashtable part) to what happens in
current ep vbuckets.

However, in case of range reads (backfills), the behavior is
different w.r.t existing ep vbuckets. The range reads are
basically point-in-time snapshots and hence require the older
(non updated) item to be there in the range of the read. But the
hashtable wants to store only the most recent (updated) item.
Hence, we mark the item as stale and transfer the ownership of the
item to the linkedlist from hashtable and add a new item with the
value of update in the hashtable and at the end of the list.

We have the module tests at the linkedlist level. Module tests at
the ephemeral vbucket level will follow soon in a future commit.

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

show more ...

[Ephemeral Bucket]: Add point-in-time snapshot rangeRead on LinkedList

Monotonically point-in-time snapshots which can be used for
incremental DCP. This is implemented in the sequential

[Ephemeral Bucket]: Add point-in-time snapshot rangeRead on LinkedList

Monotonically point-in-time snapshots which can be used for
incremental DCP. This is implemented in the sequential data structure
'BasicLinkedList' in EphemeralVBuckets. This is equivalent to DCP disk
backfill in Couchbase buckets.

To get a point-in-time snapshot from the list, the main requirement is
no de-deduplication be allowed on the list in the range where the read
for the snapshot is happening. We achieve it by not blocking
the writes on the list during the time of the range read.

This commit implements only the range read part. The non-blocking
write during a range read will be evident with implementation of
updateListElem in an upcoming commit.

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

show more ...

[Ephemeral Bucket]: Add a class for ordered sequence of items in memory

This commit adds an abstract base class 'SequenceList' that provides
apis to store ordered sequence of items (Stor

[Ephemeral Bucket]: Add a class for ordered sequence of items in memory

This commit adds an abstract base class 'SequenceList' that provides
apis to store ordered sequence of items (StoredValues) in memory in our
multi-threaded, monotonically increasing seq model.

It also adds 'BasicLinkedList', a concrete class that implements
SequenceList. 'BasicLinkedList' uses a boost intrusive doubly linked
list. It is essentially a linked list of 'StoredValues'.

Currently, only appendToList() functionality is implemented. But the
goal is, 'BasicLinkedList' works in tandem with already existing
'HashTable' to achieve O(1) writes/updates, O(1) reads and range reads.
Range read is necessary for an in-memory DCP backfill. Range reads
provide point-in-time snapshots which is essential for our incremental
DCP.

And a module test is added as well.

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

show more ...

Cleanup #include usage in headers (2)

Further cleanup of unnecessary #includes in headers

Change-Id: I31c74ffc2ed477f66c0ff955e706b069d06b99a8
Reviewed-on: http://review.couchba

Cleanup #include usage in headers (2)

Further cleanup of unnecessary #includes in headers

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

show more ...

[2/4] Ephemeral class shuffle: Rename class KVBucket to KVBucketIface

This makes room in the class hierarchy for a new concrete KVBucket
class.

Change-Id: I0c51be43907efa0f2b023

[2/4] Ephemeral class shuffle: Rename class KVBucket to KVBucketIface

This makes room in the class hierarchy for a new concrete KVBucket
class.

Change-Id: I0c51be43907efa0f2b02305a2f6faee892170c46
Reviewed-on: http://review.couchbase.org/71103
Tested-by: buildbot <build@couchbase.com>
Reviewed-by: Jim Walker <jim@couchbase.com>

show more ...

[1/4] Ephemeral class shuffle: Move kvbucket.h to kv_bucket_iface.h

The current class hierarchy for Bucket classes in ep-engine looks
like:

KVBucket - pure

[1/4] Ephemeral class shuffle: Move kvbucket.h to kv_bucket_iface.h

The current class hierarchy for Bucket classes in ep-engine looks
like:

KVBucket - pure interface
^
|
EPBucket - concrete, all code

To add support for Ephemeral buckets, we want to create a new
EphemeralBucket class. This is expected to share a majority of its
code with EPBucket (VBuckets, DCP, rebalance, failover), but with
significant changes (no storage, HashTable is ordered).

As such, we want to be able to share the majority of the current
EPBucket's code, but also deviate where necessary. This suggests an
inheritance heirarchy of:

KVBucketIface - pure interface
^
|
KVBucket - shared code
^
|
/----------------------------\
| |
EPBucket EphemeralBucket

Where each subclass contains the class-specific code, and common code
present in the parent class.

However, it is desirable to maintain as much history in Git as
possible - Git has poor handling of moves of individual pieces of
code, and if we simply created a new shared parent class - KVBucket -
and moved big chunks of code from EPBucket into KVBucket we'd likely
cause many merge conflicts in future.

It is preferable to instead break the change into a series of smaller
patches, where we rename complete files in one patch (which Git
handles very well), and then rename classes (i.e. make code changes)
in a seperate patch.

Therefore this patch is the first of a series of four:

1. Move kvbucket.h to kv_bucket_iface.h (this patch) - change no code,
but move the file which is logically the abstract base class to the
correct filename.

2. Rename class KVBucket to KVBucketIface - "make room" in the class
hierarchy for a new concrete KVBucket class.

3. Move ep.{ccm,h} -> kv_bucket.{cc,h} - change no code, but move the
file which is to become the new shared parent class to the correct
filename.

4. Rename class EPBucket -> KVBucket - Finally rename the code which
is the shared parent class to the correct name.

Change-Id: Ifc06785b3c32a4ccc79f903c1fd37d476b879fd9
Reviewed-on: http://review.couchbase.org/71102
Reviewed-by: Sriram Ganesan <sriram@couchbase.com>
Reviewed-by: Manu Dhundi <manu@couchbase.com>
Tested-by: buildbot <build@couchbase.com>
Reviewed-by: Jim Walker <jim@couchbase.com>

show more ...

[Ephemeral Bucket]: Create an abstract base class KVBucket

Currently “EventuallyPersistentStore” is the class that engineers the
couchbase bucket behavior in the kv-engine. It
(i) ha

[Ephemeral Bucket]: Create an abstract base class KVBucket

Currently “EventuallyPersistentStore” is the class that engineers the
couchbase bucket behavior in the kv-engine. It
(i) handles get/set requests, any spl requests defined in our protocol,
(ii) spawns tasks like flusher, bgfetcher, pager, access scanner etc
(iii) sets up config params for DCP, HT, Vbucket
(iv) interactions with KV store (say forestdb or couchstore) for
persistence, vb snapshotting, rollback etc and many more

Ephemeral bucket is a new bucket type and it has some similar but
many distinct features w.r.t couchbase bucket. For example we
(i) do not need flusher, bgfetcher tasks
(ii) handle get/sets differently as we do not have anything called
full eviction/value eviction and hence no bloom filters
(iii) No KV store (storage) interactions
(iv) use modified HT+ skiplist structures to store/get items.

Hence it is a good idea to derive new class “EphemeralBucket” and
“EventuallyPersistentStore” as peer subclasses from the base class
“KVBucket”.

This commit just creates the abstract base class and makes the
the clients of EventuallyPersistentStore which are expected to be
clients of EphemeralStore as well to use base class KVBucket.

Subsequent commits will add "EphemeralBucket" class and
rename "EventuallyPersistentStore" to "EPBucket".

Change-Id: Ia1e403b4c718d8ee8abd84316287d58743397cf8
Reviewed-on: http://review.couchbase.org/68671
Tested-by: buildbot <build@couchbase.com>
Reviewed-by: Dave Rigby <daver@couchbase.com>

show more ...

MB-18453: Give all tasks their own stats and priority

MB-18453 identified that tasks have copied & pasted
constructors which leads to some tasks all having the
same Priority object.

MB-18453: Give all tasks their own stats and priority

MB-18453 identified that tasks have copied & pasted
constructors which leads to some tasks all having the
same Priority object.

The fallout of this is that many tasks now all contribute
to the same histogram for runtime and scheduling waittime.
When debugging issues which lead to MB-18453 it is near
impossible at times to know which real task was delayed
as the stats can be attributed to many tasks.

This commit introduces makes all tasks have their own ID
and thus their own histograms and also makes it easier
for new tasks to be created without forgetting to create
a new Priority instance.

tasks.defs.h is a new file that captures every sub-class
of GlobalTask and shows the priority of all tasks.

TASK macros are now used to generate various switch
statements and enums used in task accounting.

The new system is not strict, MyTask could still be
assigned the priority/id of OldTask, however this
flexibility can be useful in some circumstances.

Note this patch has changed ep_testsuite test_item_pager
to increase the max_size value in the test config. This
is because this patch increases the baseline heap usage
of a bucket as we've increased the number of Histogram
object allocated by EventuallyPersistentStore.

Prior to this patch 28 were allocated, with this patch
51 are allocated (1 per task). Each Histogram<hrtime_t
is approx 1568 bytes (on OSX clang build).

The new max_size is 2.5MiB

Change-Id: I209c67945b964023615af37a12f83ca97142ce53
Reviewed-on: http://review.couchbase.org/65253
Well-Formed: buildbot <build@couchbase.com>
Reviewed-by: Dave Rigby <daver@couchbase.com>
Tested-by: buildbot <build@couchbase.com>

show more ...

Simplify common.h: Remove unnecessary headers [3/3]

Remove all #includes which arn't actually needed by the file including
them (aka "include what you use").

Reduces build time

Simplify common.h: Remove unnecessary headers [3/3]

Remove all #includes which arn't actually needed by the file including
them (aka "include what you use").

Reduces build time down from before this patch series from:

31.82 real 222.13 user 16.09 sys

down to:

26.95 real 188.54 user 13.29 sys

giving a 15% speedup in (user+sys).

(Built using `make clean && CCACHE_DISABLE=1 time make -j8`)

Change-Id: Ia47f08487d20c94167d93de8dd6590f7703dd898
Reviewed-on: http://review.couchbase.org/56705
Tested-by: buildbot <build@couchbase.com>
Reviewed-by: Manu Dhundi <manu@couchbase.com>
Reviewed-by: Chiyoung Seo <chiyoung@couchbase.com>

show more ...

Refactor: Move ExecutorThread to its own file

Change-Id: I7e8d2049aac7fefa2289d9a4f171aafdb840d267
Reviewed-on: http://review.couchbase.org/31725
Reviewed-by: Sundararaman Sridharan

Refactor: Move ExecutorThread to its own file

Change-Id: I7e8d2049aac7fefa2289d9a4f171aafdb840d267
Reviewed-on: http://review.couchbase.org/31725
Reviewed-by: Sundararaman Sridharan <sundar.sridharan@gmail.com>
Tested-by: Sundararaman Sridharan <sundar.sridharan@gmail.com>

show more ...

CBD-1148: Migrate all NonIO tasks into Common Pool

This removes per-bucket threads from the NonIO dispatcher
into the global thread pool shared by all buckets
Following tasks handled

CBD-1148: Migrate all NonIO tasks into Common Pool

This removes per-bucket threads from the NonIO dispatcher
into the global thread pool shared by all buckets
Following tasks handled by the non-io thread are now migrated
into the common shared thread pool...
1) Backfill task
2) Hash Table Resizer
3) Checkpoint remover
4) ExpiredItemPager
5) Item Pager
6) VBCBAdaptor (async task spawned by daemon tasks 1-4)
7) Tap Connection Notification (daemon task)
8) Tap Resume
9) Tap Connection Reaper
10) VBucket Memory Deletion
11) FlushAll task
12) Checkpoint Stats
Also removed isDaemon and makes GlobalTask's starttime internal
Allow new api in ExecutorPool to stop a task group entirely
Change-Id: Ic5cbbfb6d1a140335b0ff1a7c7dc31e20ca47186
Reviewed-on: http://review.couchbase.org/30775
Reviewed-by: Chiyoung Seo <chiyoung@couchbase.com>
Tested-by: Chiyoung Seo <chiyoung@couchbase.com>

show more ...

MB-7728: Add copyright headers to all files

This is something that our cpplint tool turns on and it makes
our product look a little bit more profesional. I have also
enabled the tool

MB-7728: Add copyright headers to all files

This is something that our cpplint tool turns on and it makes
our product look a little bit more profesional. I have also
enabled the tool to begin checking for these headers so it will
start complaining if we add a new file without a copyright header.

Change-Id: Ie956fdf7027bf56d9665ee455acd3c109fcacc76
Reviewed-on: http://review.couchbase.org/24560
Reviewed-by: Chiyoung Seo <chiyoung.seo@gmail.com>
Reviewed-by: Jin Lim <jin@couchbase.com>
Tested-by: Michael Wiederhold <mike@couchbase.com>

show more ...

MB-7461: Alphabetize includes to conform with c++ standards

Change-Id: I71333dedada6530713b90184857bab9ac49d13df
Reviewed-on: http://review.couchbase.org/23515
Reviewed-by: Jin Lim <

MB-7461: Alphabetize includes to conform with c++ standards

Change-Id: I71333dedada6530713b90184857bab9ac49d13df
Reviewed-on: http://review.couchbase.org/23515
Reviewed-by: Jin Lim <jin@couchbase.com>
Tested-by: Michael Wiederhold <mike@couchbase.com>

show more ...

MB-7426: Fix all header defines to conform with cpplint

Change-Id: I8253b640bc49ee8a0fabbb39ece73c2efdb906d5
Reviewed-on: http://review.couchbase.org/23510
Reviewed-by: Michael Wiede

MB-7426: Fix all header defines to conform with cpplint

Change-Id: I8253b640bc49ee8a0fabbb39ece73c2efdb906d5
Reviewed-on: http://review.couchbase.org/23510
Reviewed-by: Michael Wiederhold <mike@couchbase.com>
Tested-by: Michael Wiederhold <mike@couchbase.com>

show more ...

MB-7405: Make extension for all header files .h

Change-Id: I7badb1e71c038b6498296c2893ccdbd47c2f0f87
Reviewed-on: http://review.couchbase.org/23483
Reviewed-by: Michael Wiederhold <m

MB-7405: Make extension for all header files .h

Change-Id: I7badb1e71c038b6498296c2893ccdbd47c2f0f87
Reviewed-on: http://review.couchbase.org/23483
Reviewed-by: Michael Wiederhold <mike@couchbase.com>
Tested-by: Michael Wiederhold <mike@couchbase.com>

show more ...