[CCBC-527] Durability timeouts may be a bit jumpy Created: 18/Oct/14  Updated: 20/Oct/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.0, 2.4.3
Fix Version/s: 2.4.4
Security Level: Public

Type: Task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Durability timeouts may be a bit jumpy due to the code still using the older ns-to-us conversion. Sometimes the values might be subject to integer overflow and cause incorrect timeout behavior.

 Comments   
Comment by ivulfson [ 20/Oct/14 ]
This issue was exhibited while testing the perl Couchbase client. The issue is described in detail here:

https://github.com/mnunberg/perl-Couchbase-Client/issues/25

I've tested Mark's fix in his libcouchbase master branch, and it works.




[CCBC-520] Incorrect commands for installing libcouchbase on Debian/Ubuntu Created: 10/Oct/14  Updated: 20/Oct/14  Resolved: 13/Oct/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: docs
Affects Version/s: 2.4.0
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Minor
Reporter: Terry Dhariwal Assignee: Terry Dhariwal
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: N/A

Attachments: PNG File Screenshot 2014-10-10 15.19.56.png    

 Description   
The command:
===========
wget -O- http://packages.couchbase.com/ubuntu/couchbase.key | sudo apt-key add
should be:
wget O- http://packages.couchbase.com/ubuntu/couchbase.key | sudo apt-key add

/etc/apt/sources.list
===============
Also there's a line for creating a new file in /etc/apt/sources.list.d directory. This seems incorrect... I changed a file called /etc/apt/sources.list and that seemed to work.





 Comments   
Comment by Subhashni Balakrishnan [ 10/Oct/14 ]
I believe the alternate way is to add it in a separate file like couchbase.list to /etc/apt/sources.list.d
Comment by Mark Nunberg [ 10/Oct/14 ]
mnunberg@mbp15 ~/Source/libcouchbase $ wget O- http://packages.couchbase.com/ubuntu/couchbase.key
--2014-10-10 20:52:58-- http://o-/
Resolving o-... failed: nodename nor servname provided, or not known.
wget: unable to resolve host address 'o-'


..
Following the instructions from the manual (as I did today) work fine for me (just had to look them up earlier today for something else)
Comment by Matt Ingenthron [ 20/Oct/14 ]
Terry: With Mark's comments here, is it okay?




[CCBC-528] Large observe packets may cause partial buffers to be sent Created: 18/Oct/14  Updated: 18/Oct/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.4.0
Fix Version/s: 2.4.4
Security Level: Public

Type: Task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
If a single output buffer for an observe command exceeds 512 bytes, the library may silently drop subsequent items to be appended to the command body.

This is normally not an issue in practice as the observe buffers are typically issued on a per-key basis; and since a key is never larger than 256b, the library accidentally never runs into this bug. This only seems to be an issue with so-called "multi observe" or "multi endure" commands.




[CCBC-501] Hide no_verify SSL option Created: 25/Aug/14  Updated: 17/Oct/14  Resolved: 26/Aug/14

Status: Closed
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.4.0
Fix Version/s: 2.4.1
Security Level: Public

Type: Task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Hide the ssl=no_verify option and rename the capath option to cert_path, as currently the server does not support third-party-signed certificates, but a simple self-signed certificate




[CCBC-502] Provide API to retrieve bucket name Created: 27/Aug/14  Updated: 17/Oct/14  Resolved: 03/Sep/14

Status: Closed
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4.2
Security Level: Public

Type: New Feature Priority: Minor
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
This should be a simple cntl to retrieve the name of the bucket as a string :)




[CCBC-514] helper headers have different install targets depending on build system Created: 16/Sep/14  Updated: 17/Oct/14  Resolved: 17/Sep/14

Status: Closed
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.4.0
Fix Version/s: 2.4.2
Security Level: Public

Type: Task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The helper headers such as 'bsdio-inl' and friends have different install paths depending on whether autotools or cmake is being used.




[CCBC-515] lcb_rget3 does not check for missing configuration Created: 17/Sep/14  Updated: 17/Oct/14  Resolved: 19/Sep/14

Status: Closed
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.4.0
Fix Version/s: 2.4.2
Security Level: Public

Type: Task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The library does not check for a missing configuration in the rget3() API call, thus calling this function on a non-bootstrapped client will segfault rather than return with an error.

 Comments   
Comment by Mark Nunberg [ 17/Sep/14 ]
http://review.couchbase.org/#/c/41464/




[CCBC-518] Provide string ctl to modify retry backoff Created: 26/Sep/14  Updated: 17/Oct/14  Resolved: 12/Oct/14

Status: Closed
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: None
Fix Version/s: 2.4.3
Security Level: Public

Type: Task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Mark Nunberg [ 08/Oct/14 ]
http://review.couchbase.org/#/c/41979/




[CCBC-524] OS X/Homebrew install instructions missing from dev guide Created: 15/Oct/14  Updated: 17/Oct/14  Resolved: 15/Oct/14

Status: Closed
Project: Couchbase C client library libcouchbase
Component/s: docs
Affects Version/s: 2.4.2
Fix Version/s: None
Security Level: Public

Type: Task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Mark Nunberg [ 15/Oct/14 ]
https://github.com/couchbase/docs/pull/12




[CCBC-446] Convey more clearly that 'CONTIG' key types imply the header is provided as well. Created: 08/Jun/14  Updated: 17/Oct/14  Resolved: 18/Jun/14

Status: Closed
Project: Couchbase C client library libcouchbase
Component/s: docs, library
Affects Version/s: 2.4.0-dp1
Fix Version/s: 2.4.0-dp1
Security Level: Public

Type: New Feature Priority: Blocker
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Matt Ingenthron [ 08/Jun/14 ]
What is a 'contig' key type? Is this part of the public API?
Comment by Mark Nunberg [ 08/Jun/14 ]
https://github.com/couchbase/libcouchbase/blob/packet-ng/include/libcouchbase/api3.h

Yes, it's part of the public API. All these routines are currently deemed volatile as they are subject to change, however the intent is to eventually promote this api "Version 3 API" (the lcb 2.x API). This is an alternate API which provides much more clarity and conciseness with respect to scheduling and creating new commands, however it is not fully implemented. The older "2.x" API simply wraps this new API internally.
Comment by Matt Ingenthron [ 09/Jun/14 ]
With the thought that we're now going to do a major release, does it make sense to make this the new API as COMMITTED and deprecate (but not remove) the old one? We won't often have major releases and we should aim for clarity by having the 3.0 release the new API. Also, it's best if we don't have too many changes. I'm sure there's a schedule impact. We can discuss when we next get together.
Comment by Mark Nunberg [ 18/Jun/14 ]
http://review.couchbase.org/38405
Comment by Mark Nunberg [ 18/Jun/14 ]
Just in case yall were wondering, this is all highly volatile API, but it's there as this will form the basis of a 3.0 API when we actually do a 3.0




[CCBC-326] Confmon does not handle memcached buckets well Created: 18/Feb/14  Updated: 17/Oct/14  Resolved: 03/Mar/14

Status: Closed
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.0-dp2
Fix Version/s: 2.3.0
Security Level: Public

Type: Task Priority: Blocker
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Confmon does not properly handle updates to memcached reliably. Because the configuration is now pull-based rather than push-based, we don't actually directly refresh if there is a cluster topology change. The solution is that upon detection of a memcached bucket, perform the following:

(1) Disable CCCP
(2) Bump the http 'disconn timeout' to a very high number
(3) Never have the HTTP provider call 'failed' but rather always cycle the nodes.




[CCBC-351] vbucket config parsing very slow Created: 25/Mar/14  Updated: 17/Oct/14  Resolved: 25/Mar/14

Status: Closed
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.0.7, 2.2.0, 2.3.0-dp2
Fix Version/s: 2.3.0
Security Level: Public

Type: Improvement Priority: Test Blocker
Reporter: Mark Nunberg Assignee: Brett Lawson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The underlying cJSON library is woefully inefficient, as such it ends up that the client may end up spending _several seconds_ blocked on CPU/RAM for a parse to complete, hindering the success of other operations in the thread and test.

 Comments   
Comment by Brett Lawson [ 25/Mar/14 ]
The following two commits increases config parsing performance by 2700%, this should significantly improve performance of libcouchbase during frequent config updates.
http://review.couchbase.org/#/c/34914/
http://review.couchbase.org/#/c/34917/




[CCBC-526] Configuration source may revert to HTTP (port 8091) during excessive errors Created: 16/Oct/14  Updated: 17/Oct/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.0, 2.4.0
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Minor
Reporter: Perry Krug Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
In AWS, I am running this command:
cbc-pillowfight -U couchbase://ec2-54-176-251-0.us-west-1.compute.amazonaws.com/event_stream -t 128 -B 10000 -I 10000 -m 1024 -M 1024 -n -c -1

I am observing many:
Operation(s) failed: [0x17] Client-Side timeout exceeded for operation. Inspect network conditions or increase the timeout

I assume this is related to resource exhaustion and is not the main focus of this bug...but I think it is related so I included it.

The main concern is that within a few seconds of running this command, I observe a large increase in the number of 8091 connections to my Couchbase Server cluster. With the exact command above, the increase is in the range of 60-80 connections before I terminate the command. When adding a "-v" to capture logs, it's only around 6-10 connections increase, but is still more than I would expect and hopefully representative of the problem. With "-vv or -vvv" I am unable to reproduce the behavior which I assume is due to some race condition/context switching.

Logs are here: http://customers.couchbase.com.s3.amazonaws.com/perry/libcouchbase (sorry, it's rather big, the increase of connections should be relatively near the end)

 Comments   
Comment by Mark Nunberg [ 16/Oct/14 ]
I'm moving this to minor because in any event the client will use the "terse" URI (starting from lcb version 2.4.0), which is much more resource friendly to the cluster.

The reason, in this case, that it's falling back to port 8091 is because the connection via the 11210 port is timing out, and the client will switch to the next available bootstrap method.

Note that interaction with port 8091 can be disabled entirely by using 'bootstrap_on=cccp' in the connection string. Note that this behavior is not the default in order to support older servers (which do not have CCCP) and memcached buckets (which do not support CCCP).




[CCBC-525] Make failure tests more deterministic Created: 16/Oct/14  Updated: 17/Oct/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: None
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Major
Reporter: Perry Krug Assignee: Subhashni Balakrishnan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
From a community user:
I'm trying to build libcouchbase from sources on Ubuntu 12.04 and have several tests failing. Here's the output:

[ RUN ] MockUnitTest.testReconfigurationOnNodeFailover
tests/iotests/t_netfail.cc:252: Failure
Value of: iter->second
Actual: 23
Expected: LCB_SUCCESS
Which is: 0
tests/iotests/t_netfail.cc:252: Failure
Value of: iter->second
Actual: 23
Expected: LCB_SUCCESS
Which is: 0
tests/iotests/t_netfail.cc:252: Failure
Value of: iter->second
Actual: 23
Expected: LCB_SUCCESS
Which is: 0
tests/iotests/t_netfail.cc:252: Failure
Value of: iter->second
Actual: 23
Expected: LCB_SUCCESS
Which is: 0
tests/iotests/t_netfail.cc:252: Failure
Value of: iter->second
Actual: 23
Expected: LCB_SUCCESS
Which is: 0
tests/iotests/t_netfail.cc:316: Failure
Value of: lcb_get_num_nodes(instance)
Actual: 10
Expected: 9
[ FAILED ] MockUnitTest.testReconfigurationOnNodeFailover (9225 ms)
[ RUN ] MockUnitTest.testBufferRelocationOnNodeFailover
tests/iotests/t_netfail.cc:414: Failure
Value of: rv.error
Actual: 23
Expected: LCB_SUCCESS
Which is: 0
[ FAILED ] MockUnitTest.testBufferRelocationOnNodeFailover (36752 ms)
[ RUN ] MockUnitTest.testSaslMechs
[ OK ] MockUnitTest.testSaslMechs (1853 ms)
[ RUN ] MockUnitTest.testMemcachedFailover
tests/iotests/t_netfail.cc:536: Failure
Value of: lcb_get_num_nodes(instance)
Actual: 10
Expected: 9
[ FAILED ] MockUnitTest.testMemcachedFailover (1743 ms)

Tried building master, release 2.4.2 and 2.3.2.

 Comments   
Comment by Mark Nunberg [ 16/Oct/14 ]
Unfortunately these tests are not fully deterministic; all I can say is that they pass "most of the time", and the reason why the failures appear are due to timing issues between the mock and the client library.

Development of a new, more deterministic mock server is underway, but it will be quite some time until it's properly integrated within the client.

Generally, ensuring there is sufficient CPU and memory resources on the machine running the tests will ensure they have a high pass rate, but this is not guaranteed.
Comment by Mark Nunberg [ 16/Oct/14 ]
For further reference, our tests are executed on our Jenkins builders for each commit. They typically have at least one test that fails on one or another configuration; this will typically be a result of insufficient CPU resources which cause the mock to become slow. See: http://sdkbuilds.couchbase.com/job/lcb-linux-cmake/ for the latest test results.

Comment by Mark Nunberg [ 17/Oct/14 ]
This isn't specific to 2.4.2, but all versions of the library. Assigning to subhashni :) - I know she is working on something




[CCBC-523] Drop support for anything below TLSv1 Created: 15/Oct/14  Updated: 15/Oct/14  Resolved: 15/Oct/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.4.0, 2.4.1, 2.4.2
Fix Version/s: 2.4.3
Security Level: Public

Type: Task Priority: Critical
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Mark Nunberg [ 15/Oct/14 ]
http://review.couchbase.org/#/c/42172/




[CCBC-506] Lower the default CONFDELAY threshold Created: 02/Sep/14  Updated: 15/Oct/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.4.0, 2.4.1, 2.4.2
Fix Version/s: .future
Security Level: Public

Type: Task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The default setting for this is now 10 seconds. This means that it may take up to this time to refetch a new configuration, causing outages in such use environments when such a delay is unacceptable. While this number is certainly adjustable there seems to be some confusion and difficulty in conveying exactly what this number means. Perhaps a lower default value is ok for this as well?

To recap, this interval specifies the throttle period during which a client instance will not request a new configuration. This is the interval from the _last_ received configuration, and basically helps us avoid requesting too many config updates in a short timespan.

I am thinking about something like 3 seconds for this?

 Comments   
Comment by Mark Nunberg [ 02/Sep/14 ]
Adding matt to watchers, as maybe he can contribute his thoughts
Comment by Subhashni Balakrishnan [ 15/Oct/14 ]
can we try to do some test runs with different values and decide based on that - but this only impacts in the cases where we don't get a config on NMV




[CCBC-423] Don't request configuration from nodes about to be ejected Created: 20/May/14  Updated: 15/Oct/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.1, 2.4.3
Fix Version/s: .future
Security Level: Public

Type: Task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on CCBC-420 vbucket: Don't map item to server wit... Resolved

 Comments   
Comment by Mark Nunberg [ 20/May/14 ]
In addition to not remapping keys to "Eject Wait" nodes, we should also not try to solicit them for config requests.




[CCBC-522] Doc Issue with Personalized Logger in LCB Created: 13/Oct/14  Updated: 14/Oct/14  Resolved: 14/Oct/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: docs
Affects Version/s: 2.4.2
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Minor
Reporter: Jeff Dillon Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Customer has issue with the sample code at http://docs.couchbase.com/couchbase-sdk-c-2.4/#logging

From the customer:

"In the example at the address above, the procs structure is allocated on the stack, in the scope of the function apply_logging, so this procs object gets deleted when this function exits, whereas the object pointed by the "instance" pointer may still exist.

This seems to be in contradiction with the statement "The lcb_logprocs pointer must point to valid memory and must not be freed by the user after passing it to the library until the instance associated with it is destroyed."

AFAIK, the fact that apply_logging and logger functions are static does not change anything to that."

ASK: Is the customer concern valid?

 Comments   
Comment by Mark Nunberg [ 13/Oct/14 ]
The logging interface in the library is subject to change and thus marked as uncommitted: http://docs.couchbase.com/sdk-api/couchbase-c-client-2.4.2/group___l_c_b___c_n_t_l.html#gac5e559536b7d0666361b97e0cfae6495

The example in the doc link above _is_ wrong, though - but that documentation should no longer be visible.

The lcb_logprocs structure as the current interface has it, is stored in the library (as a pointer). The goal of not passing in a callback directly is for the logging callback to have access to whatever (if any) application-specific logging framework context being used (so the callback can just proxy over to it).
Comment by Mark Nunberg [ 13/Oct/14 ]
https://github.com/couchbaselabs/docs-ng/pull/163




[CCBC-473] cbc utility is not listed on man page index Created: 07/Jul/14  Updated: 13/Oct/14  Resolved: 13/Oct/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: docs
Affects Version/s: 2.3.2
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Major
Reporter: Matt Ingenthron Assignee: Mark Nunberg
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The cbc utility man page is not on the index so it's possible to get the man page only through installation.

 Comments   
Comment by Matt Ingenthron [ 07/Jul/14 ]
I could not find a .next to put the fix version on, please set that up.
Comment by Mark Nunberg [ 07/Jul/14 ]
Which index is this? - The new Doxygen pages will contain references to the relevant manpages on the side bar; so I guess this can be considered fixed in 2.4?
Comment by Matt Ingenthron [ 07/Jul/14 ]
The API reference off of the docs site. Given that it exists, it takes 2 minutes, we've somehow skipped this API reference publishing step for 2.3.1 and 2.3.2, it'd be really nice to fix it one-off for 2.3.2.
Comment by Mark Nunberg [ 07/Jul/14 ]
http://review.couchbase.org/#/c/39180/




[CCBC-519] Memory (possibly connection) leak in cbc-pillowfight Created: 02/Oct/14  Updated: 12/Oct/14  Resolved: 08/Oct/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.4.2
Fix Version/s: 2.4.3
Security Level: Public

Type: Bug Priority: Major
Reporter: Perry Krug Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
I can't tell whether this is only pillowfight or the libcouchbase underneath, but running the following command for about an hour shows a continuously growing RAM usage by the cbc-pillowfight process:

cbc-pillowfight -U couchbase://172.23.100.38/default -m 1 -M 1 -t 64 -B 10000 -I 30000 -n -c -1 -r 5 2> /dev/null




[CCBC-517] More information should be printed when a new config is obtained. Created: 26/Sep/14  Updated: 12/Oct/14  Resolved: 12/Oct/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.4.2
Fix Version/s: 2.4.3
Security Level: Public

Type: Task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
We should print out the following info:

* RevID
* Why a config was rejected (if it in fact was rejected)

 Comments   
Comment by Mark Nunberg [ 08/Oct/14 ]
http://review.couchbase.org/#/c/41978/1




[CCBC-516] unable yum install libcouchbase-devel.x86_64 Created: 23/Sep/14  Updated: 29/Sep/14  Resolved: 29/Sep/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.4.1
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Major
Reporter: kelvin Assignee: Mark Nunberg
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: CentOS release 6.3 (Final)


 Description   
