MB-12398: log incorrect timeout values

The loglevel DEBUG won't appear in any logs, so customers using
this in production won't get the information anywhere (the server
just change their requested lock time without telling the user).

I guess a better behavior here would be to return ERANGE in
this case, but that would potentially break user applications
and isn't something we should do in a patch revision.

Change-Id: Ib6a37deceb2755b9fea53b0542a13fb2e16a3261
Reviewed-on: http://review.couchbase.org/42387
Reviewed-by: abhinav dangeti <abhinav@couchbase.com>
Tested-by: abhinav dangeti <abhinav@couchbase.com>
MB-12305: Don't update the snap start/end seqno in tap mutation

We do this in the queueDirty function so this code is not needed. It
also appeared to cause a race in updating the snapshot start and end
sequence numbers so removing it should solve the bug linked above.

Change-Id: Ia8fa36df958be9147ea208ba9ebd78496048ebb4
Reviewed-on: http://review.couchbase.org/42503
Reviewed-by: Chiyoung Seo <chiyoung@couchbase.com>
Tested-by: Michael Wiederhold <mike@couchbase.com>
MB-12279: Incrementally spawn writer threads for buckets

This change is needed to mitigate the high bgfetch latency
observed in heavy Data-Greater-than-Memory scenarios because
having high number of writing threads slows down disk read
performance.
Also mitigates MB-11143 slowdown in single HDD case

NOTE: This may slow down disk persistence in fast SSDs by default
NOTE: cbepctl can still be used to dynamically tune writers at runtime

Change-Id: Iddf0d3094f38b66ba8c0e09d6d6a307d15b38d56
Reviewed-on: http://review.couchbase.org/42552
Tested-by: Sundararaman Sridharan <sundar@couchbase.com>
Reviewed-by: Chiyoung Seo <chiyoung@couchbase.com>
MB-12483: Don't allow recreation during vbucket deletion

When we delete a vbucket we have an option to recreate the file
immediately. Doing this is incorrect because we will not know
what the failover log of the new vbucket looks like until we
actually create it in memory. This can lead to a situation where
there is no failover log and as a result the local doc json will
be invalid. If the server is shutdown right after this happens and
then is restarted the vbuckets might be created with garbage values
in some of their fields.

Change-Id: I70e6335af68746aeac49a336da5e33b70dfcfe0e
Reviewed-on: http://review.couchbase.org/42677
Reviewed-by: Sundararaman Sridharan <sundar@couchbase.com>
Reviewed-by: Chiyoung Seo <chiyoung@couchbase.com>
Tested-by: Michael Wiederhold <mike@couchbase.com>
Remove unnecessary Item() constructor

Remove one (of the 5!) Item constructors - it was identical to another
apart from taking a std::string& instead of (char*, length) for the
key.

Change-Id: I3b123ee0c380e536bab6b8de8814db9e160db709
Reviewed-on: http://review.couchbase.org/42622
Reviewed-by: Michael Wiederhold <mike@couchbase.com>
Reviewed-by: Trond Norbye <trond.norbye@gmail.com>
Reviewed-by: abhinav dangeti <abhinav@couchbase.com>
Tested-by: abhinav dangeti <abhinav@couchbase.com>
Reformat Item initializer lists

Make it easier to see how they are similar/differ.

Change-Id: Ia140dc18d5445d93aca4ac943ce481a5dcf2fd8d
Reviewed-on: http://review.couchbase.org/42623
Reviewed-by: Michael Wiederhold <mike@couchbase.com>
Reviewed-by: Trond Norbye <trond.norbye@gmail.com>
Reviewed-by: abhinav dangeti <abhinav@couchbase.com>
Tested-by: abhinav dangeti <abhinav@couchbase.com>
Move Item member initialization to initializer list

More refactoring to prepare for merging consturctors, also is more
efficient as we don't default construct the std::string for key before
assigning it.

Change-Id: I3c6e45ea9f3303e5d29f7231ae282f1d59efb31c
Reviewed-on: http://review.couchbase.org/42624
Reviewed-by: Michael Wiederhold <mike@couchbase.com>
Reviewed-by: Trond Norbye <trond.norbye@gmail.com>
Reviewed-by: abhinav dangeti <abhinav@couchbase.com>
Tested-by: abhinav dangeti <abhinav@couchbase.com>
Remove unnecessary Item() constuctor #2

Remove another constructor of Item, the one which takes only a data
size - i.e. allocates a value but doesn't copy it in. In all existing
use-cases this can be replaced with either:

a) The constructor which does copy the data in, as the use-case was
   doing performing the copy in two stages (construct Item of correct
   size, then memcpy()).

b) The consturctor which takes both ptr and size, with with ptr==NULL
   - this is already handled by the setData() private method of Item.

Change-Id: Iffbfef423e82bb021f74860a72dc7b5936bf2215
Reviewed-on: http://review.couchbase.org/42625
Reviewed-by: Michael Wiederhold <mike@couchbase.com>
Reviewed-by: Trond Norbye <trond.norbye@gmail.com>
Reviewed-by: abhinav dangeti <abhinav@couchbase.com>
Tested-by: abhinav dangeti <abhinav@couchbase.com>
Add explicit Item copy-constructor, reduce uses of value_t constructor

Further refactor and simplify Item construction:

- Add an explicit Item copy-constructor for use when copying items
  (e.g. MutationResponse).