ctb8:/opt/slocal/src#1 cat /etc/centos-release
CentOS release 6.3 (Final)
ctb8:/opt/slocal/src#2 yum install libcouchbase2-core.x86_64 libcouchbase-devel.x86_64
Loaded plugins: downloadonly, fastestmirror, security
Loading mirror speeds from cached hostfile
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package libcouchbase-devel.x86_64 0:2.4.1-1.el6 will be installed
---> Package libcouchbase2-core.x86_64 0:2.4.1-1.el6 will be installed
--> Processing Dependency: libssl.so.10(libssl.so.10)(64bit) for package: libcouchbase2-core-2.4.1-1.el6.x86_64
--> Processing Dependency: libcrypto.so.10(libcrypto.so.10)(64bit) for package: libcouchbase2-core-2.4.1-1.el6.x86_64
--> Finished Dependency Resolution
Error: Package: libcouchbase2-core-2.4.1-1.el6.x86_64 (couchbase)
           Requires: libssl.so.10(libssl.so.10)(64bit)
Error: Package: libcouchbase2-core-2.4.1-1.el6.x86_64 (couchbase)
           Requires: libcrypto.so.10(libcrypto.so.10)(64bit)
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest
ctb8:/opt/slocal/src#3 rpm -qa | grep openssl
openssl-devel-1.0.0-25.el6_3.1.x86_64
openssl-1.0.0-25.el6_3.1.x86_64
ctb8:/opt/slocal/src#4 ldconfig -v | egrep 'libcrypto.so.10|libssl.so.10'
ldconfig: /etc/ld.so.conf.d/kernel-2.6.32-279.11.1.el6.x86_64.conf:6: duplicate hwcap 1 nosegneg
        libssl.so.10 -> libssl.so.1.0.0
        libcrypto.so.10 -> libcrypto.so.1.0.0


 Comments   
Comment by Mark Nunberg [ 23/Sep/14 ]
This is certainly odd. On my env (CentOS 6.5), I see that the current openssl version is 1.0.1, not 1.0.0:

Installed Packages
Name : openssl
Arch : x86_64
Version : 1.0.1e
Release : 16.el6_5.14
Size : 4.0 M
Repo : installed
From repo : updates
Summary : A general purpose cryptography library with TLS implementation
URL : http://www.openssl.org/
License : OpenSSL
Description : The OpenSSL toolkit provides support for secure communications between
            : machines. OpenSSL includes a certificate management tool and shared
            : libraries which provide various cryptographic algorithms and
            : protocols.

Available Packages
Name : openssl
Arch : i686
Version : 1.0.1e
Release : 16.el6_5.15
Size : 1.5 M
Repo : updates
Summary : A general purpose cryptography library with TLS implementation
URL : http://www.openssl.org/
License : OpenSSL
Description : The OpenSSL toolkit provides support for secure communications between
            : machines. OpenSSL includes a certificate management tool and shared
            : libraries which provide various cryptographic algorithms and
            : protocols.

Name : openssl
Arch : x86_64
Version : 1.0.1e
Release : 16.el6_5.15
Size : 1.5 M
Repo : updates
Summary : A general purpose cryptography library with TLS implementation
URL : http://www.openssl.org/
License : OpenSSL
Description : The OpenSSL toolkit provides support for secure communications between
            : machines. OpenSSL includes a certificate management tool and shared
            : libraries which provide various cryptographic algorithms and
            : protocols.

Comment by Mark Nunberg [ 23/Sep/14 ]
Note that you are running CentOS 6.3. This release is not supported any more by CentOS or Red Hat (see https://access.redhat.com/support/policy/updates/errata/). You can build the package from source or you can upgrade to a newer minor release. Upgrading to a newer CentOS release should be a fairly painless and transparent process.
Comment by kelvin [ 23/Sep/14 ]
Thanks! It could install in CentOS 6.5.




[CCBC-512] Docs state that getl will prevent all future access Created: 11/Sep/14  Updated: 18/Sep/14  Resolved: 18/Sep/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: docs
Affects Version/s: 2.4.1
Fix Version/s: 2.4.2
Security Level: Public

Type: Bug Priority: Major
Reporter: Perry Krug Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Under this link: http://docs.couchbase.com/sdk-api/couchbase-c-client-2.4.0/group___l_c_b___g_e_t.html

The text:
If this parameter is set then the server will in addition to retrieving the item also lock the item, making it so that other operations to access the same item will fail with an error (either LCB_KEY_EEXISTS or LCB_ETMPFAIL). The key will only be accessible again once:
-The lock timeout expires
-The item is unlocked with the cas returned in the response
-The item is modified with the cas returned in the response

Is not correct about "other operations". In fact, other operations (both read and modify) would receive no error. The text could be simply modified to be "other operations with the lock bit set"

 Comments   
Comment by Mark Nunberg [ 11/Sep/14 ]
http://review.couchbase.org/41380




[CCBC-129] Add libevent support for win32 Created: 20/Nov/12  Updated: 18/Sep/14  Resolved: 18/Sep/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: 2.0.0beta2
Fix Version/s: None
Security Level: Public

Type: New Feature Priority: Minor
Reporter: Brett Harrison Assignee: Mark Nunberg
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive win32libevent.zip    

 Description   
I created a NMakefile and made changes to the code to support libevent on windows.

Files affected:
iofactory.c
plugin-libevent.c

New file:
NMakefile.libevent

I uploaded a zipfile of the changes if you are interested in merging them.

 Comments   
Comment by Sergey Avseyev [ 21/Nov/12 ]
it would be awesome if you can move your patch to our review system. http://review.couchbase.com
Comment by Brett Harrison [ 21/Nov/12 ]
Is there a guild on how to use the review system? If you can explain the steps I'll upload the patch.
Comment by Matt Ingenthron [ 21/Nov/12 ]
It's roughly http://www.couchbase.com/wiki/display/couchbase/Contributing+Changes

Repo tool isn't required for this project though
Comment by Matt Ingenthron [ 21/Nov/12 ]
Also, Brett: saw your CLA on review.couchbase.org and you're all set.
Comment by Mark Nunberg [ 18/Sep/14 ]
Unfortunately libevent doesn't really support Windows except by means of gcc/autotools and some other complicated steps. Given that we only support our binary Visual Studio builds, getting libevent to run well on Windows would be not very fruitful. We might revisit this if and when libevent will support Visual Studio. Until then, I'm marking this as won't fix.




[CCBC-513] cmake does not install all files needed Created: 15/Sep/14  Updated: 17/Sep/14  Resolved: 17/Sep/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.4.1
Fix Version/s: 2.4.2
Security Level: Public

Type: Bug Priority: Major
Reporter: Sergey Avseyev Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
ERROR: Error installing couchbase: [15/242]
        ERROR: Failed to build gem native extension.

    ~/.rbenv/versions/2.1.0/bin/ruby -r ./siteconf20140915-28269-a46nh0.rb extconf.rb
checking for lcb_set_bootstrap_callback(NULL, NULL) in -lcouchbase... yes
checking for mach/mach_time.h... no
checking for stdint.h... yes
checking for sys/time.h... yes
checking for fcntl.h... yes
checking for sys/socket.h... yes
checking for errno.h... yes
checking for st_index_t... yes
checking for clock_gettime()... yes
checking for gettimeofday()... yes
checking for QueryPerformanceCounter()... no
checking for gethrtime()... yes
checking for rb_hash_lookup2()... yes
checking for rb_thread_fd_select()... yes
checking for rb_thread_blocking_region()... yes
checking for rb_thread_call_without_gvl()... yes
checking for poll() in poll.h... yes
checking for ppoll() in poll.h... yes
checking for rb_fiber_yield()... yes
creating couchbase_config.h
creating Makefile

make "DESTDIR=" clean

make "DESTDIR="
compiling multithread_plugin.c
multithread_plugin.c:30:36: fatal error: libcouchbase/bsdio-inl.c: No such file or directory
 #include <libcouchbase/bsdio-inl.c>
                                    ^
compilation terminated.
Makefile:224: recipe for target 'multithread_plugin.o' failed
make: *** [multithread_plugin.o] Error 1

make failed, exit code 2

Gem files will remain installed in /home/arashm/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/couchbase-1.3.9 for inspection.
Results logged to /home/arashm/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/extensions/x86_64-linux/2.1.0-static/couchbase-1.3.9/gem_make.out


 Comments   
Comment by Mark Nunberg [ 15/Sep/14 ]
http://review.couchbase.org/41421




[CCBC-508] hashkey needs to be marked as volatile and clear that it's experimental and libmemcached compat oriented Created: 10/Sep/14  Updated: 16/Sep/14  Resolved: 16/Sep/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: 2.0.7, 2.1.0, 2.2.0, 2.3.0, 2.4.0, 2.4.1
Fix Version/s: 2.4.2
Security Level: Public

Type: Bug Priority: Blocker
Reporter: Matt Ingenthron Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
This isn't described correctly in the API documentation and needs to be.

Please do so in any source code as well so it's not accidentally discovered. This is not a feature of the system currently.

Recommended text for a comment:
/* Note that hashkey/groupid is not a supported feature of Couchbase Server and this client. It should be considered volatile and experimental. Using this could lead to an unbalanced cluster, inability to interoperate with the data from other languages, not being able to use the Couchbase Server UI to look up documents and other possible future upgrade/migration concerns. */

 Comments   
Comment by Mark Nunberg [ 10/Sep/14 ]
http://review.couchbase.org/#/c/41317/




[CCBC-318] Allow support for keystats Created: 06/Feb/14  Updated: 10/Sep/14  Resolved: 10/Sep/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4.2
Security Level: Public

Type: Task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Mark Nunberg [ 06/Feb/14 ]
This would basically be a subset of 'stats' where each command would be directed only to its vbucket master (and replica?)
Comment by Mark Nunberg [ 10/Sep/14 ]
http://review.couchbase.org/41288




[CCBC-507] Add test case for empty config Created: 08/Sep/14  Updated: 08/Sep/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: None
Fix Version/s: .future
Security Level: Public

Type: Task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Server 3.0.0 sometimes returns an empty config. We should test for this and ensure the parse fails rather than crashing the client.

 Comments   
Comment by Mark Nunberg [ 08/Sep/14 ]
See MB-12104. I think this wouldn't be an issue in the library as the parsing would fail and the library would attempt the next node/provider. Still useful to have a test for this, though.




[CCBC-505] Allow user-side modification of node's statuses Created: 02/Sep/14  Updated: 04/Sep/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: None
Fix Version/s: .future
Security Level: Public

Type: Task Priority: Critical
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: customer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates to
relates to JCBC-539 Consider a way to expose target key n... Open

 Description   
This feature will allow users to get/set the node statuses in cases where existing application infrastructure can be better than the existing built in cluster configuration info with respect to determining if nodes are down , unavailable etc.

This helps increase responsiveness in applications when a node is "known" to be down, while also not forcing any possibly library-side heuristic upon the user.

 Comments   
Comment by Mark Nunberg [ 04/Sep/14 ]
There are actually two ways to implement this. One is at the network level where we can forcefully close a socket, one is at the vbucket level where we can simply set all the indices to -1 where the node's real index would be instead.




[CCBC-439] Improvement needed on cbc help text Created: 03/Jun/14  Updated: 04/Sep/14  Resolved: 04/Sep/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.1
Fix Version/s: 2.4.2
Security Level: Public

Type: Bug Priority: Minor
Reporter: Perry Krug Assignee: Perry Krug
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The current output of help for cbc does not show the arguments required for each command:
[root@cb1 ~]# cbc help create
Usage: create [options] [arguments]

-? Print this help text (--help)
-h val Hostname to connect to (--host)
-b val Bucket to use (--bucket)
-u val Username for the rest port (--user)
-P val password for the rest port (--password)
-T Enable command timings (--enable-timings)
-t val Specify timeout value (--timeout)
-D Behave like legacy memcached client (default false) (--dumb)
-S val Force SASL authentication mechanism ("PLAIN" or "CRAM-MD5") (--sasl)
-C val Specify transport for bootstrapping the connection: "HTTP" or "CCCP" (default) (--config-transport)
-Z val Path to cached configuration (--config-cache)
-f val Flag for the new object (--flag)
-e val Expiry time for the new object (--exptime)
-a Fail if the object exists (--add)

It has also been requested that cbc and/or libcouchbase have a 'man' page which might help in parallel here.

 Comments   
Comment by Mark Nunberg [ 04/Sep/14 ]
http://review.couchbase.org/#/c/41195/




[CCBC-206] Improve libcouchbase rpm instructions Created: 19/Feb/13  Updated: 04/Sep/14  Resolved: 04/Sep/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: docs
Affects Version/s: None
Fix Version/s: None
Security Level: Public

Type: Improvement Priority: Minor
Reporter: James Mauss Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: info-request
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
There is currently no documentation about installing libcouchbase from the rpm or deb files.
The only documentation is for installation with yum or apt-get.

Since some packages are optional, more instructions would be nice.

 Comments   
Comment by kzeller [ 28/Mar/13 ]
Hi,

Can you point me to any information about rpm install for the SDK on github, or anywhere else. Assign back to me to document.


Thanks,

Karen
Comment by kzeller [ 02/May/13 ]
Can you close this and reopen this under the Couchbase C Client Library project?

We're doing massive housekeeping on docs requests and want to keep this separate from server.


Thanks!
Comment by Mark Nunberg [ 12/May/14 ]
We should probably have an entire page dedicated to installation.
Comment by Mark Nunberg [ 04/Sep/14 ]
Information is at http://packages.couchbase.com/clients/c/index.html




[CCBC-504] cbc hash does not print the replica information any more Created: 02/Sep/14  Updated: 02/Sep/14  Resolved: 02/Sep/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.4.0, 2.4.1
Fix Version/s: 2.4.2
Security Level: Public

Type: Bug Priority: Critical
Reporter: Patrick Varley Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: supportability
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Before 2.4.0:

"patick" Server:"192.168.61.102:11210" vBucket:345 CouchAPI:"http://192.168.61.102:8092/TEST" Replicas:"192.168.61.101:11210"

2.4.0 and onwards

patick: [vBucket=345, Index=1] Server: 192.168.61.102:11210, CouchAPI: http://192.168.61.102:8092/TEST


The support team uses 'cbc hash' to debug issues. Please add back the replica information.

 Comments   
Comment by Mark Nunberg [ 02/Sep/14 ]
http://review.couchbase.org/#/c/41148/




[CCBC-503] need better documentation on how to use error classifiers Created: 28/Aug/14  Updated: 28/Aug/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: docs
Affects Version/s: 2.4.0, 2.4.1
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Major
Reporter: Matt Ingenthron Assignee: Matt Ingenthron
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Documentation has a section on error handling, but there's nothing in the documentation other than a release note on error classifiers.

Please add some detail on what these are and how they're intended to be used.

 Comments   
Comment by Mark Nunberg [ 28/Aug/14 ]
http://docs.couchbase.com/couchbase-sdk-c-2.4/index.html#error-handling-and-diagnostics gives a pretty detailed explanation. Do you mean to add an additional section within the API docs, or something else?




[CCBC-500] ConnSpec parser fails to understand a string with a non-existent scheme. Created: 20/Aug/14  Updated: 26/Aug/14  Resolved: 26/Aug/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.4.0
Fix Version/s: 2.4.1
Security Level: Public

Type: Task Priority: Major
Reporter: Brett Lawson Assignee: Brett Lawson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
When passing a string that is simply an IP address (ie: `192.168.7.26:8091`), libcouchbase fails with a 'Invalid arguments' error.

 Comments   
Comment by Mark Nunberg [ 20/Aug/14 ]
this is by design. to use a raw address, the v2 structure should be used instead
Comment by Brett Lawson [ 20/Aug/14 ]
A raw address/port combination is a valid URI and a valid connection string, http scheme should be used by default if one is not provided. This is necessary for backwards compatibility and does not have any known side effects.
Comment by Mark Nunberg [ 20/Aug/14 ]
The heuristics here are a bit more complex, and we shouldn't be using HTTP bootstrap by default unless there is good reason to do so, thus for example a traditional 'simple IP' address should end up being CCCP, but if a port is provided, would be HTTP, etc.

In my opinion, if dealing with a higher level SDK, the branching should be done at the SDK level rather than within the client library itself (this way, the SDK has a chance to print out a warning about how using a scheme-less syntax is deprecated, etc). This would work by having the SDK determine if the string starts with a valid scheme, and if it does, use the 'v3' options. If it does not, use the 'v1' options
Comment by Brett Lawson [ 20/Aug/14 ]
Whilst I agree with you, the spec specifically defines a host/port combination as being valid for other reasons (such as easily supporting user upgrades). Breaking spec for a single SDK, especially since it's such a simple change (literally code was added to make this specifically not work) does not make sense.

P.S. Using couchbase:// by default does not permit backwards compatibility with pre-2.5 servers (or it should not be at least, again, for reasons I won't list here; some are mentioned in the spec). Thus defaulting to this on a 'feature' thats sole purpose is supporting lazy initial upgrades also makes no sense.




[CCBC-499] cbc pillowfight now longer working Created: 18/Aug/14  Updated: 20/Aug/14  Resolved: 18/Aug/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.4.0
Fix Version/s: 2.4.1
Security Level: Public

Type: Bug Priority: Major
Reporter: Nakomis Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: pillowfight
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Ubuntu 12.04.5 LTS (GNU/Linux 3.2.0-67-virtual i686) on Softlayer VM


 Description   
Have installed libcouchbase, following instructions here [1]. When I run `cbc pillowfight` I get the following error:

Unknown command pillowfight
Usage: cbc <command> [options]
command may be:
   help Show help
<......>

If I run `cbc pillowfight -h 127.0.0.1:8091 -b default -i 1000 -I 1000 -t 1 -Q 1 -s 0 -m 50 -M 5120` I get the error:
Unknown command pillowfight
Couldn't parse options: Unknown option
No such option: i
Usage:
  pillowfight [OPTIONS...]

   -P --password Bucket password [Default='']
   -u --username Username (currently unused) [Default='']
<....>

`cbc version` gives the following:
cbc:
  Runtime: Version=2.4.0, Changeset=3ad936575b1718a748e5dc6ff73dfe801a201b15
  Headers: Version=2.4.0, Changeset=3ad936575b1718a748e5dc6ff73dfe801a201b15
  IO: Default=libevent, Current=libevent
  Compression (snappy): .. NOT SUPPORTED
  SSL: .. SUPPORTED

This was previously working

Please let me know if you require any further information

Cheers

Martin


[1]: http://www.couchbase.com/communities/c-client-library

 Comments   
Comment by Mark Nunberg [ 18/Aug/14 ]
http://review.couchbase.org/#/c/40189/
Comment by Nakomis [ 20/Aug/14 ]
Thanks, I hadn't realized `cbc pillowfight` had been replaced by `cbc-pillowfight`. Using the new cbc-pillowfight, is it possible to run it against a remote machine? If I try `cbc-pillowfight -h <ip of remote server>:8091 -b default -i 1000 -I 1000 -t 1 -Q 1 -s 0 -m 50 -M 5120` I get the error "The -h/--host option is deprecated. Use connection string instead", however, I can't find a way to specify the connection string

Thanks
Comment by Mark Nunberg [ 20/Aug/14 ]
Use the -U option. More information on the connection string can be found here: http://docs.couchbase.com/sdk-api/couchbase-c-client-2.4.0/group___l_c_b___l_c_b_t.html#structlcb__create__st3




[CCBC-497] Segfaults when handling network errors during rebalance Created: 11/Aug/14  Updated: 18/Aug/14  Resolved: 18/Aug/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: 2.4.0
Fix Version/s: 2.4.1
Security Level: Public

Type: Task Priority: Major
Reporter: Subhashni Balakrishnan Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
When handling network errors on view requests, lcb segfaults

*** glibc detected *** ./sdkd_lcb: free(): invalid pointer: 0x00007fe800000001 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x760e6)[0x7fe85bea30e6]
/root/sources/libcouchbase/inst/lib/libcouchbase.so.2(+0xcc98)[0x7fe85c96cc98]
/root/sources/libcouchbase/inst/lib/libcouchbase.so.2(+0xd101)[0x7fe85c96d101]
#4 0x00007ffd09435c98 in request_free_headers (req=0x7ffc900186f0) at src/http/http.c:36
free(*cur);

 Comments   
Comment by Mark Nunberg [ 12/Aug/14 ]
http://review.couchbase.org/#/c/40542/

@subhashni, can you see if this fixes the issue?
Comment by Subhashni Balakrishnan [ 12/Aug/14 ]
Hey Mark it fixes the issue..I've tried this fix before.. but would be nice to figure out why the double free
Comment by Mark Nunberg [ 12/Aug/14 ]
The double free takes place because it calls lcb_http_exec_request (or similar) multiple times on the same http_request_t if the request is retried :)




[CCBC-498] Config cache only gets updated every 10 seconds Created: 12/Aug/14  Updated: 12/Aug/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: docs
Affects Version/s: 2.2.0
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Major
Reporter: Patrick Varley Assignee: Patrick Varley
Resolution: Unresolved Votes: 0
Labels: config-cache, customer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
I believe that the config cache is only updated every 10seconds. I believe we advise users to use the config cache in cases where connections are being created and destroyed all the time such as apache and nginx setups, these also happen to be environments where the process is short lived.

* Is the 10 second timer useful?
* In these environments with cccp should we be using the config cache?


 Comments   
Comment by Mark Nunberg [ 12/Aug/14 ]
The config cache is updated whenever a client instance needs to fetch a new config; in most cases a new config fetch is throttled so that a request does not take place more than once every ten seconds.

The 10 second timer is specifically removed for config cache during the initial configuration, thereby making the case of the apache/nginx concerns moot. If you can please elaborate on some observations you've seen, I can perhaps explain more

There is a distinct advantage for using the config cache even in places where CCCP is enabled, since CCCP still incurs an additional latency overhead in getting the initial config as well as the chance that the node which we connected to for CCCP is not the same node which is the target for the single K/V op in the common use case. The original intent of the config cache was to allow quick bootstrap - and in this case it's always useful. For longer lived applications which are using the config cache to circumvent the connection limits, I would say that it should not be used in conjunction with CCCP




[CCBC-496] Abstract openssl use to dynamically loaded plugin Created: 07/Aug/14  Updated: 07/Aug/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.4.0
Fix Version/s: .future
Security Level: Public

Type: Task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
If an application is using a different version of openssl, the library's version may conflict with it. The solution is to use dynamic loading of the plugin at runtime so that the application's version remains in-tact.




Multi operations should never be partially scheduled (CCBC-281)

[CCBC-333] Multi get replica should not be partially scheduled Created: 22/Feb/14  Updated: 07/Aug/14  Resolved: 07/Aug/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.2.0, 2.3.2
Fix Version/s: 2.4.0
Security Level: Public

Type: Technical task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
This is the same as CCBC-281 except that to implement this for get-replica would be more complex, so I'm deliberately filing a new bug so that this remains open

 Comments   
Comment by Mark Nunberg [ 08/Jul/14 ]
This does not affect the 2.4+ releases
Comment by Mark Nunberg [ 07/Aug/14 ]
This issue is resolved implicitly in the 2.4.x series




[CCBC-494]  LCB documentation here http://www.couchbase.com/communities/c-client-library is not updated Created: 05/Aug/14  Updated: 07/Aug/14  Resolved: 07/Aug/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: docs
Affects Version/s: None
Fix Version/s: 2.4.0
Security Level: Public

Type: Bug Priority: Major
Reporter: Venu Uppalapati Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
 LCB documentation here http://www.couchbase.com/communities/c-client-library is not updated
for example, using lcb_set_error_callback with LCB2.4 throws a warning at compile time but the examples in the docs still use it.

 Comments   
Comment by Mark Nunberg [ 07/Aug/14 ]
Simply linked to the API docs in this case. Those are more extensive




[CCBC-495] Library does not consider hostname and IP of the same server as being the same node Created: 06/Aug/14  Updated: 06/Aug/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.2.0, 2.3.0, 2.4.0
Fix Version/s: .future
Security Level: Public

Type: Bug Priority: Minor
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Connecting to "localhost" will not reuse the connection if a node named "127.0.0.1" appears in the config. Unfortunately fixing this would mean determining how to handle hostnames with different resolving IPs, and similar.

 Comments   
Comment by Mark Nunberg [ 06/Aug/14 ]
In practice this is not a big issue since at most this causes an extra connection to be wasted during initial bootstrap, but may end up causing some confusion during initial log analysis.




[CCBC-493] HELLO is still emitted by client when connecting Created: 05/Aug/14  Updated: 05/Aug/14  Resolved: 05/Aug/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.4.0
Fix Version/s: None
Security Level: Public

Type: Task Priority: Minor
Reporter: Brett Lawson Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Based on the conversation that I recall, HELLO was supposed to be disabled client-side for all releases until such time that server support properly implements it (due to it being subject to change). libcouchbase appears to emit a HELLO request when connecting to a node.

 Comments   
Comment by Mark Nunberg [ 05/Aug/14 ]
It might be a bit of an annoyance, but a well behaved server should respond with NOT_SUPPORTED or UNKNOWN_COMMAND. in this case the server replies perfectly well here. Can you foresee a situation where this would be problematic?
Comment by Brett Lawson [ 05/Aug/14 ]
We had decided to remove this from the clients due to the fact that the server may not disable this immediately, but the feature does not yet work 100%. Additionally, when the feature is implemented, it is entirely possible that it will work in a completely incompatible way to what is currently built, or that opcode may be reused for another purpose.
Comment by Mark Nunberg [ 05/Aug/14 ]
http://review.couchbase.org/#/c/40306/




[CCBC-485] unable to set ssl and ca_path using lcb_cntl Created: 30/Jul/14  Updated: 04/Aug/14  Resolved: 30/Jul/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4.1
Security Level: Public

Type: Bug Priority: Major
Reporter: Subhashni Balakrishnan Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
http://docs.couchbase.com/sdk-api/couchbase-c-client-2.4.0-beta/group___l_c_b_t___i_n_f_o.html#gab3df573dbbea79cfa8ce77f6f61563dc

says it is possible to set the values using lcb_cntl but those are read only args.

 Comments   
Comment by Mark Nunberg [ 30/Jul/14 ]
You need to set ca_path via the connstr in the creation options
Comment by Subhashni Balakrishnan [ 30/Jul/14 ]
Yes but the doc says both modes get, set maybe fix doc? http://docs.couchbase.com/sdk-api/couchbase-c-client-2.4.0-beta/group___l_c_b___c_n_t_l.html#gaacfed9463423501e2623290ac68ce390
Comment by Mark Nunberg [ 30/Jul/14 ]
This is fixed in the release docs :) http://docs.couchbase.com/sdk-api/couchbase-c-client-2.4.0/group___l_c_b___c_n_t_l.html#gaacfed9463423501e2623290ac68ce390
Comment by Subhashni Balakrishnan [ 30/Jul/14 ]
ah.. my bad
Comment by Mark Nunberg [ 30/Jul/14 ]
http://review.couchbase.org/#/c/40055/




[CCBC-492] API ref docs man page for cbc refers to cbcrc man page, which is not available there Created: 01/Aug/14  Updated: 04/Aug/14  Resolved: 04/Aug/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: docs
Affects Version/s: 2.4.0
Fix Version/s: 2.4.1
Security Level: Public

Type: Bug Priority: Major
Reporter: Matt Ingenthron Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Mark Nunberg [ 01/Aug/14 ]
http://review.couchbase.org/#/c/40190/




[CCBC-487] Provide API to control memory usage of the client Created: 30/Jul/14  Updated: 04/Aug/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: None
Fix Version/s: .future
Security Level: Public

Type: New Feature Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The library reserves a sane default of memory for various buffers and such, especially in regards to pooling and the like. Since many of these buffers are per-connection, it may result in high memory usage when many connections and/or instances are used.

The idea here is to provide a "Factor" of memory to use rather than an absolute number because of the high number of settings that may possibly be adjusted within the library regarding memory usage; thus a factor of 1 (the default) will use the default settings, a factor of 0.5 would attempt to reserve only half that amount of space, and so on.




[CCBC-342] Default installation should use libevent plugin Created: 05/Mar/14  Updated: 01/Aug/14

Status: Reopened
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: None
Fix Version/s: .future
Security Level: Public

Type: Task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
10:11 < mnunberg> avsej: also. it's not using the libevent backend
10:11 <+avsej> it signs the repository during import
10:11 <+avsej> https://github.com/couchbaselabs/lcbpackage/blob/master/rakefiles/repositories.rake#L143
10:11 < mnunberg> cbc built from: libcouchbase 2.3.0 (rev. 7b11fe7e4f8f23f24861fe82287d7eb10de2c6b4) using libcouchbase: 2.3.0 (select)
10:12 <+avsej> did you install libcouchbase2-libevent?
10:12 < mnunberg> uhmm..
10:12 < mnunberg> i thought the default behavior was for it to pull in libevent
10:12 < mnunberg> no i didn't install it explicitly
10:12 <+avsej> there should be file like ubuntu/config/distributions
10:13 <+avsej> mnunberg, it won't install it implicitly either
10:13 < mnunberg> hrm, that's not good
10:13 <+avsej> so if you need libevent just install it
10:13 <+avsej> libcouchbase2-libevent
10:13 < mnunberg> but if that's hwo previous versions did it, then ok
10:13 < mnunberg> it doesn't matter to me now
10:13 <+avsej> it is documented http://www.couchbase.com/communities/c-client-library
10:14 < mnunberg> another thing i'd like to do in 3.0 is a blanket dependency on libevent. it's the most well tested and stable of our event loops
10:14 < mnunberg> if you don't want libevent, compile from source
10:17 <+avsej> what if people are using libevent1 in their libraries? they will end up having two versions in their app?
10:18 <+avsej> i don't see issue at all
10:18 <+avsej> it is always better to rely on the repository maintainer rather then us
10:18 <+avsej> are you sure we will push new libcouchbase for each new release of libevent?
10:18 < mnunberg> most people installing libcouchbase are using it as a dependency for ruby php python etc.
10:19 < mnunberg> so we should give the most optimal runtime defaults
10:19 <+avsej> right
10:19 <+avsej> in this case they won't use libcouchbase IO at all
10:19 <+avsej> this is why we have libcouchbase2-core package
10:19 <+avsej> without any dependencies and additional blobs
10:19 < mnunberg> not really. most folks are still using the default I/O plugin, whichever it is that ships
10:19 <+avsej> for ruby people just want libcouchbase
10:20 <+avsej> and for python they also have their own
10:20 < mnunberg> that's the "Most minimal packaging configuration", not "Most optimal runtime configuration" :)
10:20 < mnunberg> python optionally elts you use your own I/O but it's not the default
10:20 < mnunberg> for normal sycnrhonous operatin you want the fastest there is
10:20 < mnunberg> and that's what most use cases are
10:21 <+avsej> so you mean that select implementation is the slowest? it adds a little overhead, and we don't have c10k on the client
10:21 < mnunberg> avsej: it's also buggier
10:22 < mnunberg> 14
10:22 < mnunberg> err..
10:23 < mnunberg> mnunberg@mbp15 ~/Source/lcb-master $ git log 2.0.0..HEAD --pretty=oneline plugins/io/select/ | wc -l 14
10:23 < mnunberg> mnunberg@mbp15 ~/Source/lcb-master $ git log 2.0.0..HEAD --pretty=oneline plugins/io/libevent/ | wc -l 4
10:23 < mnunberg> mnunberg@mbp15 ~/Source/lcb-master $ git log 2.0.0..HEAD --pretty=oneline plugins/io/libev/ | wc -l 7
10:24 < mnunberg> on the other hand select is simpler to debug
10:24 < mnunberg> eh, i don't know
10:25 <+avsej> in any event people have easy what to substitute it, and so far select is good as minimal implementation
10:25 <+avsej> the recommended way to install libcouchbase is 'yum install libcouchbase-devel libcouchbase2-libevent'
10:26 <+avsej> so I don't see any issue
10:26 < mnunberg> that's not the most intuitive way of installing a package
10:26 < mnunberg> if my documentation says "I need dependency FOO" i'll go ahead and query my package manager and install "FOO"
10:26 < mnunberg> i'm not gonna jump to some other document telling me what to install
10:27 <+avsej> why not fix documentation then
10:27 < mnunberg> because people don't read documentation
10:27 < mnunberg> as a rule, people only read documentation enough to get them up and running
10:27 <+avsej> just recently i was compiling nginx with some module which has dependency on gd
10:27 <+avsej> and first thing I was tried is yum install libgd-devel which failed
10:28 <+avsej> the correct way was gd-devel
10:29 <+avsej> in any event libevent is not good enough as default for ruby and I against to have this as mandatory dependency
10:29 <+avsej> libevent doesn't allow to release GIL while it is doing IO
10:29 <+avsej> the ruby IO plugin does
10:30 <+avsej> you probably can rename the packages, but please leave ability to install libcouchbase2-core, i.e. without any plugins
10:30 < mnunberg> it's the default for python and php. i think the way i wanted this to begin with was a libcouchbase2 metapackage
10:30 < mnunberg> i.e. libcouchbase2 would install libcouchbase2 and libevent
10:31 < mnunberg> and for things that had "Special" requirements, they could use '-core'
10:31 <+avsej> why not remove libcouchbase2 package at all
10:31 < mnunberg> we don't have such a package afaict
10:31 <+avsej> and update docs to install libcouchbase2-libevent if they depend on it
10:32 <+avsej> right
10:32 <+avsej> no package no problem
10:32 < mnunberg> going back to my point
10:32 < mnunberg> people don't read docs
10:32 < mnunberg> especially if _not_ installing libevent doesn't actually give any kind of error or issues until much later when it's in production
10:32 < mnunberg> and then it's like "Oh, we're crashing"
10:32 <+avsej> https://github.com/couchbase/libcouchbase/blob/master/packaging/deb/control#L39 remove this line
10:32 < mnunberg> so then we ask "Ok, tell me what I/O plugin you're using"
10:32 < mnunberg> "Oh, you're using select. You should use libevent"
10:32 <+avsej> or rather move it to libcouchbase2-libevent sectio
10:33 <+avsej> https://github.com/couchbase/libcouchbase/blob/master/packaging/deb/control#L12 after this one
10:33 < mnunberg> avsej: not this release. these are just plans for a 3.0 or whatever
10:33 < mnunberg> i'd rather not touch or change behavior
10:34 <+avsej> rpm also has equivalent https://github.com/couchbase/libcouchbase/blob/master/packaging/rpm/libcouchbase.spec.in#L34
10:34 <+avsej> i'm okay with solution which is about moving alias 'libcouchbase2' from 'libcouchbase2-core' to 'libcouchbase2-libevent'
10:34 <+avsej> totally agree with it
10:35 <+avsej> seems like the easiest solution
10:35 < mnunberg> avsej: yeah, we'll need to schedule it for next release, like .future
10:35 < mnunberg> let me do this on JIRA
10:35 <+avsej> could you copy this log there?
10:35 <+avsej> or extract the main idea
10:35 < mnunberg> ok

 Comments   
Comment by Mark Nunberg [ 01/Aug/14 ]
Select is stable enough now
Comment by Matt Ingenthron [ 01/Aug/14 ]
I actually don't agree with this. We've had years of using libevent by default. I'm mostly concerned about environments where people don't check the underlying plugin use. Might be good to talk through this on Monday.




[CCBC-108] Allow per-command retries for not-my-vbucket and other transient errors Created: 04/Oct/12  Updated: 01/Aug/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: 2.0.0beta
Fix Version/s: 3.0-beta
Security Level: Public

Type: Improvement Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
We should avoid the possibility of 'infinite' errors and allow the user the ability of seeing the 'real' error which caused the command to fail..

http://review.couchbase.org/13177




[CCBC-337] Partial failures on vbucket mappings for multi ops should asynchronously fail unmapped keys Created: 24/Feb/14  Updated: 01/Aug/14  Resolved: 01/Aug/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.0
Fix Version/s: 2.4.0
Security Level: Public

Type: Task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
With the fix for CCBC-281 we fail out the entire command list (in the API). We should schedule the commands which are able to be mapped and then fail out the rest of the items asynchronously via some kind of queue.

 Comments   
Comment by Mark Nunberg [ 24/Apr/14 ]
This _should_ be possible with the new retry queue thingy, but would require a bit of work.




[CCBC-491] Provide lcb_dump() to print out debugging information about current client state Created: 31/Jul/14  Updated: 31/Jul/14  Resolved: 31/Jul/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: None
Fix Version/s: 2.4.1
Security Level: Public

Type: Task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
This will provide an lcb_dump() to print out various debug information about the library which may then be used to help diagnose issues.




[CCBC-474] Failure to schedule commands may leak memory Created: 10/Jul/14  Updated: 31/Jul/14  Resolved: 31/Jul/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.4.0-dp1
Fix Version/s: 2.4.1
Security Level: Public

Type: Task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Failure to schedule some commands that allocate internal cookie structures may leak memory as the cookie structure is never properly freed

 Comments   
Comment by Mark Nunberg [ 31/Jul/14 ]
http://review.couchbase.org/#/c/40128/




[CCBC-488] get with replica should return immediate failure if the bucket has no replicas Created: 30/Jul/14  Updated: 30/Jul/14  Resolved: 30/Jul/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.4.0
Fix Version/s: 2.4.1
Security Level: Public