- Change uses of Blob-passing constructor to just use the {char* data,
  size_t len} variant instead - in three use-cases the client just
  creates a Blob immediately before calling the constructor; might as
  well let the consturctor do the work.

This reduces the users of the Blob-passing constructor to one -
StoredValue::toItem(). This already has a value_t and so we do want to
make the new Item point to it, hence can't change this to use the
{data, len} variant.

Change-Id: I7c0ff575da70b24290c49d371e1aff14ef160d55
Reviewed-on: http://review.couchbase.org/42626
Reviewed-by: abhinav dangeti <abhinav@couchbase.com>
Tested-by: abhinav dangeti <abhinav@couchbase.com>
Remove unused Blob New() method

Code cleanup - no-one uses this method so delete it.

Change-Id: I10df43e052a96832fe9b4c882be6a19497392d38
Reviewed-on: http://review.couchbase.org/42775
Reviewed-by: Sundararaman Sridharan <sundar@couchbase.com>
Reviewed-by: abhinav dangeti <abhinav@couchbase.com>
Tested-by: abhinav dangeti <abhinav@couchbase.com>
Remove unnecessary Blob constructor

Blob has two very similar constructors, differing only if the Blob is
initially populated or not. Unify these two constructors to simplify
maintenance.

Change-Id: I1b77502cc178d0a116321fd32d5e0657a2fd9e09
Reviewed-on: http://review.couchbase.org/42776
Reviewed-by: abhinav dangeti <abhinav@couchbase.com>
Tested-by: abhinav dangeti <abhinav@couchbase.com>
MB-12483: Remove the default constructor in the vbucket_state struct

The default constructor can leave uninitialized fields and we persist
this structure to disk. In oreder to prevent garbage from being written
we should remove the default constructor.

Change-Id: I028fac1dc112bb454779a30f695eb180278455df
Reviewed-on: http://review.couchbase.org/42728
Reviewed-by: Chiyoung Seo <chiyoung@couchbase.com>
Tested-by: Michael Wiederhold <mike@couchbase.com>
MB-12483: Make sure vbucket_state initializes all variables

We need to make sure that this data is always completely filled
out so that we don't accidentally write garbage data to disk.

Change-Id: I196e7ca9f5bada8e0df90ddb01b6e952650bed56
Reviewed-on: http://review.couchbase.org/42729
Reviewed-by: Chiyoung Seo <chiyoung@couchbase.com>
Reviewed-by: abhinav dangeti <abhinav@couchbase.com>
Tested-by: Michael Wiederhold <mike@couchbase.com>
Fix compile warning

control reaches end of non-void function [-Wreturn-type]

Change-Id: Ibe5ec2801f304b6fe4f767073628462c90161f93
Reviewed-on: http://review.couchbase.org/42826
Reviewed-by: Chiyoung Seo <chiyoung@couchbase.com>
Tested-by: Chiyoung Seo <chiyoung@couchbase.com>
MB-10789 [8]: More unit tests for bloomfilters

Change-Id: I95b8937c0d58a4e3ec5ab7e9814184732d27f168
Reviewed-on: http://review.couchbase.org/42732
Reviewed-by: Sundararaman Sridharan <sundar@couchbase.com>
Tested-by: abhinav dangeti <abhinav@couchbase.com>
MB-12551: Add all arguments to noop log message

Change-Id: Id6e8aac2bf9e398dc8c929eb122651884d27b7c1
Reviewed-on: http://review.couchbase.org/42862
Reviewed-by: Chiyoung Seo <chiyoung@couchbase.com>
Tested-by: Michael Wiederhold <mike@couchbase.com>
Don't create a corefile just because we don't have tcmalloc

Change-Id: I2a01322d74033a7c80cbf82bd1cb71cb732bd031
Reviewed-on: http://review.couchbase.org/42837
Reviewed-by: Michael Wiederhold <mike@couchbase.com>
Tested-by: Trond Norbye <trond.norbye@gmail.com>
Don't create a 2mb stack object

Change-Id: I24001deb436b4f5859e8e58400fbff176253514e
Reviewed-on: http://review.couchbase.org/42841
Reviewed-by: Trond Norbye <trond.norbye@gmail.com>
Tested-by: Trond Norbye <trond.norbye@gmail.com>
Don't release the item while we're using it

Change-Id: I6ab6c9fee2497d0843af47647f33bcce73111f76
Reviewed-on: http://review.couchbase.org/42842
Reviewed-by: Michael Wiederhold <mike@couchbase.com>
Tested-by: Trond Norbye <trond.norbye@gmail.com>
MB-12562: Avoid terminating all writer threads

With incremental writer thread scheduling, we
need to make sure that all writer threads aren't
deleted before deleting all buckets.

Scenario
- maxWriters is 4
- create bucket 1, numWriters=1
- create bucket 2, numWriters=2
- create bucket 3, numWriters=3
- create bucket 4, numWriters=4
- create bucket 5, numWriters=4
- delete bucket 5, numWriters=3 =>with change, 4
- delete bucket 4, numWriters=2 =>with change, 3
- delete bucket 3, numWriters=1 =>with change, 2
- delete bucket 2, numWriters=0 =>with change, 1
- delete bucket 1, numWriters=0 =>with change, 0

Change-Id: Ib9d45f7acb9177924612547538aa74ca9dd49c20
Reviewed-on: http://review.couchbase.org/42880
Reviewed-by: Sundararaman Sridharan <sundar@couchbase.com>
Tested-by: abhinav dangeti <abhinav@couchbase.com>