Type: Bug Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Mark Nunberg [ 30/Jul/14 ]
This issue is actually caused by a bug in the lcbvb_vbreplica() function which has a bad check for determining if the input index is valid. This only affects get-with-replica using the index parameter, as in all other cases the index is already bound-checked by other mechanisms.
Comment by Brett Lawson [ 30/Jul/14 ]
This also affects OBSERVE requests completing.
Comment by Brett Lawson [ 30/Jul/14 ]
In hindsight, the bug accidentally makes most cases work, unless you try to observe/getReplica for a replica higher than you have configured.




[CCBC-490] get-with-replica 'FIRST' mode will not actually try all replicas Created: 30/Jul/14  Updated: 30/Jul/14  Resolved: 30/Jul/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.4.0
Fix Version/s: 2.4.1
Security Level: Public

Type: Bug Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The LCB_REPLICA_FIRST will actually only respond with the first replica that has been received, since the custom rget callback (in get.c) is never invoked. See CCBC-489 for another symptom of this bug




[CCBC-489] Get-with-replica will leak memory Created: 30/Jul/14  Updated: 30/Jul/14  Resolved: 30/Jul/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.4.0
Fix Version/s: 2.4.1
Security Level: Public

Type: Bug Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Each call to get-with-replica will leak memory because the packet handler does not properly invoke the customized callback, rather invoking the user callback directly.




[CCBC-486] cbc flush command missing Created: 30/Jul/14  Updated: 30/Jul/14  Resolved: 30/Jul/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: 2.4.0
Fix Version/s: 2.4.1
Security Level: Public

Type: Task Priority: Minor
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
This will be re-added as 'mcflush' instead, to avoid confusion between this command and the bucket-flush (aka "RESTful flush")

 Comments   
Comment by Mark Nunberg [ 30/Jul/14 ]
http://review.couchbase.org/#/c/40064/




[CCBC-402] Provide API for exposing buffer/pool settings (rdb, netbuf) Created: 01/May/14  Updated: 30/Jul/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.4.0-dp1
Fix Version/s: .future
Security Level: Public

Type: Task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[CCBC-484] Override I/O plugin functionality with default I/O impl for send/recv functions Created: 29/Jul/14  Updated: 29/Jul/14  Resolved: 29/Jul/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.4.0-dp1, 2.4.0-beta
Fix Version/s: 2.4.0
Security Level: Public

Type: Task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Because some existing SDKs (like Ruby) make assertions about LCB's behavior which no longer hold true for 2.4, we need to patch the I/O functions at runtime, or risk breaking those dependent SDKs.

See https://github.com/couchbase/couchbase-ruby-client/blob/master/ext/couchbase_ext/plugin_common.c#L56 for an example




[CCBC-174] Error handling documentation Created: 05/Feb/13  Updated: 29/Jul/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: docs
Affects Version/s: 2.0.2
Fix Version/s: .future
Security Level: Public

Type: Improvement Priority: Major
Reporter: Perry Krug Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Please create some documentation specifying possible error/failures to operations, what they "look" like in the logs/exceptions/stack traces and what our recommendation is on how to handle them.

i.e. tmp_oom, timeouts (connection/operation/java-internal/etc), "get miss" (it's technically a failure, let's make it overly obvious what it means), CAS failure, add() failure, replace() failure,

Some of this should be covered in the API reference, but this bug is specifically for a single page where this information is aggregated that a customer/user could read about how to handle errors.




[CCBC-483] Ignore CCCP config updates from not-my-vbucket responses if CCCP is disabled Created: 28/Jul/14  Updated: 29/Jul/14  Resolved: 29/Jul/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.2
Fix Version/s: 2.4.0
Security Level: Public

Type: Bug Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
If the CCCP provider is explicitly disabled, don't update from not-my-vbucket responses. This allows various configuration proxies (functioning over HTTP) to work properly

 Comments   
Comment by Mark Nunberg [ 28/Jul/14 ]
No good way to test this for now




[CCBC-482] Don't set "Last refresh" time for initial file config Created: 28/Jul/14  Updated: 28/Jul/14  Resolved: 28/Jul/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: None
Fix Version/s: 2.4.0
Security Level: Public

Type: Bug Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates to

 Description   
When the client is initially bootstrapped from a file-based cache, it is possible that the cache might be stale; if so, don't set the initial timestamp for the config (which is used as the base to determine whether to throttle subsequent config requests). This allows the client to quickly refetch the configuration if the existing one is stale.




[CCBC-461] Unmask NOT_MY_VBUCKET return codes. Created: 26/Jun/14  Updated: 28/Jul/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.2.0, 2.3.0
Fix Version/s: 3.0-beta
Security Level: Public

Type: Task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
NOT_MY_VBUCKET error codes should be unmasked in the library and propagated to the user if we were unable to retry the operation for whatever reason. While typically the library _will_ retry the operation, masking this error under a different code makes it more difficult for the application to handle.

Historically we have mapped this error to 'LCB_ETIMEDOUT' which isn't always accurate and makes our timeout mechanism seem buggy (an error called "Timeout" should only be thrown after a specific amount of time has elapsed).

The alternative, LCB_NO_MATCHING_SERVER is also confusing as this is typically the return code _before_ an operation is scheduled - while a NOT_MY_VBUCKET is a definite reply from the server. While in raw C applications it may be possible to treat a NO_MATCHING_SERVER from an operation return value differently than one invoked from within a callback, for most common SDKs there is no distinction - and these two paths require different handling paths.




[CCBC-406] instancepool example does not run Created: 04/May/14  Updated: 27/Jul/14  Resolved: 27/Jul/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: docs
Affects Version/s: 2.3.0
Fix Version/s: 2.4.0
Security Level: Public

Type: Bug Priority: Trivial
Reporter: Shiv Dayal Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: documentation
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Ubunutu 14.04 GCC 4.8.2


 Description   
Inf function pool_create in pool.c following should have a case 2

switch(options->version) {
    case 0:
        io = options->v.v0.io;
        break;
    case 1:
        io = options->v.v1.io;
        break;
    default:
        /*
         * I don't know the layout of the option structure (its created
         * after I wrote the example) so I don't now if an io ops structure
         * is provided or not.
         */
        return LCB_EINTERNAL;
    }

like case 2:
        io = options->v.v2.io;

otherwise it says cannot create pool: internal libcouchbase error because it throws error.




[CCBC-480] Don't fail immediately for vbuckets which lack a master node Created: 24/Jul/14  Updated: 25/Jul/14  Resolved: 25/Jul/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.4.0-beta
Fix Version/s: 2.4.0
Security Level: Public

Type: Task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Items whose master vbucket index contains a -1 should not be failed immediately to the user, since in this case a new configuration is never received. The proper behavior is to forward the item to a random node once and receive a not-my-vbucket with the proper configuration.

 Comments   
Comment by Mark Nunberg [ 25/Jul/14 ]
This has been addressed in a different manner, by scheduling the item immediately to the retry queue, but without actually forwarding it to a 'random' node. This approach eliminates the excessive network I/O in this case




[CCBC-481] Use retry queue signalling instead of deadlines. Created: 25/Jul/14  Updated: 25/Jul/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.4.0
Fix Version/s: .future
Security Level: Public

Type: Task Priority: Minor
Reporter: Brett Lawson Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Currently, operations that need to be rescheduled for retry or waiting-on-config situations enter the retry queue and then are retried at a later date based on a timeout period. In many cases, this is inefficient and those operations should instead be signalled by external events occurring (such as a new config being received). In these cases, the retry queue should only be deadlined on the operation timeout, rather than an arbitrary retry interval. This change should additionally help make the handling of operation retries more deterministic.




[CCBC-394] Crash on win32 in lcb_get_replica Created: 25/Apr/14  Updated: 25/Jul/14  Resolved: 01/May/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: 2.3.0
Fix Version/s: 2.3.1
Security Level: Public

Type: Task Priority: Blocker
Reporter: Haster Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency

 Description   
How to reproduce:
1) Start claster with 3 nodes
2) Start a loop of getting some vakue from claster ()first use lcb_get and if NETWORK_ERROR or CONNECTION_ERROR then try to use lcb_get_replica)
3) Stop one node - as a result we have crash

There is a call stack below:
libcouchbase.dll!ringbuffer_ensure_capacity(ringbuffer_st * buffer=0x00000000, unsigned long size=0x00000018) Line 62 + 0x4
libcouchbase.dll!lcb_server_buffer_start_packet_ex(lcb_server_st * c=0x066b0770, lcb_command_data_st * ct=0x12edfce0, ringbuffer_st * buff=0x00000000, ringbuffer_st * buff_cookie=0x066b0794, const void * data=0x12edfd00, unsigned long size=0x00000018) Line 199 + 0x11 libcouchbase.dll!lcb_server_start_packet_ex(lcb_server_st * c=0x066b0770, lcb_command_data_st * ct=0x12edfce0, const void * data=0x12edfd00, unsigned long size=0x00000018) Line 216 + 0x6 bytes C
libcouchbase.dll!lcb_get_replica(lcb_st * instance=0x035ed8c0, const void * command_cookie=0x0357bb88, unsigned long num=0x00000001, const lcb_get_replica_cmd_st * const * items=0x12edfd38) Line 210 C
cache_impl.dll!0a7e2361()
[Frames below may be incorrect and/or missing, no symbols loaded for cache_impl.dll]
cache_impl.dll!0a7e3b1d()


 Comments   
Comment by Haster [ 30/Apr/14 ]
Hi!
I made some investigation of this problem and found that then I called lcb_get_replica in lcb_server_start_packet_ex the buff is assigned with NULL and after that lcb_server_buffer_start_packet_ex->ringbuffer_ensure_capacity is called.
But in lcb_get function is used lcb_server_start_packet instead of lcb_server_start_packet_ex.
In that function is additional check:
        if (!c->connection.output) {
            c->connection.output = calloc(1, sizeof(ringbuffer_t));
            ringbuffer_initialize(c->connection.output, 8092);
        }

Maybe it is enough to add such check to lcb_server_start_packet_ex. function?
I don't know what about memory leaks in that situation...
Comment by Mark Nunberg [ 30/Apr/14 ]
Yes, this should be enough. memory will not leak because anything assigned to ->output will be cleaned up either by the io system or by the server's connection dtor.
Comment by Mark Nunberg [ 30/Apr/14 ]
http://review.couchbase.org/#/c/36525/




[CCBC-475] Better error messag when failing to connect using SSL Created: 11/Jul/14  Updated: 18/Jul/14  Resolved: 18/Jul/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.4.0-dp1
Fix Version/s: 2.4.0
Security Level: Public

Type: Bug Priority: Major
Reporter: Patrick Varley Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: 3.0 Cluster
SSL


 Description   
When I try to connect to the cluster with .pem file that did not exist the error message suggested it was a network issue:

[patrick:~/Code/C/libcouchbase] master* 1 ± LCB_SSL_MODE=1 LCB_SSL_CACERT=bad.pem ~/Code/Python/set.py
Traceback (most recent call last):
  File "/Users/patrick/Code/Python/get-loop.py", line 5, in <module>
    cb = Couchbase.connect(bucket='beer-sample', host='192.168.71.101')
  File "/Library/Python/2.7/site-packages/couchbase/__init__.py", line 219, in connect
    **kwargs)
  File "/Library/Python/2.7/site-packages/couchbase/connection.py", line 153, in __init__
    self._do_ctor_connect()
  File "/Library/Python/2.7/site-packages/couchbase/connection.py", line 163, in _do_ctor_connect
    self._connect()
couchbase.exceptions._NetworkError_0x10 (generated, catch NetworkError): <RC=0x10[Network failure], There was a problem while trying to send/receive your request over the network. This may be a result of a bad network or a misconfigured client or server., C Source=(src/connection.c,878)>

It would be good if the error message was better.

get-loop.py

#!/usr/bin/python
import time
from couchbase import Couchbase

cb = Couchbase.connect(bucket='beer-sample', host='192.168.71.101')
while True:
    result = cb.get('new_holland_brewing_company-sundog')
    print result
    time.sleep(1)

 Comments   
Comment by Mark Nunberg [ 11/Jul/14 ]
http://review.couchbase.org/#/c/39320/




[CCBC-477] Configuration provider may erroneously revert to HTTP Created: 14/Jul/14  Updated: 18/Jul/14  Resolved: 18/Jul/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.4.0-dp1, 2.4.0-beta
Fix Version/s: 2.4.0
Security Level: Public

Type: Task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The configuration provider may erroneously revert to CCCP in cases where the client sleeps in between operations. In this case the timer to request a new configuration expires during the sleep interval and the library then assumes that the provider has failed.

This is also caused by the CCCP provider not cancelling its timeout when a new configuration has been received, but only when the actual refresh has been paused.




[CCBC-476] Create EL7 repositories Created: 12/Jul/14  Updated: 17/Jul/14  Resolved: 17/Jul/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4.0
Security Level: Public

Type: Task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Mark Nunberg [ 15/Jul/14 ]
I've managed to build the RPMs. however I need a system to test this on...




3.0 API Changes (CCBC-462)

[CCBC-479] Use built-in C89 int/short/long/etc where possible Created: 16/Jul/14  Updated: 16/Jul/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: Public

Type: Technical task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
There's no good reason to use fixed width types for simple functions that aren't expected to have a specified value. int/unsigned will be sufficient. Leave the fixed width types for things that actually expect large values.




[CCBC-478] setting large design doc terminates the program Created: 16/Jul/14  Updated: 16/Jul/14  Resolved: 16/Jul/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4.0-dp1
Security Level: Public

Type: Bug Priority: Major
Reporter: sjoerd@weett.nl Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Node.js


 Description   
I have a design document which plans with dates. In CouchDB I used to import the libraries 'moment.js' and 'later.js'. When I upload the same design document to CouchBase, the nodejs program fails with this message:

FATAL ERROR:
    libcouchbase experienced an unrecoverable error and terminates the program
    to avoid undefined behavior.
    The program should have generated a "corefile" which may used
    to gather more information about the problem.
    If your system doesn't create "corefiles" I can tell you that the
    assertion failed in ../deps/lcb/src/http.c at line 268
16 Jul 09:38:40 - [nodemon] app crashed - waiting for file changes before starting...

Removing one library (reducing the code size of the design document) resolves the issue. 25kb of code works, 50kb of js code fails

 Comments   
Comment by Mark Nunberg [ 16/Jul/14 ]
The problem is that the code never calls ringbuffer_ensure_capacity before appending the extra bytes. Since normally the ringbuffer preallocates at minimum around 4k we never notice this with smaller body sizes; but with larger body sizes it seems to show itself.

The newer version (2.4.x) should not suffer from this problem since it does not use the ringbuffer from this purpose but rather lcb_string, whose allocation/resizing is done internally upon appending.
Comment by sjoerd@weett.nl [ 16/Jul/14 ]
I installed the dev version of couchbase node which uses the updated libocuchbase and can confim you are right!
Thanks for the awesome job on CouchBase!




[CCBC-211] libcouchbase may touch a failed node after failover Created: 21/May/13  Updated: 14/Jul/14  Resolved: 26/Jun/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.0.6
Fix Version/s: 2.4.0-beta
Security Level: Public

Type: Bug Priority: Major
Reporter: Ivan Chernetsky Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Observed on CentOS (details in the description)

Issue Links:
Relates to

 Description   
Library version: v2.0.6 (compiled from the source code, on x64)
Server version: v2.0.1
Number of nodes in my test setup: 3 (2 x CentOS 6.2 x64, and 1 x CentOS 5.8 x86, if it's of any relevance)

Steps to reproduce:

1. Create a new cluster
2. Print the returned value by lcb_get_server_list function (there shoud be 3 servers printed)
3. Bring down network on one of servers
4. Try to put several values, until one of them is routed to the failed node. The library should return an error, which is expected.
5. Repeat 2
6. Manually fail over the failed node.
7. Print the returned value by lcb_get_server_list function (there should be 2 servers printed)
8. Try to put several values, until one of them is routed to the failed node. This behaviour is not expected.
9. Start rebalance.
10. While rebalancing takes place, a request might be routed to the failed node. It is not expected as well.
11. Once rebalance is completed, no requests are routed to the failed node. It is as expected.

Thanks in advance for your support.

 Comments   
Comment by Mark Nunberg [ 03/Feb/14 ]
Can you explain what you mean by "Touching" the node?

Failing over the node simply promotes its replica (if any) as master. If your cluster doesn't have a sufficient number of replicas, all data on the failed node is _lost_ and no node can replace ownership of the vbuckets for the failed node until you rebalance.
Comment by Mark Nunberg [ 26/Jun/14 ]
As long as the client library receives a proper configuration updates, a command will not be routed to a failed node. In the rare case that it is routed to such a node, it will be internally requeued and retried against the appropriate node.




[CCBC-375] Migrate to Doxygen Created: 17/Apr/14  Updated: 11/Jul/14  Resolved: 29/Apr/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: docs
Affects Version/s: None
Fix Version/s: 2.4.0-dp1
Security Level: Public

Type: Task Priority: Critical
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks CCBC-369 lcb_create manpage does not mention v... Resolved

 Description   
This allows us to write documentation in a single place and not duplicate things in headers and standalone manpages.




[CCBC-458] Allow to disable refresh-on-views-error Created: 25/Jun/14  Updated: 10/Jul/14  Resolved: 10/Jul/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.0, 2.3.1, 2.3.2
Fix Version/s: 2.4.0-beta
Security Level: Public

Type: Improvement Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Currently when an HTTP error is received we automatically take this as a cue to refresh the configuration. While the side effects are generally harmless (because of throttling) they are troublesome to analyze in the logs and are a waste of network resources. Since this behavior exists primarily for views-only workload we should look into adding an option to disable this behavior and/or disable it by default.

We may also possibly implement the proper "Heuristics Checking" specified in a proposal somewhere too..

 Comments   
Comment by Mark Nunberg [ 10/Jul/14 ]
http://review.couchbase.org/39288




[CCBC-405] Throw appropriate error on empty key Created: 02/May/14  Updated: 10/Jul/14  Resolved: 10/Jul/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4.0-beta
Security Level: Public

Type: Bug Priority: Major
Reporter: Jon Moses Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: OSX 10.9, LCB 2.3.0

$ cbc version
cbc built from: libcouchbase 2.3.0_15_g0b04b36 (rev. 0b04b36c1ef8d568271ea402b582e4339b81c8f3)
    using libcouchbase: 2.3.0 (libevent)
    using libyajl: 2.0.4

Attachments: File minimal.c    

 Description   
If I issue a query that returns 0x07, the next two queries, regardless of validity will return 0x10 instead of the expected results.

See 'minimal.c' attached

 Comments   
Comment by Sergey Avseyev [ 02/May/14 ]
Expected output:
$ example/minimal/minimal
STORED "foo" CAS: 17097673194045177856
GOT "foo" CAS: 17097673194045177856 FLAGS:0x0 SIZE:3
bar
GET ERROR: Invalid input/arguments (0x7)
GOT "foo" CAS: 17097673194045177856 FLAGS:0x0 SIZE:3
bar


Actual output:
$ example/minimal/minimal
STORED "foo" CAS: 580788420889542656
GOT "foo" CAS: 580788420889542656 FLAGS:0x0 SIZE:3
bar
GET ERROR: Invalid input/arguments (0x7)
ERROR: Network failure (0x10), (null)


Matt, do you know whether the server defines behaviour on empty key (zero length)
Comment by Mark Nunberg [ 02/May/14 ]
The error callback is not and never has been a reliable way to programmatically extract the error from an operation. For what it's worth, 2.2.0 exhibits the same behavior:

+ LD_LIBRARY_PATH=/sources/libcouchbase-2.0.7/inst/lib ./minimal
Using libcouchbase 2.0.7
STORED "foo" CAS: 858236688785346304
GOT "foo" CAS: 858236688785346304 FLAGS:0x0 SIZE:3
bar
GET ERROR: Invalid arguments (0x7)
GOT "foo" CAS: 858236688785346304 FLAGS:0x0 SIZE:3
bar
+ LD_LIBRARY_PATH=/sources/libcouchbase-2.1.3/inst/lib ./minimal
Using libcouchbase 2.1.3
STORED "foo" CAS: 5565267957526957824
GOT "foo" CAS: 5565267957526957824 FLAGS:0x0 SIZE:3
bar
GET ERROR: Invalid arguments (0x7)
ERROR: Network error (0x10), (null)
+ LD_LIBRARY_PATH=/sources/libcouchbase-2.2.0/inst/lib ./minimal
Using libcouchbase 2.2.0
STORED "foo" CAS: 8308748484727672576
GOT "foo" CAS: 8308748484727672576 FLAGS:0x0 SIZE:3
bar
GET ERROR: Invalid arguments (0x7)
ERROR: Network error (0x10), (null)
+ LD_LIBRARY_PATH=/sources/libcouchbase-2.3.0/inst/lib ./minimal
Using libcouchbase 2.3.0
STORED "foo" CAS: 3755695023363067648
GOT "foo" CAS: 3755695023363067648 FLAGS:0x0 SIZE:3
bar
GET ERROR: Invalid input/arguments (0x7)
GET ERROR: Network failure (0x10)
ERROR: Network failure (0x10), (null)


The issue seems to be in the client assuming a specific behavior of error_callback which is not guaranteed.
Comment by Jon Moses [ 02/May/14 ]
I'm not sure if the behavior expresses with a different initial error than 0x07, that's just the one that I reproduced from my data.
Comment by Mark Nunberg [ 02/May/14 ]
If you're scheduling commands asynchronously, then the failed commands in the pipeline will end up being invoked with the error received. This is actually correct behavior since the server is closing the socket.

Observe:

recvmsg(6, {msg_name(0)=NULL, msg_iov(1)=[{"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 65495}], msg_controllen=0, msg_flags=0}, 0) = 0
write(2, "GET ERROR: Invalid input/argumen"..., 41GET ERROR: Invalid input/arguments (0x7)
) = 41
epoll_ctl(3, EPOLL_CTL_DEL, 6, {EPOLLIN, {u32=6, u64=6}}) = 0
close(6) = 0
write(2, "ERROR: Network failure (0x10), ("..., 38ERROR: Network failure (0x10), (null)
) = 38


The first command gets EINVAL, and the error callback is invoked from it. The subsequent read from the socket returns 0 indicating the server has closed the connection which causes the remaining commands to fail with LCB_NETWORK_ERROR.
Comment by Mark Nunberg [ 02/May/14 ]
Proper solution is to return an error (either at lcb level or sdk level) if the key is empty.
Comment by Mark Nunberg [ 10/Jul/14 ]
http://review.couchbase.org/39284




[CCBC-233] Provide new version of arguments with common ABI header Created: 26/Jul/13  Updated: 09/Jul/14  Resolved: 09/Jul/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.0.7
Fix Version/s: 2.4.0-beta
Security Level: Public

Type: Task Priority: Critical
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Our current argument structure doesn't have a simple ABI for common fields. This results in duplicate code for almost all implementations using libcouchbase because they must make sure that common fields such as "key" and "nkey" (and possibly also "cas") are dereferenced correctly in each structure.

A new version of arguments should be added which would unify the common fields of all commands, and allow code to "cast" the command structure to a common base type.

This also ties in to the C++ wrappers in which I'm forced to currently either use templates or use virtual if I am going to properly deal with fields

 Comments   
Comment by Mark Nunberg [ 08/Jul/14 ]
This isn't tied to a specific commit, but is related to the ongoing API3 stuff.




[CCBC-226] Support HTTP keepalive semantics for views Created: 15/Jul/13  Updated: 09/Jul/14  Resolved: 09/Jul/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4.0-beta
Security Level: Public

Type: Task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks PYCBC-171 Too many open connections when runnin... Resolved

 Description   
Keep-Alive

 Comments   
Comment by Matt Ingenthron [ 20/Aug/13 ]
keepalive is hard btw mordy__ @ 2:30

no doubt ingenthr @ 2:31

yes, probably we will start it as the latest tas avsej @ 2:31

though, we have only one server implementation, so we may be able to cut some corners w.r.t. the actual HTTP spec ingenthr @ 2:31
if that's where the weird stuff is 2:31
 
ingenthr: the most difficult is stale connection tracking mordy__ @ 2:31

ah ingenthr @ 2:31
that makes sense 2:32
 
since tyou have no way to know if a connection is closed or not unless you try to use it mordy__ @ 2:32

that sounds familiar ingenthr @ 2:32

so then you need to keep state in knowing whether a "cached" connection was used and apply retry logic mordy__ @ 2:33
Comment by Mark Nunberg [ 07/Jul/14 ]
Now that we have generic and well tested connection pool functionality within the library, this is simple to do. I decided to add this after seeing the immense numbers of HTTP connections during running the tests. This change should keep that down, and perhaps as a side effect, reduce some of the bugginess witnessed in the tests.
Comment by Mark Nunberg [ 07/Jul/14 ]
http://review.couchbase.org/#/c/39146/




[CCBC-471] Retried HTTP request may hang client Created: 06/Jul/14  Updated: 09/Jul/14  Resolved: 09/Jul/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.4.0-dp1
Fix Version/s: 2.4.0-beta
Security Level: Public

Type: Task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
If a request is retried as a result of an HTTP redirect, it will increment the pendops counter (which indicates how many pending operations remain until the event loop should stop and control be returned back to the user); however the counter is decremented only once -- when the request finishes.

 Comments   
Comment by Mark Nunberg [ 06/Jul/14 ]
http://review.couchbase.org/39143




[CCBC-430] Ensure SSL is properly setup in threaded environments Created: 25/May/14  Updated: 09/Jul/14  Resolved: 09/Jul/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.4.0-dp1
Fix Version/s: 2.4.0-beta
Security Level: Public

Type: Task Priority: Critical
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Also enusre SSL_library_init() etc is done correctly as well.

 Comments   
Comment by Mark Nunberg [ 07/Jul/14 ]
http://review.couchbase.org/39202




[CCBC-456] IOCP plugin aborts on init failure Created: 23/Jun/14  Updated: 09/Jul/14  Resolved: 09/Jul/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.1.2
Fix Version/s: 2.4.0-beta
Security Level: Public

Type: Task Priority: Major
Reporter: sdeigm42 Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Windows 7 / 64bit


 Description   
In some of the C client library function (at least in lcb_iocp_new_iops in libcouchbase/plugins/io/iocp/iocp_iops.c) the abort() method is called in case of an failure. This causes my entire application to terminate instead of giving me the chance to print out an appropriate failure message.

I would suggest to replace the abort() function call with a return of an appropriate error code.

 Comments   
Comment by Mark Nunberg [ 07/Jul/14 ]
I've written up a fix for this. Indeed in the specific location there, you may do better with just an error message; however in general it might be better to leave the abort()s where they are; it's better to have a program predictably crash and possibly leaving a core dump than have it unpredictably hang.
Comment by sdeigm42 [ 07/Jul/14 ]
For us and our customers an abort and the termination of our process in case of an failure which can happen during normal processing is unacceptable since we don't have any chance to report errors, do cleanup operations and other things. Of course our software is not 100% error free and could also crash for other reasons but hopefully only for programming errors and not for other situations like not enough sockets available or other missing resources. In my opinion a basic client library should never terminate a process.

The main reason why we are evaluating couchbase is the high availability of the database due to the cluster approach. Since our software is working in a 24/7 environment with minimal downtime any possible termination through libcouchbase would be a show stopper for us to use the library/database.
Comment by Mark Nunberg [ 07/Jul/14 ]
I'm more curious to know under which circumstances the original abort was seen in the first place. Are you operating in a memory constrained environment?
Comment by sdeigm42 [ 07/Jul/14 ]
We were doing stress tests from a Windows 7 client with 8GB memory agains a Redhat couchbase server. At some point we got a lot of network errors and then our software terminated. Later on we used a debugger to figure out that libcouchbase called the abort() method after the Windows function CreateIoCompletionPort() failed. So we had no chance to figure out why the Windows method failed, but I assume the system was running out of open socket descriptors.
Comment by Mark Nunberg [ 07/Jul/14 ]
http://review.couchbase.org/#/c/38817/
Comment by Mark Nunberg [ 07/Jul/14 ]
I'd be interested to know if the library was leaking sockets. Are you running views as part of your stress test?

I'd also recommend testing the 2.4 developer preview (and beta which will be released soon) if possible. Should probably fix any socket leaks.

Lacking that, please try the 2.3.2 version (our latest stable release). 2.1.2 is pretty old.
Comment by sdeigm42 [ 07/Jul/14 ]
We don't think that your library is leaking sockets since most of the time the stress tests complete without any problems. When the test cases failed some lcb_get and some lbc_store commands failed and lcb_strerror returned "Network error" and shortly after that our process aborted.

We are just running one view - and that just at the end of the test - to collect all keys that have to be deleted.

We will update to a newer version of libcouchbase as you suggested.

Just to summarize again: we have no problems with the library itself. Today we weren't even able to reproduce the problem at all. But we can not live with the theoretical problem that a limited resource is not available and our software terminates due to this fact. Since our software runs in a realtime environment where we get multiple inbound and outbound socket connections for various protocols (SQL databases, SOAP connections, HTTP connections ...) we are dependent on the underlying client libraries to report an error if some resource is not available. Otherwise we would have to control the overall socket usage of all these subsystems which is not feasible.
Comment by Mark Nunberg [ 07/Jul/14 ]
In your particular case, be aware the library creates a new TCP connection each time you query a view. This will be fixed in 2.4

I can't guarantee the code is free of other places where it may abort or crash due to allocation failure, though I believe the most common cases have been caught. If you see a certain place where this may happen, please report it.
Comment by sdeigm42 [ 08/Jul/14 ]
Ok, I will update to version 2.4 as soon as possible and if I encounter any new aborts I will report them.

Thanks for your great support!!




[CCBC-472] server_nodes returns only nodes specified via "host" argument Created: 03/Jul/14  Updated: 09/Jul/14  Resolved: 09/Jul/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: None
Fix Version/s: 2.4.0-beta
Security Level: Public

Type: Bug Priority: Major
Reporter: Pavel Paulau Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Python 2.7.6
lcb 2.3.2
couchbase 1.2.2


 Description   
https://gist.github.com/pavel-paulau/5f02459f73ee207a18aa

I'm pretty sure it's used to work. And it obviously has nothing to do with python sdk...

 Comments   
Comment by Mark Nunberg [ 03/Jul/14 ]
This is going to be fixed in libcouchbase 2.4. Unfortunately the way 'nodes' was implemented was rather confusing and would be dependent on HTTP bootstrap (which we only do selectively)
Comment by Pavel Paulau [ 03/Jul/14 ]
Thanks for clarification.

Two questions:
1. When do you plan to release 2.4
2. Is there any temporary workaround? I need list of servers for view queries via 3rd party HTTP library...
Comment by Mark Nunberg [ 07/Jul/14 ]
2.4 should have a beta out sometime this week which should hopefully fix this issue.

As for a temporary workaround - I'll see what I can come up with. Are you OK with a patch? :)
Comment by Pavel Paulau [ 07/Jul/14 ]
I temporary workaround-ed the problem but look forward to permanent fix.
Comment by Mark Nunberg [ 07/Jul/14 ]
http://review.couchbase.org/#/c/39158/




[CCBC-360] date mutated in libcouchbase's send buffer Created: 08/Apr/14  Updated: 08/Jul/14  Resolved: 08/Jul/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.2.0
Fix Version/s: 2.4.0-dp1
Security Level: Public

Type: Bug Priority: Blocker
Reporter: killgxlin Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: usability
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: libcouchbase-2.2.0
couchbase-server 2.2.0
ubuntu 13.04 g++ 4.8.1

Attachments: File key_3423.base64     File key_3423.hexdump     File key_3423.json    

 Description   
while true
  set 1000 json document to couchbase-server
  get 1000 json documents from couchbase-server
  some of them may become invalid json document

the test code is here https://github.com/killgxlin/libcouchbase_testcode
i think it may be a bug of libcouchbase. if not it may be a bug of myself ,please point out and mail me
killgxlin@hotmail.com please.

broken document is in attachment
key_*.base64 is the broken document saved in couchbase-server
key_*.json is a broken json which decoded from key_*base64,
key_*.hexdump is a hexdumped text from broken key_*.json

by watch key_*.hexdump i could see that the past of the document is overwroted by a network msgof couchbase which head is 80 01 PROTOCOL_BINARY_REQ PROTOCOL_BINARY_CMD_SET

 Comments   
Comment by Sergey Avseyev [ 13/Apr/14 ]
https://github.com/couchbase/libcouchbase/pull/13
Comment by Mark Nunberg [ 14/May/14 ]
This is dependent on having a 2.3.2 come out (or perhaps be supplied as a 2.3.x main release in the future)..




[CCBC-317] Consolidate lcb_list_t and lcb_clist_t Created: 03/Feb/14  Updated: 08/Jul/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: 2.3.0-dp2
Fix Version/s: .future
Security Level: Public

Type: Bug Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
We should split our our list implementation to a node type (next/prev) and a list type (which also contains size and some other metadata).




[CCBC-459] Provide error category indicating server is loaded Created: 26/Jun/14  Updated: 07/Jul/14  Resolved: 07/Jul/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.1, 2.4.0-dp1
Fix Version/s: 2.4.0-beta
Security Level: Public

Type: Task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
We should make a new error classifier (LCB_ERRTYPE_SRVLOAD) and LCB_EIFSRVLOAD to indicate that the error reply would be solved by a backoff.

Currently we have EIFTMP which includes these errors, but also includes some errors which are not strictly related to having a backoff interval.




3.0 API Changes (CCBC-462)

[CCBC-467] 3.0: Remove 'sanity check' and 'struct IDs' Created: 28/Jun/14  Updated: 07/Jul/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 3.0-beta
Fix Version/s: None
Security Level: Public

Type: Technical task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
These functions have not been widely used or maintained. Their purpose was to assist applications in verifying the structure sizes used by the library conformed to that of what their application was expecting. However in reality the structure sizes rarely changed, and when they did change, they only changed in compatible ways so that applications compiled against older versions would never break anyway.

Applications using newer versions of the structures would also never work anyway since the library itself would reject the newer versions at runtime.




[CCBC-470] Publish docs for C SDK July 2014 release Created: 01/Jul/14  Updated: 03/Jul/14  Resolved: 03/Jul/14

Status: Closed
Project: Couchbase C client library libcouchbase
Component/s: docs
Affects Version/s: 2.3.2
Fix Version/s: 2.3.2
Security Level: Public

Type: Task Priority: Major
Reporter: Amy Kurtzman Assignee: Amy Kurtzman
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[CCBC-435] Stale commands may be conflated with new responses Created: 31/May/14  Updated: 02/Jul/14  Resolved: 03/Jun/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.0-dp2
Fix Version/s: 2.3.2
Security Level: Public

Type: Task Priority: Critical
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: customer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Gantt: start-finish
Relates to

 Description   
When a response for a new command is received, the library may conflate this with an older version of the same command. This is because the "purge_implicit_responses" function is being called _after_ the request data is being retrieved for the response.

 Comments   
Comment by Mark Nunberg [ 31/May/14 ]
http://review.couchbase.org/#/c/37712/




[CCBC-413] Noisy warnings when extracting libcouchbase tarball Created: 13/May/14  Updated: 02/Jul/14  Resolved: 02/Jul/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.1
Fix Version/s: 2.3.2
Security Level: Public

Type: Bug Priority: Minor
Reporter: Michael Leib Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: CentOS 6, latest rpms installed from yum, tar --version reports "tar (GNU tar) 1.23"


 Description   
Got the latest 2.31 libcouchbase-2.3.1.tar.gz

gunzip the .gz => ok
tar xvf *.tar => not ok

...
libcouchbase-2.3.1/cmake/Modules/GenerateConfigDotH.cmake
tar: Ignoring unknown extended header keyword `SCHILY.dev'
tar: Ignoring unknown extended header keyword `SCHILY.ino'
tar: Ignoring unknown extended header keyword `SCHILY.nlink'
libcouchbase-2.3.1/cmake/Modules/GetLibcouchbaseFlags.cmake
tar: Ignoring unknown extended header keyword `SCHILY.dev'
tar: Ignoring unknown extended header keyword `SCHILY.ino'
tar: Ignoring unknown extended header keyword `SCHILY.nlink'
libcouchbase-2.3.1/cmake/Modules/GetPlatformCCInfo.cmake
tar: Ignoring unknown extended header keyword `SCHILY.dev'
tar: Ignoring unknown extended header keyword `SCHILY.ino'
tar: Ignoring unknown extended header keyword `SCHILY.nlink'
...

etc, etc

 Comments   
Comment by Mark Nunberg [ 13/May/14 ]
Despite the annoying messages from the output (I've yet to resolve this), the tar command does succeed. I've just verified this on a Centos system (6.5) and it all builds and extracts successfuly.
Comment by Mark Nunberg [ 13/May/14 ]
A quick google suggests this is the result of creating the archive on OS X: http://superuser.com/questions/318809/linux-os-x-tar-incompatibility-tarballs-created-onos-x-give-errors-when-unt




3.0 API Changes (CCBC-462)

[CCBC-469] Change all type names to lcb_TYPENAME rather than lcb_typename_t Created: 01/Jul/14  Updated: 01/Jul/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: None
Fix Version/s: 3.0-beta
Security Level: Public

Type: Technical task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The newer convention is done in most of the 2.4 codebase. Using this convention makes it easier to distinguish types inside source code and also allows the names to be more conformant to POSIX standards which technically prohibits the _t suffix from being used.

We can either remove the old names completely, or place them in deprecated.h.

Probably the most notable difference would be in the lcb_t -- which would need to be renamed to something like lcb_pBUCKET




[CCBC-421] Allow option to disable relocation of commands on failover Created: 20/May/14  Updated: 01/Jul/14  Resolved: 02/Jun/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.1
Fix Version/s: None
Security Level: Public

Type: Task Priority: Critical
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Won't Fix Votes: 0
Labels: customer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Provide option to disable rescheduling of commands to other nodes when topologies have changed. Packet-ng should handle this more gracefully, but it would still be helpful to avoid non-idempotent operations from being retried.

Currently we don't have the facilities to inspect (in 2.3.x) which operations should be retried and which shouldn't be, but we should add this as an extensible option in any event.

 Comments   
Comment by Mark Nunberg [ 02/Jun/14 ]
Has been resolved in a VF, but we're not gonna roll it into 2.3.x




3.0 API Changes (CCBC-462)

[CCBC-468] 3.0: Remove lcb_timer public API Created: 28/Jun/14  Updated: 28/Jun/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: None
Fix Version/s: 3.0-beta
Security Level: Public

Type: Technical task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The timer API was never really used and should have always been private (its use came in before we started having 'interface attributes' within the library)




[CCBC-462] 3.0 API Changes Created: 28/Jun/14  Updated: 28/Jun/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: None
Fix Version/s: 3.0-beta
Security Level: Public

Type: New Feature Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Sub-Tasks:
Key
Summary
Type
Status
Assignee
CCBC-463 3.0: Remove syncmode Technical task Open Mark Nunberg  
CCBC-464 3.0: Error code type should be lcb_ST... Technical task Open Mark Nunberg  
CCBC-465 3.0: Remove lcb_error_callback Technical task Open Mark Nunberg  
CCBC-466 3.0: Remove lcb_get_last_error Technical task Open Mark Nunberg  
CCBC-467 3.0: Remove 'sanity check' and 'struc... Technical task Open Mark Nunberg  
CCBC-468 3.0: Remove lcb_timer public API Technical task Open Mark Nunberg  
CCBC-469 Change all type names to lcb_TYPENAME... Technical task Open Mark Nunberg  
CCBC-479 Use built-in C89 int/short/long/etc w... Technical task Open Mark Nunberg  

 Description   
This is an umbrella task for the various changes which will take place in the 3.0 API. Some of these changes may be introduced as volatile within the 2.4 series, while some involve explicitly removing older APIs.

As a secondary goal of the 3.0 API, we hope to make it mostly API and ABI compatible with the 2.0 series, so that application changes can be gradual and minimal.




3.0 API Changes (CCBC-462)

[CCBC-466] 3.0: Remove lcb_get_last_error Created: 28/Jun/14  Updated: 28/Jun/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: None
Fix Version/s: 3.0-beta
Security Level: Public

Type: Technical task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
This function is deprecated and its use can result in false positives, true negatives. Most internals do not set 'last_error', and because there may be multiple things going on within the library, getting the last error does not make sense. Only operation specific error fields should be used.




3.0 API Changes (CCBC-462)

[CCBC-465] 3.0: Remove lcb_error_callback Created: 28/Jun/14  Updated: 28/Jun/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: None
Fix Version/s: 3.0-beta
Security Level: Public

Type: Technical task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
This API call has no use other than indicating bootstrap success/failure, and has been deprecated in favor of lcb_bootstrap_callback in 2.4




3.0 API Changes (CCBC-462)

[CCBC-464] 3.0: Error code type should be lcb_STATUS, not lcb_error_t Created: 28/Jun/14  Updated: 28/Jun/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: None
Fix Version/s: 3.0-beta
Security Level: Public

Type: Technical task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
In conformance with standards and more consistent names, we should call it lcb_STATUS rather than error; also considering that some codes are not necessarily errors :)




3.0 API Changes (CCBC-462)

[CCBC-463] 3.0: Remove syncmode Created: 28/Jun/14  Updated: 28/Jun/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 3.0-beta
Fix Version/s: None
Security Level: Public

Type: Technical task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[CCBC-386] Stabilize server module Created: 22/Apr/14  Updated: 27/Jun/14  Resolved: 27/Jun/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: None
Fix Version/s: 2.4.0-beta
Security Level: Public

Type: Task Priority: Critical
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
This is a meta-bug covering various fixes for the server.c code. This code is very much in flux because of the various changes around the modules it interacts with. It is also arguably the most complex and difficult to test part of our code because it is here where all the moving parts come together.

This bug exists to address the issue that these issues will not be fixed with a single commit, and will likely need to evolve over several commits in order to stabilize.

 Comments   
Comment by Mark Nunberg [ 01/May/14 ]
We really can't close this until tests have passed.




[CCBC-336] observe operations may not be retried when NMV received Created: 24/Feb/14  Updated: 26/Jun/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.0.0, 2.1.0, 2.1.1, 2.1.2, 2.1.3, 2.2.0, 2.3.0-dp2
Fix Version/s: .future
Security Level: Public

Type: Bug Priority: Critical
Reporter: Matt Ingenthron Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency

 Description   
During investigation of an issue, Mark Nunberg found that observe replies with NMV may not be retried in libcouchbase. Further, the differentiation between NMV and -1 (i.e., no node in this position) isn't clear from the way the library currently handles things.

The correct behavior is that on any NMV, the library will retry using an updated configuration. This will happen until timeout.

As a workaround, check for the state with a get() or retry the observe() at an application level until successful. It's recommended to retry with some kind of rate limiting and a maximum.


 Comments   
Comment by Mark Nunberg [ 26/Jun/14 ]
I've filed CCBC-461 which should hopefully provide visibility into NOT_MY_VBUCKET.

For the most common case of observe, which is the durability polling, the not-my-vbucket is effectively retried under the hood (in the sense that the polling will simply retry the observe command to all nodes) and is generally not a problem.

Since the packet format for observe differs from any other operation, the normal retry handling code would need to be fiddled with to make a special case for OBSERVE.

Any idea of how important this is?




[CCBC-460] phrasing on the getting started page is odd Created: 26/Jun/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Major
Reporter: Matt Ingenthron Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
On our current page, it has this section:

We are building windows versions of libcouchbase with two different MS runtimes: 9th (Visual Studio 2008), 10th (Visual Studio 2010) and 11th (Visual Studio 2012) versions, to simplify linking for your application. Just choose the appropriate zip archive:

That's phrased a bit odd. Please fix.

 Comments   
Comment by Mark Nunberg [ 26/Jun/14 ]
Windows

Archives for Windows are included. Bundled in the archive are the header files (inside include), the dynamic library (bin/libcouchbase.dll), the import library (lib/libcouchbase.lib) and the debug variants (bin/libcouchbase_d.dll and lib/libcouchbase_d.lib). The cbc utility is included as well.

If you wish to link against libcouchbase from a Windows application, you must select the archive appropriate for the version of Visual Studio being used to compile your application.




[CCBC-271] create index files in package repositories Created: 18/Sep/13  Updated: 26/Jun/14  Resolved: 26/Jun/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: Public

Type: Task Priority: Minor
Reporter: Matt Ingenthron Assignee: Matt Ingenthron
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File package-index.txt    

 Description   
Per recent discussion, the apt indexes have only the most recent versions in the index. This is normal.

Suggestion is to either create an index per directory or turn on auto-index generation.

This issue is to request creating indexes within the directory structure so archive files may be found.

 Comments   
Comment by Sergey Avseyev [ 18/Sep/13 ]
The list all releases. The early releases accessible as sources only.
Comment by Matt Ingenthron [ 18/Sep/13 ]
That's good to have for now, but what I mean to be asking for is that we update some kind of index up on the S3 bucket (or wherever, if we move it) every time we add packages. I think you got that, but just checking.
Comment by Sergey Avseyev [ 19/Sep/13 ]
I rather against of just indexing s3 bucket, because it contains some extra files and intermediate releases. What we need is the page like for server, where people could download any release
Comment by Mark Nunberg [ 26/Jun/14 ]
http://packages.couchbase.com/clients/c/index.html -- does this solve things?

We can make similar pages for other clients if needed - of course it would be nice to have a way to automate the running of ths script
Comment by Matt Ingenthron [ 26/Jun/14 ]
That's sufficient for this issue, thanks. We need to approach the website with a better way of handling things.




[CCBC-308] provide built artifacts for windows Created: 29/Jan/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: None
Fix Version/s: None
Security Level: Public

Type: Improvement Priority: Minor
Reporter: Matt Ingenthron Assignee: Matt Ingenthron
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
To facilitate easy software building for Windows users, we should provide a .zip file of artifacts.

 Comments   
Comment by Mark Nunberg [ 15/Apr/14 ]
I'm not sure what this means. We already provide builds for Windows and have done so since early on. If you meant something else, reassign back to me
Comment by Mark Nunberg [ 26/Jun/14 ]
I'm closing this because I believe this issue has been resolved. However since I'm not entirely sure what this issue implies (we have always had .zip files for windows) please re-open and add explanation if necessary
Comment by Matt Ingenthron [ 26/Jun/14 ]
I believe it was missing when this was filed. I think we're good.




[CCBC-256] Enhance intelligence of client to know about all nodes of a cluster for making REST connection Created: 27/Aug/13  Updated: 26/Jun/14  Resolved: 26/Jun/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: docs
Affects Version/s: 2.1.1
Fix Version/s: None
Security Level: Public

Type: Improvement Priority: Major
Reporter: Perry Krug Assignee: Matt Ingenthron
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
If configured with a single host (a load balancer), the client may pause for everytime it loses this connection. The same thing happens when configured with a list of hosts and the client reaches the end of the list...it pauses before going back to the top.

I don't think it's appropriate to ask for the client to constantly spin on trying to make a connection if in fact none can be made.

Another solution to this would be to have the client be aware of ALL the servers in a cluster (which it gets via the vbucket map info) and be able to try all of them, and/or know which ones are alive so that it doesn't have to wait

 Comments   
Comment by Perry Krug [ 27/Aug/13 ]
And this would need integration with the higher level languages (php/python/ruby/etc)
Comment by Mark Nunberg [ 10/Jan/14 ]
The key issue of network programming when dealing with unresponsive servers is not knowing why a particular host is "unresponsive". A user-defined setting can tune between "Availability" and "Trying to reduce spinning", but those two criteria cannot be satisfied at the same time.
Comment by Perry Krug [ 10/Jan/14 ]
Matt, I believe CCCP/unibrow has taken care of this issue correct?
Comment by Mark Nunberg [ 26/Jun/14 ]
I believe this leads into a greater question of whether we support load balancers or not. Currently the client will _learn_ about the other hosts and make connections to them (For both config and data), discarding any user-supplied node list.

With a load balancer the client must be instructed to explicitly _ignore_ any topology information it discovers about the cluster (wrt selecting a configuration provided node).
Comment by Perry Krug [ 26/Jun/14 ]
The core issue here is already resolved with the latest updates to the client (CCCP and unibrow)




[CCBC-418] Not-My-Vbucket may result in immediate timeouts Created: 19/May/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: 2.3.1
Fix Version/s: 2.4.0-beta
Security Level: Public

Type: Bug Priority: Critical
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
[EDIT] remove previous description after analysis

This is specific to the case when there is only a single node and a new node is being added. In this case we will get a not-my-vbucket during the first relocation. Since the node has not yet been added (the current I/O handler must first return to the event loop) the client has nowhere that it can forward the command to, and ends up dispatching it with a not-my-vbucket.

 Comments   
Comment by Mark Nunberg [ 19/May/14 ]
This will probably only be fixed in packet-ng
Comment by Mark Nunberg [ 26/Jun/14 ]
Note that an ETIMEDOUT may still be issued, however the client can requeue the operation upon receipt of such error.




[CCBC-251] replace the jira logo for CCBC with something modern Created: 20/Aug/13  Updated: 26/Jun/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: docs
Affects Version/s: None
Fix Version/s: None
Security Level: Public

Type: Task Priority: Trivial
Reporter: Matt Ingenthron Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[CCBC-422] Build Ubuntu 14.04 packages and provide them in a repo Created: 20/May/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.1
Fix Version/s: 2.4.0-dp1
Security Level: Public

Type: Task Priority: Critical
Reporter: Brent Woodruff Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
In our installation documentation, we reference several repositories one can use to install libcouchbase on Ubuntu 10.04, 11.10, and 12.04:

http://docs.couchbase.com/couchbase-sdk-c-2.3/index.html#ubuntu

Ubuntu 14.04 has been released, making it the most recent LTS release. The 14.04 LTS release is to be maintained through 2019. Please prepare an Ubuntu 14.04 package of libcouchbase and provide it via an apt repository.

 Comments   
Comment by Mark Nunberg [ 20/May/14 ]
I'll need to set up a VM environment and see exactly why we need so many varied ubuntu dists.




[CCBC-377] Handle API/ABI modifications from 2.x => 3.0/2.4 Created: 20/Apr/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: 2.4.0-dp1
Fix Version/s: 2.4.0-beta
Security Level: Public

Type: Task Priority: Blocker
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Sub-Tasks:
Key
Summary
Type
Status
Assignee
CCBC-111 Make iops functions 'private', and di... Technical task Resolved Mark Nunberg  
CCBC-365 Restore syncmode functionality (if ne... Technical task Resolved Mark Nunberg  
CCBC-378 lcb_socket_t is DWORD on Win32, not int Technical task Resolved Mark Nunberg  
CCBC-381 Deprecate all the simple lcb_set_FOO/... Technical task Resolved Mark Nunberg  
CCBC-403 Restore 'memcached compat' functional... Technical task Resolved Mark Nunberg  

 Description   
This is a parent task for handling/documenting API/ABI changes and removals between those versions.

Some of the changes represent features which are too difficult to maintain in an 3.0/2.4 version while others represent different ABI and API changes to previous APIs which were error prone.

The goal of this bug is to be able to review these changes as the work on 2.4/3.0 stabilizes so that features may be re-added if deemed necessary.




[CCBC-400] Improve API doc navbar layout Created: 29/Apr/14  Updated: 26/Jun/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: docs
Affects Version/s: None
Fix Version/s: .future
Security Level: Public

Type: Task Priority: Trivial
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

- If I click on "Introduction" from the "Couchbase C Client" the left hand menu folds up.
- Introduction is in a funny place in the list on the left.





[CCBC-454] Provide clearer API to obtain REST hosts (and other types of hosts for external use) Created: 19/Jun/14  Updated: 25/Jun/14  Resolved: 25/Jun/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4.0-beta
Security Level: Public

Type: Task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Currently we have lcb_get_server_list, lcb_get_host, and lcb_get_port. All these functions are confusing and rather clumsy to use. We should rather have something that reflects how the server works today with its varied connection options.

Folks will most likely wish to use either the views or rest admin ports.

 Comments   
Comment by Mark Nunberg [ 25/Jun/14 ]
http://review.couchbase.org/38810




[CCBC-452] Rename 'dsn' module to something more correct Created: 17/Jun/14  Updated: 25/Jun/14  Resolved: 25/Jun/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.4.0-dp1
Fix Version/s: 2.4.0-beta
Security Level: Public

Type: Task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Mark Nunberg [ 24/Jun/14 ]
http://review.couchbase.org/#/c/38770/




[CCBC-393] Add apidoc section about environment variables Created: 25/Apr/14  Updated: 25/Jun/14  Resolved: 25/Jun/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4.0-beta
Security Level: Public

Type: Task Priority: Critical
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Mark Nunberg [ 24/Jun/14 ]
http://review.couchbase.org/#/c/38777/




Handle API/ABI modifications from 2.x => 3.0/2.4 (CCBC-377)

[CCBC-403] Restore 'memcached compat' functionality. Created: 01/May/14  Updated: 25/Jun/14  Resolved: 25/Jun/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: None
Fix Version/s: 2.4.0-beta
Security Level: Public

Type: Technical task Priority: Critical
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
This functionality is broken in 2.2.0+

We should check if we want to re-add this before GA, or leave it alone.

 Comments   
Comment by Matt Ingenthron [ 01/May/14 ]
what does `memcached compat` mean?
Comment by Mark Nunberg [ 01/May/14 ]
Basically the ability to connect to a dumb memcached cluster without a vbucket config etc.

The question is:

(1) Do we want to support this functionality? I can see it being "cute" but I'm not sure how useful it would be
(2) Does anything rely on this functionality? My answer is 'NO' considering that it's been broken for quite some time.
Comment by Matt Ingenthron [ 01/May/14 ]
It was useful for isolating issues in the past. I think the answer for #1 is probably not, but I wouldn't be unhappy if we maintained it and not to my knowledge on #2.
Comment by Mark Nunberg [ 01/May/14 ]
Yeah, my thoughts are similar. It shouldn't be too hard to readd it either; It's just not the time to do it yet -- and mark it @volatile or similar.
Comment by Mark Nunberg [ 24/Jun/14 ]
http://review.couchbase.org/#/c/38752/




[CCBC-431] Replace vbucket_* function usages with new lcbvb prefix universally. Created: 25/May/14  Updated: 24/Jun/14  Resolved: 24/Jun/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: 2.4.0-dp1
Fix Version/s: 2.4.0-beta
Security Level: Public

Type: Task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[CCBC-453] pillowfight: Add 'pause-at-end' option Created: 19/Jun/14  Updated: 24/Jun/14  Resolved: 24/Jun/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.1
Fix Version/s: 2.4.0-beta
Security Level: Public

Type: Improvement Priority: Major
Reporter: Dave Rigby Assignee: Dave Rigby
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
For certain load testing, it is useful to see what the cost of established connections is on the application and/or server. Therefore add a new option to pillowfight to pause at the end of execution (with all connections held open) to be able to measure the cost (memory, threads, FDs etc) of keeping them open.


 Comments   
Comment by Dave Rigby [ 19/Jun/14 ]
http://review.couchbase.org/#/c/38473/




[CCBC-457] pillowfight fails to connect to non-standard port Created: 24/Jun/14  Updated: 24/Jun/14  Resolved: 24/Jun/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.4.0-dp1
Fix Version/s: 2.4.0-beta
Security Level: Public

Type: Bug Priority: Major
Reporter: Dave Rigby Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: OS X Mavericks, master branch (4d6a266)


 Description   
Running pillowfitght and attempting to connect to a cluster running on port 9000 fails. This works fine with the release23 branch (8e337a8).

I see the following in the logs when attempting to connect:

$ LCB_LOGLEVEL=5 bin/cbc-pillowfight -h localhost:9000
    Creating instance 00ms [I0] {1287} [INFO] (instance - L:451) Version=2.4.0-dp1-9-g13916c5, Changeset=13916c5e25b63bc2b54324ca7817d1e29d47d1b7
    0ms [I0] {1287} [INFO] (instance - L:452) Effective connection string: couchbase://localhost:9000/default?. Bucket=default
    0ms [I0] {1287} [DEBUG] (instance - L:189) Adding host localhost:9000 to initial CCCP bootstrap list
    0ms [I0] {1287} [DEBUG] (confmon - L:94) Provider FILE is DISABLED
    0ms [I0] {1287} [DEBUG] (confmon - L:91) Provider CCCP is ENABLED
    0ms [I0] {1287} [DEBUG] (confmon - L:91) Provider HTTP is ENABLED
    0ms [I0] {1287} [TRACE] (confmon - L:263) Start refresh requested
    0ms [I0] {1287} [TRACE] (confmon - L:243) Current provider is CCCP
    0ms [I0] {1287} [DEBUG] (lcbio_mgr - L:383) <localhost:9000> (HE=0x7fc369008e00) Creating new connection because none are available in the pool
    0ms [I0] {1287} [DEBUG] (lcbio_mgr - L:301) <localhost:9000> (HE=0x7fc369008e00) Starting connection on I=0x7fc368604db0
    0ms [I0] {1287} [INFO] (connection - L:423) <localhost:9000> (SOCK=0x7fc368604ed0) Starting. Timeout=2000000us
    3ms [I0] {1287} [TRACE] (connection - L:241) <localhost:9000> (SOCK=0x7fc368604ed0) Got event handler for new connection
    3ms [I0] {1287} [TRACE] (connection - L:288) <localhost:9000> (SOCK=0x7fc368604ed0) Scheduling asynchronous watch for socket.
    3ms [I0] {1287} [TRACE] (connection - L:241) <localhost:9000> (SOCK=0x7fc368604ed0) Got event handler for new connection
    3ms [I0] {1287} [INFO] (connection - L:99) <localhost:9000> (SOCK=0x7fc368604ed0) Connected
    3ms [I0] {1287} [DEBUG] (lcbio_mgr - L:255) <localhost:9000> (HE=0x7fc369008e00) Received result for I=0x7fc368604db0,C=0x7fc368604ed0; E=0x0
    3ms [I0] {1287} [DEBUG] (lcbio_mgr - L:206) <localhost:9000> (HE=0x7fc369008e00) Assigning R=0x7fc368604be0 SOCKET=0x7fc368604ed0
    3ms [I0] {1287} [DEBUG] (ioctx - L:75) <localhost:9000> (CTX=0x7fc36a100700,unknown) Pairing with SOCK=0x7fc368604ed0
    3ms [I0] {1287} [ERROR] (negotiation - L:162) <localhost:9000> (SASLREQ=0x7fc36a100000) Error: 0x10, IO Error
    3ms [I0] {1287} [ERROR] (cccp - L:130) <NOHOST:NOPORT> Got I/O Error=0x10
    3ms [I0] {1287} [INFO] (confmon - L:190) Provider 'CCCP' failed
    3ms [I0] {1287} [DEBUG] (ioctx - L:125) <localhost:9000> (CTX=0x7fc36a100700,sasl) Destroying. PND=0,ENT=0,SORC=1
    104ms [I0] {1287} [TRACE] (confmon - L:243) Current provider is HTTP
    104ms [I0] {1287} [TRACE] (htconfig - L:393) Starting HTTP Configuration Provider 0x7fc369003400
    104ms [I0] {1287} [ERROR] (htconfig - L:397) Not scheduling HTTP provider since no nodes have been configured for HTTP bootstrap
    104ms [I0] {1287} [INFO] (confmon - L:190) Provider 'HTTP' failed
    104ms [I0] {1287} [TRACE] (confmon - L:204) Maximum provider reached. Resetting index
    104ms [I0] {1287} [ERROR] (bootstrap - L:96) Failed to bootstrap client=0x7fc368603ab0. Code=0xa, Message=No more bootstrap providers remain

    Failed to connect: Error while establishing TCP connection


For comparison, on release23 I see the following (working):

    $ LCB_LOGLEVEL=5 bin/cbc-pillowfight -h localhost:9000
    Creating instance 00ms [I0] [TRACE] (confmon - L:56) Creating monitor...
    0ms [I0] [DEBUG] (confmon - L:91) Have 2 providers enabled
    0ms [I0] [TRACE] (confmon - L:253) Start refresh requested
    0ms [I0] [TRACE] (confmon - L:229) Current provider is 2
    0ms [I0] [DEBUG] (connmgr - L:262) Got request R=0x7fab53830400,localhost:11210
    0ms [I0] [INFO] (connmgr - L:221) Starting connection on I=0x7fab53405e00,C=0x7fab53405e18
    0ms [I0] [INFO] (connection - L:407) Starting connection (0x7fab53405e18) to localhost:11210
    2ms [I0] [ERROR] (connection - L:123) Connection=0x7fab53405e18 failedLCBERR=0x18, OS Err=61
    2ms [I0] [INFO] (connmgr - L:173) Received result for I=0x7fab53405e00,C=0x7fab53405e18; E=0x18
    2ms [I0] [DEBUG] (cccp - L:304) CCCP Socket connected
    2ms [I0] [ERROR] (cccp - L:141) Got I/O Error=0x18
    2ms [I0] [INFO] (confmon - L:175) Provider [2] failed
    103ms [I0] [TRACE] (confmon - L:229) Current provider is 3
    103ms [I0] [TRACE] (htconfig - L:283) Starting HTTP Configuration Provider 0x7fab53814600
    103ms [I0] [INFO] (connection - L:407) Starting connection (0x7fab53814648) to localhost:9000
    103ms [I0] [INFO] (connection - L:137) Connection=0x7fab53814648,localhost:9000 completed succesfully
    103ms [I0] [DEBUG] (htconfig - L:229) Successfuly connected to REST API localhost:9000
    104ms [I0] [TRACE] (htconfig - L:129) Received 200 bytes on HTTP stream
    104ms [I0] [TRACE] (htconfig - L:145) HTTP not yet done. Err=0x25
    112ms [I0] [TRACE] (htconfig - L:129) Received 8411 bytes on HTTP stream
    112ms [I0] [DEBUG] (htconfig - L:140) Generation 0 -> 1
    112ms [I0] [INFO] (confmon - L:151) Setting new configuration of type 3
    112ms [I0] [DEBUG] (file - L:242) Got updated configuration. Flushing to file
    112ms [I0] [DEBUG] (bootstrap - L:58) Instance configured!

    113ms [I0] [DEBUG] (connmgr - L:262) Got request R=0x7fab56018c00,192.168.0.81:12000
    113ms [I0] [INFO] (connmgr - L:221) Starting connection on I=0x7fab552006c0,C=0x7fab552006d8
    113ms [I0] [INFO] (connection - L:407) Starting connection (0x7fab552006d8) to 192.168.0.81:12000
    113ms [I0] [INFO] (connection - L:137) Connection=0x7fab552006d8,192.168.0.81:12000 completed succesfully
    113ms [I0] [INFO] (connmgr - L:173) Received result for I=0x7fab552006c0,C=0x7fab552006d8; E=0x0
    113ms [I0] [INFO] (connmgr - L:160) Assigning R=0x7fab56018c00,c=0x7fab552006d8
    113ms [I0] [DEBUG] (connmgr - L:262) Got request R=0x7fab5601be00,127.0.0.1:12002
    113ms [I0] [INFO] (connmgr - L:221) Starting connection on I=0x7fab55200d70,C=0x7fab55200d88
    113ms [I0] [INFO] (connection - L:407) Starting connection (0x7fab55200d88) to 127.0.0.1:12002
    113ms [I0] [INFO] (connection - L:137) Connection=0x7fab55200d88,127.0.0.1:12002 completed succesfully
    113ms [I0] [INFO] (connmgr - L:173) Received result for I=0x7fab55200d70,C=0x7fab55200d88; E=0x0
    113ms [I0] [INFO] (connmgr - L:160) Assigning R=0x7fab5601be00,c=0x7fab55200d88
    358ms [I0] [INFO] (connmgr - L:402) Reclaiming connection I=0x7fab552006c0,Cu=0x7fab560080d8,Cp=0x7fab552006d8 (192.168.0.81:12000)
    358ms [I0] [INFO] (connmgr - L:402) Reclaiming connection I=0x7fab55200d70,Cu=0x7fab56008690,Cp=0x7fab55200d88 (127.0.0.1:12002)

 Comments   
Comment by Mark Nunberg [ 24/Jun/14 ]
http://review.couchbase.org/38743




[CCBC-455] Restore support for 'cbcrc' file Created: 20/Jun/14  Updated: 23/Jun/14  Resolved: 23/Jun/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.4.0-dp1
Fix Version/s: 2.4.0-beta
Security Level: Public

Type: Task Priority: Blocker
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[CCBC-444] Can't handle out-of-order responses to concurrent GET requests. Created: 04/Jun/14  Updated: 20/Jun/14  Resolved: 05/Jun/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.1
Fix Version/s: 2.4.0-dp1
Security Level: Public

Type: Bug Priority: Major
Reporter: Kevin Kingdon Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: customer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Centos 6.4, 64-bit, Couchbase-Server 2.2

Attachments: Text File purge_single_server.txt    

 Description   
We are using libcouchbase in an event-driven mode using libev, sharing the event loop between libcouchbase and our application. IWe instantiate a single library instance and send multiple "single get" requests before the callback from the first request. There is a chance that Couchbase server will send an out-of-order response to one of the GET requests. When that happens, libcouchbase returns an internal error: "Unknown implicit send message op=0" After debugging in the libcouchbase code, we see that the code only handles out-of-order responses for GETQ or GATQ or NOP opcodes. This implies that the application must wait after submitting a single get request to libcouchbase until the callback for that get request is invoked before submitting a second get request.

We believe that libcouchbase should handle the out-of-order responses. The data is there in the transaction log ring buffer to match the response to the request and issue the callback. If the application issues multiple concurrent GET requests, no immediate error is returned and the internal ring buffers grow to accommodate the outstanding requests. Indeed, if no out-of-order response happens, everything works. Forcing a single request at a time cuts our Couchbase transactions per second in half from around 9K tps to less than 5K tps.

 Comments   
Comment by Mark Nunberg [ 04/Jun/14 ]
Perhaps CCBC-435 is related to your issue.

In any event the next version (i.e. 2.4) will feature command lookup by opaque only and not rely on any implicit ordering of responses - thus not relying on request ordering at all.

The current behavior for memcached is to always serve requests in order - so unless you're running a modified memcached this should not be happening in the first place. But again, please see the CCBC-435 issue which I believe is the cause of what you're seeing now.
Comment by Kevin Kingdon [ 05/Jun/14 ]
I believe that we will still hit the internal error inside of lcb_server_purge_implicit_responses(). We will hit the switch statement starting on line 707 in server.c and take the default case. (The opcode of the request throwing the error is PROTOCOL_BINARY_CMD_GET.) The change you made doesn't appear to affect this code path because we were already not hitting the internal error condition in lcb_proto_parse_single. The switch statement anticipates receiving a response to a later request before a response to an earlier request, but only for a multi-get. Single-get responses must be received in-order or we will hit the default switch case and fail.

I don't know why the response for the later request is received from Couchbase server prior to the response to the earlier request. I'm not sure what constitutes a stale request, but the requests in our application are closely spaced in time -- we are issuing 9K requests per second to libcouchbase in our application. Our application log files don't show a significant time gap between the earlier request (whose response was skipped) and the later request whose response was received first.

Our application is expecting a callback of some kind for each request accepted by libcouchbase. When the internal error callback is made, all of the requests outstanding in libcouchbase at the time are lost and no callback to our app is made. The only workaround we have is to time out the request in our app and respond with an error to our app's remote client. If we don't destroy the library instance and recreate it before issuing new requests, the next few requests return a "network error" to the request callback. We are able to successfully retry those requests. Even if we destroy the library instance after the internal error, we still would lose the requests in the cmd_log ring buffer at the time of the error.
Comment by Mark Nunberg [ 05/Jun/14 ]
If there's a bug in the library, it may be in the assignment of the 'opaque' value, or in comparing the timestamps between the requests. In any event, the issue is resolved in the upcoming major release. See https://github.com/couchbase/libcouchbase/blob/1c602553e4502f3eec8f605f910ccffa283b2d9c/src/mc/mcreq.c#L540-553

If you can confirm you're getting responses out of order though, it'd be a bug in memcached
Comment by Kevin Kingdon [ 05/Jun/14 ]
-- "If you can confirm you're getting responses out of order though, it'd be a bug in memcached "

We are currently testing with a 2-node Couchbase cluster. In this configuration, individual GET requests can be sent to different nodes, based on the respective key hashes. Each node would respond in-order to the requests that node received, but collectively, the two nodes could respond out-of-order with respect to the order in which requests were submitted to libcouchbase. It is a testament to the ultra-fast responsiveness of Couchbase that we don't see a higher percentage of out-of-order responses.
Comment by Mark Nunberg [ 05/Jun/14 ]
Ok, but the code in question only cares about responses received on an individual server. Each server can be thought of as an individual pipeline that is isolated from all other servers. While it is certainly possible and common to receive responses out of order from the perspective of an application (i.e. key1 is mapped to server1 and key2 is mapped to server2, and server2 responds before server1 does) this should not affect the I/O logic of the application itself which is always scoped to the individual server in question.
Comment by Mark Nunberg [ 06/Jun/14 ]
Just checking on this, can you try with an older version of the library (i.e. 2.2.0) and see if that helps? - see http://packages.couchbase.com/clients/c/index.html for a listing of older versions
Comment by Kevin Kingdon [ 06/Jun/14 ]
Unfortunately, we had to move to 2.3.0 to get the CCBC-270 fix. We use libev. We were hitting this issue when we start our application while Couchbase server is still warming up. Our app shares the event loop with libcouchbase.

I plan on working on this issue some more next week. I will do a private build of 2.3.1 with additional instrumentation to track our app's requests through the libcouchbase library. Hopefully that will provide an additional clue. We tried serializing requests to libcouchbase, but that has a severe performance impact, primarily because we end up serializing both view-based and memcached-based requests into the same application queue. I would rather not have to do a lot of rework at the app level to work around this, but we are now experiencing lost requests and consequent memory leaks. The subsystem that is waiting for responses from the "database" module times out and sends an error response to the remote client, but the "database" module that provides the application wrapper for Couchbase is leaking the requests it assumes would come back in libcouchbase callbacks.
Comment by Mark Nunberg [ 06/Jun/14 ]
Yours sounds like a very typical use case - though the "unknown implicit send message" is rare - we haven't seen this in 2.3.x. Typically the "high risk" factors are when you have a rebalance or failover -- then you end up with relocating commands and timeouts (which should still work, but is obviously a less travelled code path)

Also, have you tried to use the built in logging feature (just set LCB_LOGLEVEL in the environment, with a value of 1-5 (5 being the highest)) to see what might possibly be going wrong?

You can also try to compile the libev plugin for 2.3.x and use it with 2.2 - it's worth a shot
Comment by Kevin Kingdon [ 19/Jun/14 ]
I was able to find the root cause of this issue. It is in the libev plugin. Occasionally, (especially when many of requests are being sent at once), the EV_WRITE event for a connection is not triggered, and the library never sends one request to the server. When a later request is sent and its response is received, libcouchbase is still expecting a response to the unsent request. This triggers the internal-error path during the ensuing attempt to clean up. The fix is to force an EV_WRITE event when updating the LCB_WRITE_EVENT flag for the connection. Fixed code below:

static int lcb_io_update_event(struct lcb_io_opt_st *iops,
                               lcb_socket_t sock,
                               void *event,
                               short flags,
                               void *cb_data,
                               void (*handler)(lcb_socket_t sock,
                                               short which,
                                               void *cb_data))
{
    struct libev_cookie *io_cookie = iops->v.v0.cookie;
    struct libev_event *evt = event;
    int events = EV_NONE;

    if (flags & LCB_READ_EVENT) {
        events |= EV_READ;
    }
    if (flags & LCB_WRITE_EVENT) {
        events |= EV_WRITE;
    }

    if (events == evt->ev.io.events && handler == evt->handler) {
        /* no change! */
        return 0;
    }

    ev_io_stop(io_cookie->loop, &evt->ev.io);
    evt->data = cb_data;
    evt->handler = handler;
    ev_init(&evt->ev.io, handler_thunk);
    ev_io_set(&evt->ev.io, sock, events);
// KWK -- redundant -- ev_io_stop(io_cookie->loop, &evt->ev.io);
    ev_io_start(io_cookie->loop, &evt->ev.io);
// KWK
    // If we are setting the write flag, force a write event to become pending.
    // Otherwise, occasionally we miss triggering this
    if (flags & LCB_WRITE_EVENT) {
        ev_feed_event(io_cookie->loop, &evt->ev.io, EV_WRITE);
    }
// KWK

    return 0;
}
Comment by Kevin Kingdon [ 19/Jun/14 ]
BTW, This now passes my libcouchbase stress test where I have up to 800 'get' requests outstanding with libcouchbase at one time. (I am issuing a total of 300K get request distributed to 10 lcb instances running in 10 separate threads, each with its own event loop.)
Comment by Mark Nunberg [ 19/Jun/14 ]
This sounds quite strange. Does this happen if you use a different libev backend? AFAIK libev should use level-triggered events rather than edge-triggered ones. Perhaps this is a bug inside libcouchbase somewhere else where the write event is mistakenly unscheduled?
Comment by Kevin Kingdon [ 20/Jun/14 ]
I reverted my patch to the libev plugin and added back some of my instrumentation of libcouchbase. I am including a trace below of a sequence of 'get' requests and responses. The 'seq' is the packet/request 'opaque' value. When the 'parse_single' is called with a packet 'seq' greater than the expected request 'seq', the internal error will occur. The 'seq' not sent is 4742. I don't yet know why the conn->output ringbuffer's read_head moves from seq(4742) to seq(4745) without seq(4742) being written.

v0_handle:try-write:conn(0x7f8694015d18):seq(4738)
parse_single:conn(0x7f8694015d18):seq(4735)=req-seq(4735)
parse_single:conn(0x7f8694015d18):seq(4736)=req-seq(4736)
single_get:conn(0x7f8694015d18):seq(4742)
lcb_sockrw_set_want:write-wanted:conn(0x7f8694015d18):seq(4742)
lcb_sockrw_apply_want:write-scheduled:conn(0x7f8694015d18):seq(4742)
parse_single:conn(0x7f8694015d18):seq(4737)=req-seq(4737)
lcb_sockrw_set_want:write-wanted:conn(0x7f8694015d18):seq(4742)
lcb_sockrw_apply_want:write-scheduled:conn(0x7f8694015d18):seq(4742)
single_get:conn(0x7f8694015d18):seq(4743)
lcb_sockrw_set_want:write-wanted:conn(0x7f8694015d18):seq(4742)
lcb_sockrw_apply_want:write-scheduled:conn(0x7f8694015d18):seq(4742)
single_get:conn(0x7f8694015d18):seq(4744)
lcb_sockrw_set_want:write-wanted:conn(0x7f8694015d18):seq(4742)
lcb_sockrw_apply_want:write-scheduled:conn(0x7f8694015d18):seq(4742)
parse_single:conn(0x7f8694015d18):seq(4738)=req-seq(4738)
parse_single:conn(0x7f8694015d18):seq(4739)=req-seq(4739)
parse_single:conn(0x7f8694015d18):seq(4740)=req-seq(4740)
single_get:conn(0x7f8694015d18):seq(4745)
lcb_sockrw_set_want:write-wanted:conn(0x7f8694015d18):seq(4745)
lcb_sockrw_apply_want:write-scheduled:conn(0x7f8694015d18):seq(4745)
lcb_sockrw_set_want:write-wanted:conn(0x7f8694015d18):seq(4745)
lcb_sockrw_apply_want:write-scheduled:conn(0x7f8694015d18):seq(4745)
single_get:conn(0x7f8694015d18):seq(4746)
lcb_sockrw_set_want:write-wanted:conn(0x7f8694015d18):seq(4745)
lcb_sockrw_apply_want:write-scheduled:conn(0x7f8694015d18):seq(4745)
v0_handler:try-write:conn(0x7f8694015d18):seq(4745)
single_get:conn(0x7f8694015d18):seq(4748)
lcb_sockrw_set_want:write-wanted:conn(0x7f8694015d18):seq(4748)
lcb_sockrw_apply_want:write-scheduled:conn(0x7f8694015d18):seq(4748)
single_get:conn(0x7f8694015d18):seq(4750)
lcb_sockrw_set_want:write-wanted:conn(0x7f8694015d18):seq(4748)
lcb_sockrw_apply_want:write-scheduled:conn(0x7f8694015d18):seq(4748)
single_get:conn(0x7f8694015d18):seq(4751)
lcb_sockrw_set_want:write-wanted:conn(0x7f8694015d18):seq(4748)
lcb_sockrw_apply_want:write-scheduled:conn(0x7f8694015d18):seq(4748)
v0_handler:try-write:conn(0x7f8694015d18):seq(4748)
parse_single:conn(0x7f8694015d18):seq(4745)>req-seq(4742)
Comment by Kevin Kingdon [ 20/Jun/14 ]
Per your suggestion, I re-ran the stress test with LIBEV_FLAGS=1, LIBEV_FLAGS=2, and LIBEV_FLAGS=4, to try various libev backends. In each case, libcouchbase failed to send one or more 'get' requests to the couchbase server.
Comment by Kevin Kingdon [ 20/Jun/14 ]
OK, I think I've found the root cause of the issue, and also have an explanation for why my workaround actually helps. In 2.3.1, there is a per-connection timer that fires and checks for stale requests in the command log. The code in purge_single_server() is called to check for and fail any stale requests. The problem in the purge_single_server() implementation is that it incorrectly assumes that the connection's output ring-buffer has the same request at the read-head as does the command-log ring-buffer. But this is not the case when some requests have been sent to the server and not yet received responses; in this case, the output ring-buffer has consumed the transmitted requests and is either now empty or has some later requests yet-to-be sent. In this latter case, the purge_single_server() code is broken -- it is attempting to remove an unsent request from the output ring buffer that may not even be present. In the particular run-through I examined, the earliest request in the command-log hadn't timed out, so no command failure was triggered, but the code near the bottom of purge_single_server() reset the output ring buffer without preserving the unsent requests. (The # of bytes to be sent was less than the number of bytes in the command-log ring buffer, triggering the reset without copying the unsent requests.)

The workaround I proposed works, I believe, because the i/o watcher is made pending before the timer watcher becomes pending. So the i/o callback is earlier in the pending list than the timer callback. The i/o callback tries to send the output ring buffer, and would nearly always succeed (always worked in my tests). When the timer fires, the output ring buffer is empty, and the broken purge_single_server() handling of the output ring buffer is avoided.

Fixing this in 2.3.1 would be difficult (for me, in any case). It would require either ignoring the output ring buffer, which might result in later responses for stale requests, or it would require tracking the relationship between requests in the command log and their position in the output ring buffer. I know the code has been entirely reworked for 2.4, so this may no longer be an issue.
Comment by Kevin Kingdon [ 20/Jun/14 ]
I've attached a modified version of purge_single_server() that attempts to fix the issue with the command-log ring-buffer being out-of-sync with the connection output ring-buffer.




[CCBC-273] Increase granularity of timings below 9ms for pillowfight Created: 25/Sep/13  Updated: 20/Jun/14  Resolved: 20/Jun/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: None
Fix Version/s: 2.4.0-dp1
Security Level: Public

Type: Improvement Priority: Trivial
Reporter: Perry Krug Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The current timings output from a pillowfight run groups 1-9ms together:
[1380106215.425126] Run
              +---------+---------+---------+---------+
[ 1 - 9]ms |######################################## - 102733
[ 10 - 19]ms | - 97
[ 20 - 29]ms | - 78
[ 30 - 39]ms | - 30
[ 40 - 49]ms | - 7
[ 50 - 59]ms | - 35
[ 60 - 69]ms | - 10
[ 70 - 79]ms | - 3
[ 80 - 89]ms | - 3
[ 90 - 99]ms | - 2
[180 - 189]ms | - 3
[190 - 199]ms | - 1
[200 - 209]ms | - 2
              +----------------------------------------

It would be very helpful to get much more granular below 9ms and even below 1ms.

Similar to what ./cbstats timings outputs, we want to measure 0-500us, 500us to 1ms, 1-2ms, and 2-3ms...and then can probably jump up to 9/19/29/etc ms

 Comments   
Comment by Mark Nunberg [ 02/Jun/14 ]
libcouchbase can output timings well below several microseconds. The reason they are all grouped between 1-9ms is because they are all taking between 1-9ms.
Comment by Perry Krug [ 02/Jun/14 ]
Yes, I see that in other runs of pillowfight. The problem is more about the granularity...most of our customers are looking for the distribution of requests between 500us and 2ms, with an upper bound of 5ms. Could we augment the timings outputs to be more in line with what the server is reporting as I stated in the description?
Comment by Mark Nunberg [ 02/Jun/14 ]
It's possible, but not trivial to do so (for me at least)
Comment by Mark Nunberg [ 20/Jun/14 ]
[990 - 999 ]us |#### - 262
[2000 - 2099]us |###################################### - 2417
[2100 - 2199]us |####################################### - 2473
[2200 - 2299]us |###################################### - 2435
[2300 - 2399]us |###################################### - 2434
[2400 - 2499]us |####################################### - 2494
[2500 - 2599]us |######################################## - 2502
[2600 - 2699]us |####################################### - 2463
[2700 - 2799]us |###################################### - 2396
[2800 - 2899]us |##################################### - 2373
[2900 - 2999]us |####################################### - 2460
[3000 - 3099]us |####################################### - 2440
[3100 - 3199]us |################################# - 2081
[3200 - 3299]us |##################### - 1374
[3300 - 3399]us |############ - 758
[3400 - 3499]us |###### - 435
[3500 - 3599]us |### - 237
[3600 - 3699]us |# - 124
[3700 - 3799]us |# - 103
[3800 - 3899]us |# - 71
[3900 - 3999]us |# - 65
[4000 - 4099]us | - 48
[4100 - 4199]us | - 43
[4200 - 4299]us |# - 108
[4300 - 4399]us | - 35
[4400 - 4499]us | - 19
[4500 - 4599]us | - 6
[4600 - 4699]us | - 6




[CCBC-380] It is impossible to pass additional params to CFLAGS and LDFLAGS during CMAKE build Created: 21/Apr/14  Updated: 19/Jun/14  Resolved: 19/Jun/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4.0-dp1
Security Level: Public

Type: Bug Priority: Minor
Reporter: Haster Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Now it is impossible to pass some additional parameters to CFLAGS and LDFLAGS when you use cmake for building libcouchbase.
As a result I can't pass D_REENTRANT parameter, so the building is not reentrant.
When I use autotools, the D_REENTARNT flag is already added to CFLAGS

 Comments   
Comment by Mark Nunberg [ 01/May/14 ]
You'd need to edit the build script yourself and do this. Unlike autotools, CMake is not the most friendly when it comes to user-specific customizations.
Curious, why do you need to define _REENTRANT?

I'll see if I can maybe add a 'Customizations' file to include to modify the build flags for all relevant stuff (for the sake of user customizations) but it'd need to be file-based, not CLI-based.
Comment by Haster [ 02/May/14 ]
I just compare it with another libraries that use CMAKE for build. Usualy they allow you to set CFLAGS and LDFLAGS.
_REENTRANT is needed because my app is multithread and I need that errno was different in each thread
Comment by Mark Nunberg [ 12/May/14 ]
Also, are you using cmake directly, or via cmake/configure?
Comment by Haster [ 12/May/14 ]
I am using cmake/configure
Comment by Mark Nunberg [ 18/Jun/14 ]
http://review.couchbase.org/#/c/38467/
Comment by Mark Nunberg [ 19/Jun/14 ]
See if this works for you :)




[CCBC-440] Apply new shuffle algorithm to packet-ng Created: 03/Jun/14  Updated: 18/Jun/14  Resolved: 03/Jun/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: None
Fix Version/s: None
Security Level: Public

Type: Task Priority: Critical
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates to
relates to CCBC-433 hostlist_randomize skips the first ho... Resolved

 Description   
See CCBC-433

 Comments   
Comment by Mark Nunberg [ 18/Jun/14 ]
http://review.couchbase.org/37790




[CCBC-344] add support for SSL to libcouchbase in support of Couchbase Server 3.0 Created: 10/Mar/14  Updated: 18/Jun/14  Resolved: 26/May/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: docs, library
Affects Version/s: None
Fix Version/s: 2.4.0-dp1
Security Level: Public

Type: New Feature Priority: Critical
Reporter: Matt Ingenthron Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Issue Links:
Dependency
blocks PCBC-272 Implement SSL support Resolved
blocks MB-10084 Sub-Task: Changes required for Data E... Open
Relates to
relates to CCBC-374 Implement SSL Transport For 3.0 Server Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
CCBC-425 implement SSL I/O Core with OpenSSL f... Technical task Resolved Mark Nunberg  
CCBC-426 Make data connections use SSL encrypt... Technical task Resolved Mark Nunberg  

 Description   
In support of Couchbase Server 3.0, please add SSL support to the client library. Check with the requirements repo and/or Aliaksey K. for pointers to information on this feature.

If the integration is complex, it may be useful to get an initial version for testing purposes and then get the integration complete for a future release.

Note this should include man page coverage of how to enable the feature.

 Comments   
Comment by Brett Lawson [ 20/Mar/14 ]
Due to the nature of the numerous IO paths within libcouchbase, this feature is non-trivial to implement. There is currently a significant amount of refactoring taking place in regards to the IO handling within the library by @mnunberg and because of this I have put this on hold temporarily until everything has stabilized. In the interim, I have however tested SSL support with my javascript-only client library written for Node.js, and the server itself appears to behave correctly in regards to handling SSL connections and performing operations across this connection.

Cheers, Brett
Comment by Mark Nunberg [ 21/May/14 ]
http://review.couchbase.org/37336
Comment by Mark Nunberg [ 21/May/14 ]
http://review.couchbase.org/#/c/37339/




[CCBC-374] Implement SSL Transport For 3.0 Server Created: 17/Apr/14  Updated: 18/Jun/14  Resolved: 21/Apr/14

Status: Closed
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: None
Fix Version/s: 2.4.0-dp1
Security Level: Public

Type: Task Priority: Critical
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates to
relates to CCBC-344 add support for SSL to libcouchbase i... Resolved

 Comments   
Comment by Mark Nunberg [ 21/Apr/14 ]
CCBC-344




[CCBC-332] libcouchbase does not compare revids before overwritting configs Created: 20/Feb/14  Updated: 18/Jun/14  Resolved: 28/Apr/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.0-dp2
Fix Version/s: 2.3.1
Security Level: Public

Type: Task Priority: Major
Reporter: Brett Lawson Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Gantt: start-finish
is triggering CCBC-364 cbc-pillowfight slow during topology ... Resolved

 Description   
libcouchbase currently ignores the revid information attached to the bucket-config data potentially causing a stale configuration to be made active within libcouchbase.

 Comments   
Comment by Mark Nunberg [ 23/Apr/14 ]
http://review.couchbase.org/#/c/36253/
Comment by Mark Nunberg [ 25/Apr/14 ]
Merged in 2.3.1
Comment by Mark Nunberg [ 28/Apr/14 ]
http://review.couchbase.org/#/c/36253/ (2.4)
Comment by Mark Nunberg [ 28/Apr/14 ]
Merged in 2.4




[CCBC-376] Memory leak in cJSON/VBucket config parsing Created: 20/Apr/14  Updated: 18/Jun/14  Resolved: 25/Apr/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.0
Fix Version/s: 2.3.1
Security Level: Public

Type: Bug Priority: Critical
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Mark Nunberg [ 23/Apr/14 ]
Fixed in 2.4, awaiting review on 2.3




[CCBC-384] It is needed to handle WSAETIMEDOUT in iocp_w32err_2errno Created: 22/Apr/14  Updated: 18/Jun/14  Resolved: 23/Apr/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: 2.2.0, 2.3.0
Fix Version/s: 2.3.1
Security Level: Public

Type: Bug Priority: Critical
Reporter: Haster Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
I have got WSAETIMEDOUT error when I libcouchbase with iocp plugin on Win32.

And because iocp_w32err_2errno doesn't handle WSAETIMEDOUT the default case was choosen and as
result my application was terminated by abort();

 Comments   
Comment by Haster [ 22/Apr/14 ]
I fixed it in my app by adding lines:

case WSAETIMEDOUT:
   return ETIMEDOUT;
Comment by Mark Nunberg [ 22/Apr/14 ]
http://review.couchbase.org/#/c/36140/

This will be fixed in 2.4.0 (not _next_ release, the one after that); for 2.3.1 it's sufficient to not abort.
Comment by Mark Nunberg [ 23/Apr/14 ]
http://review.couchbase.org/#/c/36140/




[CCBC-407] select io mode should not define "fd_set" struct array. Only one "fd_set" variable is OK. Created: 05/May/14  Updated: 18/Jun/14  Resolved: 08/May/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.2.0, 2.3.0
Fix Version/s: 2.3.1
Security Level: Public

Type: Bug Priority: Critical
Reporter: whl0630 Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: memory-use
Σ Remaining Estimate: 20m Remaining Estimate: 20m
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: 20m Original Estimate: 20m
Environment: no relation with os env

Sub-Tasks:
Key
Summary
Type
Status
Assignee
CCBC-408 FORWARDPORT: => Select fixups for 2.4... Technical task Resolved Mark Nunberg  

 Description   
The fd_set struct related definition (e.g. fd_set readfds[FD_SETSIZE]; ) in "plugins\io\select\plugin-select.c" should be only one item, not array, like: fd_set readfds. Because fd_set has been a set array.

In our os env, FD_SETSIZE is 51200, which means "readfds[FD_SETSIZE]" will consume very large memory.



 Comments   
Comment by Mark Nunberg [ 06/May/14 ]
Thank you for the input. I'll fix it ASAP.
Comment by Mark Nunberg [ 06/May/14 ]
http://review.couchbase.org/36758




[CCBC-414] cccp_cookie is never assigned to cccp_provider Created: 14/May/14  Updated: 18/Jun/14  Resolved: 20/May/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.0
Fix Version/s: 2.3.2
Security Level: Public

Type: Task Priority: Critical
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
We never assign cccp_cookie to cccp->cmdcookie, thereby not allowing us to set an ignore flag when the object is being released.

 Comments   
Comment by Mark Nunberg [ 20/May/14 ]
http://review.couchbase.org/#/c/37321/




[CCBC-395] Add configuration cache API via lcb_cntl() Created: 25/Apr/14  Updated: 18/Jun/14  Resolved: 29/Apr/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: None
Fix Version/s: 2.3.1
Security Level: Public

Type: Improvement Priority: Critical
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates to
relates to CCBC-392 ABI compatibility broken on 2.3 when ... Resolved

 Description   
This would add a simple api to use lcb_cntl(instance, LCB_CNTL_SET, LCB_CNTL_CONFIGCACHE, "filename"); which would be applied to an already-created instance.

 Comments   
Comment by Mark Nunberg [ 25/Apr/14 ]
http://review.couchbase.org/#/c/36330/
Comment by Mark Nunberg [ 25/Apr/14 ]
Fixed in 2.3. Pending merged in 2.4




select io mode should not define "fd_set" struct array. Only one "fd_set" variable is OK. (CCBC-407)

[CCBC-408] FORWARDPORT: => Select fixups for 2.4/3.0 Created: 06/May/14  Updated: 18/Jun/14  Resolved: 25/May/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: Public

Type: Technical task Priority: Critical
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Mark Nunberg [ 21/May/14 ]
http://review.couchbase.org/37388




[CCBC-371] FORWARDPORT (2.4) - Incorrect error raised when using node_list: property Created: 17/Apr/14  Updated: 18/Jun/14  Resolved: 28/Apr/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.0
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
If you use the node_list property and try to connect to a cluster for a bucket that doesn't exist, you get:
Couchbase::Error::Timeout instead of Couchbase::Error::BucketNotFound

This can mess up scripts that rescue the BucketNotFound and create the bucket if it's not there. Timeout implies other problems (connectivity problems) which isn't the case.

gems/ruby-2.1.0/gems/couchbase-1.3.6/lib/couchbase.rb:63:in `initialize': No more bootstrap providers remain (error=0x17) (Couchbase::Error::Timeout)


 Comments   
Comment by Mark Nunberg [ 17/Apr/14 ]
CCBC-368
Comment by Mark Nunberg [ 27/Apr/14 ]
http://review.couchbase.org/36399




[CCBC-372] FORWARDPORT (2.4) - Couchbase::Error::Invalid: failed to schedule document request (key="/pools/default/buckets/default/ddocs", error=0x07) after upgrade to 2.3 Created: 17/Apr/14  Updated: 18/Jun/14  Resolved: 28/Apr/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: 2.3.0
Fix Version/s: None
Security Level: Public

Type: Task Priority: Critical
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
http://www.couchbase.com/communities/q-and-a/error-after-updating-libcouchbase-22-23

Assigning to sergey first to see if this is not a ruby issue. I've tried something similar on Python and have it working as expected.

 Comments   
Comment by Mark Nunberg [ 17/Apr/14 ]
CCBC-367
Comment by Mark Nunberg [ 27/Apr/14 ]
http://review.couchbase.org/36400
Comment by Mark Nunberg [ 28/Apr/14 ]
Merged in 2.4




[CCBC-373] FORWARDPORT (2.4) - lcb_get_host/lcb_get_port may not return host:port for same host Created: 17/Apr/14  Updated: 18/Jun/14  Resolved: 29/Apr/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.0
Fix Version/s: None
Security Level: Public

Type: Task Priority: Critical
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
These two API calls select a host at random if there is no current "Rest Host"

 Comments   
Comment by Mark Nunberg [ 17/Apr/14 ]
CCBC-370
Comment by Mark Nunberg [ 27/Apr/14 ]
http://review.couchbase.org/36401




[CCBC-451] info log instance configuration at time of creation Created: 16/Jun/14  Updated: 18/Jun/14  Resolved: 18/Jun/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4.0-dp1
Security Level: Public

Type: