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

Status: Open
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: Unresolved 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.




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




[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-474] Failure to schedule commands may leak memory Created: 10/Jul/14  Updated: 10/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


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




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

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: docs
Affects Version/s: 2.3.2
Fix Version/s: 2.3.3
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   
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-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-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-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





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




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)




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.




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




[CCBC-461] Unmask NOT_MY_VBUCKET return codes. Created: 26/Jun/14  Updated: 14/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: 2.4.0
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-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-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.




[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-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-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-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-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-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-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-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: Improvement 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   
It is useful when reviewing logs to diagnose an issue to see what parameters were provided and tunables have been adjusted. This would be very helpful from a field serviceability perspective.

This is related to CCBC-447.

 Comments   
Comment by Mark Nunberg [ 17/Jun/14 ]
http://review.couchbase.org/#/c/38365/
Comment by Mark Nunberg [ 17/Jun/14 ]
0ms [I0] [INFO] (instance - L:414) Version=2.3.0, Changeset=b09f8ce84be9b3bbcde1ba1be66e3f281d37bed2
0ms [I0] [INFO] (instance - L:415) Effective connection string: couchbase://localhost/default?console_log_level=2&
0ms [I0] [INFO] (lcbio_mgr - L:303) <localhost:11210> (HE=0x1a3c260) Starting connection on I=0x1a3c8b0
0ms [I0] [INFO] (connection - L:421) <localhost:11210> (SOCK=0x1a3c9f0) Starting. Timeout=2000000us
1ms [I0] [INFO] (connection - L:99) <localhost:11210> (SOCK=0x1a3c9f0) Connected
1ms [I0] [INFO] (lcbio_mgr - L:257) <localhost:11210> (HE=0x1a3c260) Received result for I=0x1a3c8b0,C=0x1a3c9f0; E=0x0
1ms [I0] [INFO] (lcbio_mgr - L:240) <localhost:11210> (HE=0x1a3c260) Assigning R=0x1a3c210 SOCKET=0x1a3c9f0
1ms [I0] [INFO] (ioctx - L:75) <localhost:11210> (CTX=0x1a3e2a0,unknown) Pairing with SOCK=0x1a3c9f0
2ms [I0] [INFO] (ioctx - L:125) <localhost:11210> (CTX=0x1a3e2a0,sasl) Destroying. PND=0,ENT=1,SORC=1
2ms [I0] [INFO] (ioctx - L:75) <localhost:11210> (CTX=0x1a46790,unknown) Pairing with SOCK=0x1a3c9f0
2ms [I0] [INFO] (ioctx - L:125) <localhost:11210> (CTX=0x1a46790,unknown) Destroying. PND=0,ENT=1,SORC=1
2ms [I0] [INFO] (lcbio_mgr - L:463) <localhost:11210> (HE=0x1a3c260) Reclaiming connection I=0x1a3c8b0,C=0x1a3c9f0
3ms [I0] [INFO] (confmon - L:162) Setting new configuration. Received via CCCP
3ms [I0] [INFO] (ioctx - L:75) <localhost:11210> (CTX=0x1a3e370,unknown) Pairing with SOCK=0x1a3c9f0
3ms [I0] [INFO] (server - L:457) <localhost:11210> (SRV=0x1a4af80,IX=0) Setting initial timeout=2499ms
foo The key does not exist on the server (0xd)
4ms [I0] [INFO] (ioctx - L:125) <localhost:11210> (CTX=0x1a3e370,memcached) Destroying. PND=0,ENT=0,SORC=1
Comment by Matt Ingenthron [ 17/Jun/14 ]
Honestly, that's not very user friendly. It looks a bit too much like in the weeds debugging logging.

Can you remove the line number and module? Also lines like these seem like they shouldn't be info level and haven't anything user actionable.:
1ms [I0] [INFO] (lcbio_mgr - L:257) <localhost:11210> (HE=0x1a3c260) Received result for I=0x1a3c8b0,C=0x1a3c9f0; E=0x0
1ms [I0] [INFO] (lcbio_mgr - L:240) <localhost:11210> (HE=0x1a3c260) Assigning R=0x1a3c210 SOCKET=0x1a3c9f0

Added Brett and Don as watchers as well... would be good to get more feedback.
Comment by Brett Lawson [ 17/Jun/14 ]
I agree that quite a few of those should fall under DEBUG logging. Additionally, having the line number helps debug, but I also agree it should not show in usual log messages, perhaps a flag to enable or disable that kind of information?
Comment by Mark Nunberg [ 17/Jun/14 ]
Logging is off by default. The information displayed to the screen and their respective levels are:
(1) Still a work in progress.
(2) Only displayed during connection state changes, such that in steady mode there should never be any messages printed to the screen.

Perhaps we can make a google doc elsewhere for more suggestions on levels/displays/formatting/etc. which can pertain to the logging library. For starters the file/line information has been invaluable in helping diagnose issues when given logs from users. Yes they are a bit of line noise to the user but give an immense amount of insight as to what the application is doing from a developers perspective.
Comment by Matt Ingenthron [ 17/Jun/14 ]
Understood that it's off by default, but I think we should be thinking about CONFIG or INFO level as something that is intended to be used as *on* by default.

I also understand what you're saying on line numbers, but this should be thought about from the end user's UX, not what is most useful to us. Unfortunately, this one currently reads more like tracing than logging of important events.

One possible approach is that you have multiple log lines in the same place in the file. In other words, you may log a bit at INFO level and a lot more at DEBUG level. Another approach, as Brett recommends, is different log formatters.
Comment by Mark Nunberg [ 18/Jun/14 ]
The individual issue has been fixed. We should have a comb-through of the logging system in the future to determine a better way to handle this. One thing that comes to mind is extending the logging API - and making it volatile again (it has been volatile in 2.3.x) to be able to extend it with more flexibility.
Comment by Mark Nunberg [ 18/Jun/14 ]
Don, that is exactly what we already have. My key concern is about the callback and what exactly would be passed to it. For example the naive approach is that there is only a level/function/file/message; however with a library like libcouchbase we also add:

* Subsystem
* Instance ID

and we'd like to add:
* Host:Port
* Associated "context pointer"

The library is complex and asynchronous which means that there are:
(1) Many things happening
(2) The things aren't happening in a specified order
(3) There are possibly multiple concurrent instances of the same "thing" happening

A good example would be issuing multiple concurrent view requests. The requests may have the same destination and the same instance associated with them and would only differ by the local TCP port as well as the context pointer associated with them.

Another good (and very common) example is having multiple instances of the library operating within the same thread. We've actually run into this issue previously and added a new parameter to the callback just before the 2.3.1 release adding this field.

Of course will all this information I may consider moving to a struct-based callback rather than passing a million arguments; or maybe a different approach altogether.

My comments about the "volatility of the interface" refers mainly to this callback, rather than how a user may enable logging. How a user may enable logging should be considered committed - though with that some ambiguity might arise as well; for example the environment variable _only_ affects how logging is handled _if_ the application did not install its own custom callback, etc. I don't think it's a good idea to change how users may enable, disable, or filter logging levels though.




[CCBC-450] Provide additional error codes for various failures Created: 14/Jun/14  Updated: 16/Jun/14  Resolved: 16/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: 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 only return NETWORK_ERROR or CONNECT_ERROR upon various types of network failures. At the user's option we should also be able to return more detailed codes reflecting what actually happened to the socket. This feature should be compatible with older versions and thus disable by default.

 Comments   
Comment by Mark Nunberg [ 16/Jun/14 ]
http://review.couchbase.org/38297
http://review.couchbase.org/38298




[CCBC-449] pillowfight isn't listed as a subcommand of 'cbc Created: 13/Jun/14  Updated: 13/Jun/14  Resolved: 13/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: 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


 Description   
When running cbc with no arguments, it shows a list of possible subcommands. However pillowfight isn't present in the list:

      $cbc
      Error: Unknown command "cbc"
      Usage: cbc command [options]
      command may be:
         help show this help or for given command
         cat output keys to stdout
         cp store files to the cluster
         create store files with options
         observe observe key state
         flush remove all keys from the cluster
         hash hash key(s) and print out useful info
         lock lock keys
         unlock unlock keys
         rm remove keys
         stats show stats
         verify verify content in cache with files
         version show version
         verbosity specify server verbosity level
         view execute couchbase view (aka map/reduce) request
         admin execute request to management REST API
         bucket-create create data bucket on the cluster
         bucket-delete delete data bucket
         bucket-flush flush data bucket
      Use 'cbc command --help' to show the options



 Comments   
Comment by Dave Rigby [ 13/Jun/14 ]
http://review.couchbase.org/#/c/38223/
Comment by Dave Rigby [ 13/Jun/14 ]
@Mark - assigning back to you to set the fixVersion - I assume it'll be 2.3.2 but wanted to double-check.




[CCBC-448] Explicitly search /usr/local for newer OS X Created: 12/Jun/14  Updated: 13/Jun/14

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

Type: Bug Priority: Minor
Reporter: Wei-Li Liu Assignee: Wei-Li Liu
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Mac OS X


 Description   
I clone libcouchbase repo and build.with autotool on my mac
The instruction is :

$ ./config/autorun.sh
$ ./configure
$ make
$ make check
$ make install

On the 2nd step (./configure) I see
====================================================
checking for libev3... no
checking for libev4... no
checking for libevent >= 1.4... no
checking for libevent2... no
checking for libuv... no
configure: error: Failed to locate usable event library. You must install either libev or libevent dev package or use --disable-plugins option
====================================================


However, I do have libevent installed
=====================================================
Wei-Lis-MacBook-Pro:libcouchbase wei-li$ brew install libevent
Warning: libevent-2.0.21 already installed
Wei-Lis-MacBook-Pro:/ wei-li$ sudo find . -name libevent
Password:
find: ./dev/fd/3: Not a directory
find: ./dev/fd/4: Not a directory
./Users/wei-li/repo/couchbase/libcouchbase/plugins/io/libevent
./usr/local/Cellar/libevent
./usr/local/Library/LinkedKegs/libevent
./usr/local/opt/libevent
====================================================
configure script wasn't able to find the package
 






 Comments   
Comment by Mark Nunberg [ 12/Jun/14 ]
Please ensure you have the development libraries for libevent installed as well. It seems you have this available from homebrew, however your homebrew installation is not inside the default linker/compiler search paths.

Find an 'event.h' :)
Comment by Dave Rigby [ 13/Jun/14 ]
@Wei-Li

To be more specific, brew installs things in /usr/local/ by default, and so you need to add them to your search path if building from source. Try:

    CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ./configure && make
Comment by Mark Nunberg [ 13/Jun/14 ]
or 'brew link libevent'. Can you find 'libevent.dylib'?
Comment by Dave Rigby [ 13/Jun/14 ]
@Mark: "brew link libevent" just puts things in /usr/local (at least on my box), which the lcb configure scripts don't look in by default (hence me specifying it).
Comment by Mark Nunberg [ 13/Jun/14 ]
mnunberg@mbp15 ~ $ cpp --verbose
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
 "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.8.0 -E -disable-free -disable-llvm-verifier -main-file-name - -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 224.1 -v -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/5.0 -I /usr/include -fdebug-compilation-dir /Users/mnunberg -ferror-limit 19 -fmessage-length 134 -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-10.8.0 -fobjc-dispatch-method=mixed -fobjc-default-synthesize-properties -fencode-extended-block-signature -fdiagnostics-show-option -fcolor-diagnostics -traditional-cpp -o - -x c -
clang -cc1 version 5.0 based upon LLVM 3.3svn default target x86_64-apple-darwin12.5.0
ignoring duplicate directory "/usr/include"
  as it is a non-system directory that duplicates a system directory
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/5.0/include
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
Comment by Mark Nunberg [ 13/Jun/14 ]
It would be odd if you had to add -I/usr/local/include -- in any event, see what homebrew does (brew install libcouchbase?)
Comment by Dave Rigby [ 13/Jun/14 ]
@Mark - /usr/local/include has been removed in 5.1:

$ cpp --verbose
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.2.0
Thread model: posix
 "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.9.0 -E -disable-free -disable-llvm-verifier -main-file-name - -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 236.3 -v -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/5.1 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -I /usr/include -fdebug-compilation-dir /Users/dave/Documents/Code -ferror-limit 19 -fmessage-length 233 -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-10.9.0 -fencode-extended-block-signature -fdiagnostics-show-option -fcolor-diagnostics -vectorize-slp -traditional-cpp -o - -x c -
clang -cc1 version 5.1 based upon LLVM 3.4svn default target x86_64-apple-darwin13.2.0
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/local/include"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/5.1/include
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks (framework directory)
End of search list.
Comment by Wei-Li Liu [ 13/Jun/14 ]
Adding the search path when build works for me

CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ./configure && make

I have to switch to root user to resolve some permission issue after that steps. Eventually it builds successfully .
I wasn't sure if libcouchbase configure scripts doesn't look in by default. Now It is confirmed I will resolve this

Comment by Mark Nunberg [ 13/Jun/14 ]
Libcouchbase doesn't explicitly look in /usr/local because on any sane system that path is _already_ part of the default compiler search path. You should keep this open and rename the title to something like "explicitly search /usr/local for newer OS X"
Comment by Wei-Li Liu [ 13/Jun/14 ]
Done




[CCBC-447] Include lcb version in log output Created: 11/Jun/14  Updated: 16/Jun/14  Resolved: 16/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: Improvement 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


 Description   
LCB_LOGLEVEL is very helpful for debugging issues, but it would be even more helpful if it printed the lcb version on startup, similar to the Java SDK.



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




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

Status: Resolved
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-445] Provide 'sync destructor' functionality Created: 05/Jun/14  Updated: 12/Jun/14  Resolved: 12/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-dp1
Security Level: Public

Type: New Feature 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   
in packet-ng, lcb_destroy() does not actually free I/O resources but decrements their reference counts. Some resources such as pending socket connects are "cancelled" asynchronously, with the actual 'free' event taking place on the next tick of the event loop rather than immediately.

The most common case is when the library has failed to connect or when there are pending config requests. While this is typically harmless (as the amount of memory "leaked" is fairly small) it is likely most annoying when debugging an application for memory leaks. This feature provides a means by which to offer "synchronous destroy" functionality. Unfortunately this cannot become the default for lcb_destroy() as async-based models also use lcb_destroy() and as such will end up with an infinite loop.

This feature will be implemented via lcb_cntl() and via an environment variable, thus code may compile against this feature and simply ignore an error at runtime if it cannot be set.




[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-443] Add DSN/URI/Connection string for creation options Created: 03/Jun/14  Updated: 10/Jun/14  Resolved: 10/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-dp1
Security Level: Public

Type: New Feature 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 will add a URI feature as mentioned in this document: https://docs.google.com/document/d/172ausWsYt3eYYOZ1lYHVS8ccbrrVJaGwHIRsf_O_Hyc/edit




[CCBC-442] Allow lcb_cntl_setstring() to pass string key-value pairs Created: 03/Jun/14  Updated: 03/Jun/14  Resolved: 03/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-dp1
Security Level: Public

Type: New Feature 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 feature will allow setting of common options via key-value string pairs rather than through "funny looking" hex codes

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




[CCBC-441] lcb_arithmetic does not set expiration in packet header Created: 03/Jun/14  Updated: 03/Jun/14  Resolved: 03/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-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


 Comments   
Comment by Brett Lawson [ 03/Jun/14 ]
https://gist.github.com/brett19/af735a0c16ce3f1fc813/revisions
Comment by Mark Nunberg [ 03/Jun/14 ]
http://review.couchbase.org/#/c/37785/




[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-439] Improvement needed on cbc help text Created: 03/Jun/14  Updated: 03/Jun/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.1
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   
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.




[CCBC-438] Properly handle datatype in response structure (strip/leave compression settings) Created: 02/Jun/14  Updated: 09/Jun/14  Resolved: 09/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-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





[CCBC-437] cbc: add datatype and ssl options Created: 02/Jun/14  Updated: 12/Jun/14  Resolved: 12/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-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


 Comments   
Comment by Mark Nunberg [ 12/Jun/14 ]
https://github.com/couchbase/libcouchbase/commit/aadec1086ff3b346bb0917567ad893203c973cd2




[CCBC-436] Create tests for existence of ctls Created: 02/Jun/14  Updated: 03/Jun/14  Resolved: 03/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-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


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




[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-434] pillowfight should output errors by default Created: 30/May/14  Updated: 14/Jun/14  Resolved: 14/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: Improvement Priority: Minor
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   
When running pillowfight, there is no indication of error when a node dies, etc.



 Comments   
Comment by Mark Nunberg [ 02/Jun/14 ]
As far as I can tell, cbc will output actual operation errors if and when they occur.
Generic cluster topology change events would be reflected in logging (which must be enabled in the environment) and not as programmatic output from pillowfight.
Comment by Perry Krug [ 02/Jun/14 ]
Then this is a valid bug that the errors from cbc are not being reported when running pillowfight. I ran it, "kill -9" memcached and got no output on the command prompt that I was running it on.
Comment by Mark Nunberg [ 02/Jun/14 ]
I don't see how this is a bug, you need to run with logging. pillowfight is a tool to test throughput between client and server, the client can't possibly catch and figure out whenever a node is down. Have you run with logging? Do you want logging to be enabled for pillowfight by default?
Comment by Perry Krug [ 02/Jun/14 ]
The client can catch and report when it gets a timeout or a connection reset can it not?

How do I enable logging for pillowfight via the command-line?
Comment by Mark Nunberg [ 02/Jun/14 ]
A node failing over doesn't necessarily mean the command will time out if the client can retry to send it when the node comes back up before the timeout expires. libcouchbase is operation-driven which means it can only know and programmatically report when an operation fails.

You can enable logging by LCB_LOGLEVEL in the environment, using a number between 1-5 as the value, with higher numbers being more verbose. I'd suggest =2
Comment by Perry Krug [ 02/Jun/14 ]
Mark, please read my previous notes...I was not talking about failover at all, rather a node actually _failing_.

Trying with that environment variable set does work well, thank you. I would think we want at least LCB_LOGLEVEL=1 to be set by default. You have to remember, not everyone running this command is an expert C programme ;-)
Comment by Matt Ingenthron [ 03/Jun/14 ]
+1 to some logging on pillowfight by default. It's new functionality in 2.3, so understandable that it's not there, but would be good to add.
Comment by Mark Nunberg [ 12/Jun/14 ]
http://review.couchbase.org/#/c/38211/




[CCBC-433] hostlist_randomize skips the first host in the list. Created: 30/May/14  Updated: 16/Jun/14  Resolved: 03/Jun/14

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

Type: Bug Priority: Critical
Reporter: Patrick Varley Assignee: Patrick Varley
Resolution: Fixed Votes: 0
Labels: connection, customer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
Relates to
relates to CCBC-440 Apply new shuffle algorithm to packet-ng Resolved

 Comments   
Comment by Mark Nunberg [ 02/Jun/14 ]
Pending +V from submitter.




[CCBC-432] The code example in Configuration Sources is wrong Created: 28/May/14  Updated: 09/Jun/14  Resolved: 09/Jun/14

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

Type: Task Priority: Minor
Reporter: Patrick Varley Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: cccp
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: http://docs.couchbase.com/couchbase-sdk-c-2.3/#configuration-sources


 Description   
The example code for disabling HTTP is wrong and will not compile:

lcb_config_transport transports[] = {
    LCB_CONFIG_TRANSPORT_CCCP,
    LCB_CONFIG_TRANSPORT_LIST_END
};

cb_config_transport is wrong it should be cb_config_transport_t:

lcb_config_transport_t transports[] = {
    LCB_CONFIG_TRANSPORT_CCCP,
    LCB_CONFIG_TRANSPORT_LIST_END
};

 Comments   
Comment by Mark Nunberg [ 09/Jun/14 ]
https://github.com/couchbaselabs/docs-ng/pull/131




[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-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-429] Select plugin will needlessly busy-poll when timeouts are active. Created: 24/May/14  Updated: 25/May/14  Resolved: 25/May/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.0, 2.3.1
Fix Version/s: 2.4.0-dp1
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 [ 24/May/14 ]
http://review.couchbase.org/37564




[CCBC-428] Use terse (/pools/default/bs/$bucket) rather than compat (/pools/default/bucketsStreaming/default) for streaming config Created: 24/May/14  Updated: 26/May/14  Resolved: 26/May/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: 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


 Description   
Use the terse URI which is far more efficient on the cluster. This would allow to have the benefits of the library despite using an older cluster.

This should be implemented in a way so that older clusters will not suffer the need to make a new TCP connection if the first request (to bs) fails.

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




[CCBC-427] Use common code for decoding and parsing HTTP responses. Created: 24/May/14  Updated: 25/May/14  Resolved: 25/May/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.2.0, 2.3.1
Fix Version/s: 2.4.0-dp1
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


 Description   
Currently we have the streaming HTTP parser which we use for bucket configuration and another HTTP parser which we use for parsing the lcb_make_http_request() functionality. We should merge these into a single parser.




add support for SSL to libcouchbase in support of Couchbase Server 3.0 (CCBC-344)

[CCBC-426] Make data connections use SSL encryption if enabled Created: 21/May/14  Updated: 25/May/14  Resolved: 25/May/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: 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 [ 24/May/14 ]
http://review.couchbase.org/37339




add support for SSL to libcouchbase in support of Couchbase Server 3.0 (CCBC-344)

[CCBC-425] implement SSL I/O Core with OpenSSL for both event models Created: 21/May/14  Updated: 25/May/14  Resolved: 25/May/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: 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





[CCBC-424] libcouchbase not updated in brew recipes ... Created: 21/May/14  Updated: 22/May/14  Resolved: 22/May/14

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

Type: Task Priority: Trivial
Reporter: adonoho Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: libcouchbase
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: OS X v10.9.2


 Description   
libcouchbase v2.3.1 is current. As of this morning, 20140521, brew is installing v2.3.0.


awd$ brew upgrade libcouchbase
==> Upgrading 1 outdated package, with result:
libcouchbase 2.3.0
==> Upgrading libcouchbase
==> Downloading http://packages.couchbase.com/clients/c/libcouchbase-2.3.0.tar.gz
######################################################################## 100.0%
==> ./configure --prefix=/usr/local/Cellar/libcouchbase/2.3.0 --disable-examples --disable-tests --disable-couchbasemock
==> make install
🍺 /usr/local/Cellar/libcouchbase/2.3.0: 118 files, 1.6M, built in 16 seconds


Anon,
Andrew


 Comments   
Comment by Dave Rigby [ 21/May/14 ]
Have you tried updating brew?

    brew update; brew upgrade libcouchbase

Comment by adonoho [ 21/May/14 ]
Dave,

That solves the problem.

Please consider updating the documentation to reflect the fact that one must update brew to get the latest recipes. (To those of us who have only installed brew to support libcouchbase, these kinds of handholding steps matter. I only ever use brew when a new libcouchbase update occurs.)

Thank you.

Anon,
Andrew
Comment by Matt Ingenthron [ 21/May/14 ]
Mark: when you have a moment, please add such a line to the docs.
Comment by Mark Nunberg [ 21/May/14 ]
https://github.com/couchbaselabs/docs-ng/pull/127




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

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.1
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-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-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




[CCBC-420] vbucket: Don't map item to server with no vbuckets Created: 20/May/14  Updated: 20/May/14  Resolved: 20/May/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.0.7, 2.2.0, 2.3.1
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

Issue Links:
Dependency
blocks CCBC-423 Don't request configuration from node... Open
Relates to

 Description   
in found_incorrect_master, we sometimes end up mapping keys to servers based on their presence inside the serverList array. However we should really be ignoring this node if it doesn't have any vBuckets mapped to it.

See https://www.couchbase.com/issues/browse/MB-10543?focusedCommentId=82995&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-82995

 Comments   
Comment by Mark Nunberg [ 20/May/14 ]
Matt, Alk -- I've placed you both here as watchers for this ticket.
Comment by Mark Nunberg [ 20/May/14 ]
http://review.couchbase.com/#/c/37322/
Comment by Mark Nunberg [ 20/May/14 ]
packet-ng does not use found_incorrect_master - so this is not _entirely_ applicable to it.




[CCBC-419] Crash in libcouchbase 2.3.0 Created: 20/May/14  Updated: 16/Jun/14  Resolved: 16/Jun/14

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

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


 Description   
I have 2-node claster and if all nodes are in pending state and I try to set some data to claster
my application crashes with such stack:
(gdb) bt
#0 0x0000003435c0e9dd in raise () from /lib64/libpthread.so.0
#1 0x00002b887dc2c5b6 in skgesigOSCrash () from /u01/app/oracle/product/11.2.0/client/lib/libclntsh.so.11.1
#2 0x00002b887deca609 in kpeDbgSignalHandler () from /u01/app/oracle/product/11.2.0/client/lib/libclntsh.so.11.1
#3 0x00002b887dc2c7c6 in skgesig_sigactionHandler () from /u01/app/oracle/product/11.2.0/client/lib/libclntsh.so.11.1
#4 <signal handler called>
#5 0x0000003435030265 in raise () from /lib64/libc.so.6
#6 0x0000003435031d10 in abort () from /lib64/libc.so.6
#7 0x00002b88814980a5 in ringbuffer_consumed (buffer=0x7073, nb=30646) at src/ringbuffer.c:263
#8 0x00002b888149a00c in lcb_purge_single_server (server=0x1daa9168, error=LCB_ETIMEDOUT) at src/server.c:330
#9 0x00002b888149d927 in lcb_server_timeout_handler (sock=<optimized out>, which=<optimized out>, arg=0x6) at src/timeout.c:38
#10 0x00002b8884e49348 in event_base_loop () from /import/home/hasg_test/IBES_INSTANCE/Linux/5.0/i686/HAS_SERVER_051.10__0/64/bin/lib/libevent-2.0.so.5
#11 0x00002b888149e893 in lcb_wait (instance=0x1db96800) at src/wait.c:60
#12 0x00000000004312d0 in Couchbase::set_values (this=0x1d731568, elements=..., timeout=100) at couchbase_loader_source/couchbase.cpp:268
#13 0x000000000043e9e1 in couchbase_loader::writer_thread::execute (this=0x1d7314e0) at couchbase_loader_source/writer_thread.cpp:49
#14 0x00002b88836a48d3 in threads::thread_proc(void*) () from /import/home/hasg_test/IBES_INSTANCE/Linux/5.0/i686/HAS_SERVER_051.10__0/64/bin/libhas_common.so
#15 0x0000003435c0673d in start_thread () from /lib64/libpthread.so.0
#16 0x00000034350d40cd in clone () from /lib64/libc.so.6
#17 0x0000000000000000 in ?? ()


 Comments   
Comment by Haster [ 20/May/14 ]
Sorry, I;ve given this error on 2.0.3 version. But I thinks that it will reproduce and on 2.3.0 too.
Now I can't set all nodes on my cluster to pending state, so I can't check it
Comment by Patrick Varley [ 11/Jun/14 ]
Haster have you reproduce this on 2.3.1? I know we have fixed a number of bugs around ringbuffer_consumed since 2.0.3
Comment by Haster [ 12/Jun/14 ]
Patrick, I can't reproduce this bug in new version. So, I think you can drop it.




[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-417] TTP/TTR calculation in observe response handling is broken. Created: 15/May/14  Updated: 15/May/14  Resolved: 15/May/14

Status: Closed
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: Venu Uppalapati Assignee: Mark Nunberg
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
TTP/TTR calculation in observe response handling is broken
https://github.com/couchbase/libcouchbase/blob/master/src/handler.c#L533-536

On server side only the persist_time is sent as part of the CAS.
https://github.com/couchbase/ep-engine/blob/master/src/ep_engine.cc#L4334-4341

 Comments   
Comment by Venu Uppalapati [ 15/May/14 ]
This is a known limitation on server side. Server side does not currently have a implementation for time taken for replication.




[CCBC-416] Map in-situ AUTH_ERROR to NETWORK_ERROR or retry Created: 14/May/14  Updated: 03/Jun/14  Resolved: 03/Jun/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.0, 2.3.1
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:
Relates to

 Description   
Authentication errors may be received during a rebalance with CCCP (See CCBC-357). We should be able to distinguish these errors from ones received as an actual authentication failure. This is handled in packet-ng, but not in 2.3.x

The point of the issue is to help developers not worry about receiving this error during normal application flow - since there is no actionable path for such an error.

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




[CCBC-415] IPv6 Functionality Created: 14/May/14  Updated: 02/Jun/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: Haster Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
If I put some ipv6 address (for example "::1") function lcb_host_parse(...) returns LCB_INVALID_HOST_FORMAT error.
It is needed to add ipv6 support


 Comments   
Comment by Mark Nunberg [ 14/May/14 ]
I'm not sure how well ipv6 works up the stack tbh. I'm curious though - did this work in lcb 2.2?
Comment by Haster [ 14/May/14 ]
Mark, I don't know =)
But I suggest that it don't work in 2.2 version,
But in libcouchbase there is some things, related to ipv6, such as function lcb_behavior_set_ipv6 in cntl.c

Maybe it's not a bug but future request or task =)




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




[CCBC-412] config cache: Documentation suggests using deprecated function lcb_create_compat() Created: 13/May/14  Updated: 22/May/14  Resolved: 22/May/14

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

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


 Description   
As of lcb 2.3.1, the `lcb_create_compat` function is deprecated - see http://docs.couchbase.com/couchbase-sdk-c-2.3/#release-notes-for-couchbase-client-library-c-231-ga-09-may-2014. However the documentation at http://docs.couchbase.com/couchbase-sdk-c-2.3/#file-based-configuration-cache still suggests using the deprecated method.

`lcb_cntl` with the operation `LCB_CNTL_CONFIGCACHE` is now the recommended method of enabling config cache. The documentation should be updated to reflect this.




 Comments   
Comment by Mark Nunberg [ 19/May/14 ]
https://github.com/couchbaselabs/docs-ng/pull/127




[CCBC-411] 2.3.1 Release notes are missing. Created: 12/May/14  Updated: 12/May/14  Resolved: 12/May/14

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

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


 Description   
http://docs.couchbase.com/couchbase-sdk-c-2.3/#release-notes

 Comments   
Comment by Mark Nunberg [ 12/May/14 ]
https://github.com/couchbaselabs/docs-ng/pull/122
Comment by Amy Kurtzman [ 12/May/14 ]
The release notes are available on the docs site now.

Please note that the announcements of the SDK releases and the publication of the release notes on the docs website is not always coordinated and will often lag behind the announcement. The announcement does mention that possibility and includes a link to the release notes on GitHub. In the future, please consider checking with me about the documentation release status before filing an issue about it not being on the docs website.




[CCBC-410] Typo in CCCP Struct Code Example in 2.3 C SDK Documentation Will Result in Compilation Error Created: 09/May/14  Updated: 12/May/14  Resolved: 12/May/14

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

Type: Bug Priority: Minor
Reporter: Morrie Schreibman Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: usability
Remaining Estimate: 0.5h
Time Spent: Not Specified
Original Estimate: 0.5h


 Description   
The code error which I found may be seen at

http://docs.couchbase.com/couchbase-sdk-c-2.3/index.html#integration-with-libcouchbase

The code example given:
.
  lcb_t instance;
  struct lcb_create_st options;
  lcb_config_transport_t enabled_transports = {
  LCB_CONFIG_TRANSPORT_CCCP,
  LCB_CONFIG_TRANSPORT_LIST_END
  };

  memset(&options, 0, sizeof(options));
  options.version = 2;
  options.v.v2.mchosts = "example.com:11210";
  options.v.v2.transports = enabled_transports;
...
will not compile (at least it will not compile under gcc). The problem is on the 3rd line. The correct code is
.
  lcb_t instance;
  struct lcb_create_st options;
  lcb_config_transport_t enabled_transports [ ] = {
  LCB_CONFIG_TRANSPORT_CCCP,
  LCB_CONFIG_TRANSPORT_LIST_END
  };

  memset(&options, 0, sizeof(options));
  options.version = 2;
  options.v.v2.mchosts = "example.com:11210";
  options.v.v2.transports = enabled_transports;
.

-while this may seem trivial, my experience is that customers frequently paste in source code examples without studying them in detail, and then get themselves in trouble later. So this is a doc bug which should be fixed.


 Comments   
Comment by Mark Nunberg [ 12/May/14 ]
https://github.com/couchbaselabs/docs-ng/pull/122




[CCBC-409] Lacking a way to definitively determine if a bucket exists or not Created: 08/May/14  Updated: 26/Jun/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: 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

Issue Links:
Relates to
relates to CCBC-357 Authentication Errors during rebalance Open

 Description   
Prior to memcached bootstrap, we'd rely on an HTTP 404 to determine that the bucket does not exist; however no such semantic exists for memcached, where memcached will just tell us authentication failed.

 Comments   
Comment by Mark Nunberg [ 08/May/14 ]
Perhaps consider moving this to MB?




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-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-406] instancepool example does not run Created: 04/May/14  Updated: 01/Jul/14

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

Type: Bug Priority: Trivial
Reporter: Shiv Dayal Assignee: Mark Nunberg
Resolution: Unresolved 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-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-404] Segfault in lcb2.3 in connmgr invoke_request() Created: 02/May/14  Updated: 07/May/14  Resolved: 07/May/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: Task Priority: Critical
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: CentOS 6u5

Issue Links:
Dependency

 Description   
Customer running lcb2.3 (on top of Python SDK) and reported:

<quote>
TimeoutError: <Key=u'DEV_509075a7b22c93664cc9d853ca7f7a722100c3e1', RC=0x17[Client-Side timeout exceeded for operation. Inspect network conditions or increase the timeout], Operational Error, Results=1, C Source=(src/multiresult.c,148)>

And then it crashed with core dumps.
</quote>

I dug into this a little bit, and I see essentially the same backtrace on both core files:

(gdb) bt 5
#0 invoke_request (req=0x7ffaa84792c0) at src/connmgr.c:126
#1 0x00007ffb2993de0f in connection_available (he=0x7ffab402c700) at src/connmgr.c:163
#2 0x00007ffb2994cb5b in timer_callback (sock=<value optimized out>, which=<value optimized out>, arg=0x7ffab4008d40) at src/timer.c:45
#3 0x00007ffb26b81b44 in ?? ()
#4 0x00007ffb26d940e0 in ?? ()

The `conn` field looks garbage:

(gdb) p *req
$9 = {llnode = {next = 0x0, prev = 0x0}, callback = 0x7ffb29949bb0 <socket_connected>, key = "inbox-31:11210", '\000' <repeats 1035 times>, he = 0x7ffab402c700, timer = 0x7ffaa8c13530, state = 1, conn = 0x18, err = LCB_SUCCESS, data = 0x7ffaa872fd80}

Digging further, this came from the he->idle list with is supposedly empty, but has size ==1 :

(gdb) p he->ll_idle
$11 = {next = 0x7ffab402c700, prev = 0x7ffab402c700, size = 1}




 Comments   
Comment by Dave Rigby [ 07/May/14 ]
http://review.couchbase.org/#/c/36601/
Comment by Mark Nunberg [ 07/May/14 ]
Reopen if this does not resolve the issue.




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-402] Provide API for exposing buffer/pool settings (rdb, netbuf) Created: 01/May/14  Updated: 14/Jul/14

Status: Open
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: Task Priority: Critical
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-401] Remove 2.3.0 'v2' creation structure ABI fields, replace with lcb_cntl() Created: 30/Apr/14  Updated: 30/Apr/14  Resolved: 30/Apr/14

Status: Closed
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: Critical
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
See CCBC-392 for a discussion of why this is 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-399] Promote logging api to 'uncommitted' Created: 29/Apr/14  Updated: 03/Jun/14  Resolved: 03/Jun/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: docs
Affects Version/s: 2.4.0-dp1
Fix Version/s: 2.4.0-dp1
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   
Logging API should not be volatile. If our current API is indeed volatile then let us make one which isn't.

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




[CCBC-398] Ensure all API calls have interface attributes. Created: 29/Apr/14  Updated: 01/May/14  Resolved: 01/May/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: docs
Affects Version/s: 2.4.0-dp1
Fix Version/s: 2.4.0-dp1
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 be clear to document any functions to have the proper 'stability attributes'; this would require about an 30 mins work to simply skim over the list.

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




[CCBC-397] Create a back-compat file for lcb_cntl operations Created: 29/Apr/14  Updated: 01/May/14

Status: Open
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: Mark Nunberg Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Provide a file which may be used by any C client application.

This may be dropped into other clients as 'lcb_cntl_compat.h' and would conditionally define any cntls not already defined. We could make this auto generated via a script. This would avoid other clients having to #ifdef this stuff themselves.




[CCBC-396] Make it simpler to execute tests against a real cluster Created: 27/Apr/14  Updated: 28/Apr/14  Resolved: 28/Apr/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: 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   
Currently we must run tests using special environment variables. Considering that 'check-all' is now our wrapper, we should now add 'real cluster' params to the check-all script.




[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




[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-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/




[CCBC-392] ABI compatibility broken on 2.3 when using config cache. Created: 24/Apr/14  Updated: 01/May/14  Resolved: 01/May/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: Task Priority: Critical
Reporter: Patrick Varley Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: compatible
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
Relates to
relates to CCBC-395 Add configuration cache API via lcb_c... Resolved

 Description   
"Compat" structure which is used when creating a config cache are not ABI compatible between 2.3 and older versions.

Details:
"lcb_compat_st" structure embeds an "lcb_create_st" structure in its first field. second field. The lcb_create_st" structure has increased in size in 2.3, it now includes a transport selection and a memcached host array.

Work arounds:

For C/C++ code using LCB a recompile will be required or if compatibility is required across 2.2 and 2.3 do not use the configcache.

From the SDKs (ruby, python and php) that sits on top of LCB if you wish to use the config cach the SDK will need to be reinstalled after LCB 2.3.0 has been installed.

 Comments   
Comment by Mark Nunberg [ 25/Apr/14 ]
This is probably the best workaround for this. The idea would be that:

When compiling, first try to use lcb_create_st and then lcb_cntl() with the CONFIGCACHE command. If that fails (And it will fail on runtime for older versions, but not fail to compile or load) the application can fall back to the older built-in 'compat' structure.
Comment by Mark Nunberg [ 25/Apr/14 ]
Won't fix, but see CCBC-395 for a workaround.
Comment by Matt Ingenthron [ 30/Apr/14 ]
From a high level, we should fix backwards compatibility, then later redesign that interface. We can implement backwards compatibility by checking the version field of the create_st of compat_st to determine the 'true length' of the structure.

Can we do this for the next maintenance release?
Comment by Mark Nunberg [ 30/Apr/14 ]
That still won't work because even if the version is set to a lower number it doesn't mean the structure is actually that size. The version only tells us how much of the structure the application is using, but not the actual size of the structure in memory. The only way to implement backwards compat is to remove the extra field added in 2.3.0 and expose that via lcb_cntl() as well. This of course breaks compat with 2.3.0, but with a lower risk (less deployments compiled with 2.3 than compiled with 2.2.0).

I don't think breaking 2.3.0 would be as harmful other than breaking any things up the chain which already employ such functionality; I don't know of any SDK that's actually used the 'v2' fields inside the host and we already have the facilties to add specific nodes to specific transports. Please open another bug if you think that is the correct course of action and close this; there is no way to provide back compat without breaking 2.3.0 ABI
Comment by Matt Ingenthron [ 30/Apr/14 ]
I believe the bug is breaking ABI from 2.2.0 to 2.3.0 and we need to address it in 2.3.1 even if that (obviously) breaks 2.3.0. Right now, there aren't that many 2.3.0 deployments and as they go up, we'll see this issue crop up more and more.

I'd like to find a way (even if not the most clean) to handle backwards compatibility. Can you think of a creative solution, or do you think the only possible way is to add the lcb_cntl() piece and then need to make changes to all of the clients to use it?

Perhaps in a 2.3.1, we just need an additional set of files which do the new version and we always read the old as old and write new? Any other creative approaches?
Comment by Mark Nunberg [ 30/Apr/14 ]
I think removing the fields in 2.3.0 should be good enough for all cases. This will eliminate the need for clients to rewrite their code to be compatible fowards and backwards (however, it is still desirable that they do so, as the lcb_cntl() api is far better suited).

lcb_cntl would be used going forward:

* To set various transport options
* To set the configuration cache

Setting the configuration cache would still be available via lcb_create_compat() etc, except that such a usage would be deprecated and hopefully within some time, SDKs will update their code (like Python has) to work well with both models.
Comment by Mark Nunberg [ 30/Apr/14 ]
Created as CCBC-401
Comment by Mark Nunberg [ 30/Apr/14 ]
After a long discussion with brett, we found a reasonable workaround that didn't involve removing the field. Closing CCBC-401

http://review.couchbase.org/#/c/36559
Comment by Patrick Varley [ 01/May/14 ]
Can we fix http://upstream-tracker.org/versions/libcouchbase.html to check for all public ABI? (Maybe that should be a subtask of this ticket)
Comment by Mark Nunberg [ 01/May/14 ]
I'm not sure how that thing works or what we can do with it. We don't maintain that site, it probably just does some simple scripts and compares structure sizes/members; with this fix it'll erroneously report incorrect results too because we "Broke" the compat_st structure (except that this code handles the older compat_st structure as well).




[CCBC-391] Preserve server structures across topology changes Created: 24/Apr/14  Updated: 14/May/14  Resolved: 28/Apr/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.0.7, 2.2.0, 2.3.0
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:
Relates to

 Description   
Currently when a topology change is detected in the cluster, the client behavior is to destroy the entire server list and recreate it anew. This is inefficient both on the network end as well as from a logic standpoint.

The proposed behavior should be that the server structures be relocated to their proper indices. Pending commands which may be mapped to the wrong server will end up receiving a not-my-vbucket response which the client shall silently relocate once received as a response. The client-side packet structure will be marked with a flag indicating that we expect a not-my-vbucket response on this command and that the client need not be alarmed (or update its configuration) when we actually do get a not-my-vbucket.

Only servers which are no longer part of the cluster will have their command queues purged and relocated to other servers.

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




[CCBC-390] Implement server datatype handling. Created: 24/Apr/14  Updated: 28/May/14  Resolved: 28/May/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: Task Priority: Critical
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:
Dependency
blocks PCBC-273 Implement datatype/wire-compression Resolved

 Description   
Implement datatype support as implemented by the server.

One solution suggested was to integrate compression handling directly within libcouchbase, and simply exposing the remaining bits of the 'datatype' to the higher levels for any further processing as an numeric rather than bitfield value.




[CCBC-389] Timeout handler is triggered even when no commands are pending (or timed out) Created: 23/Apr/14  Updated: 25/Apr/14  Resolved: 25/Apr/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: 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   
The timeout handler is triggered even when no commands are pending. Normally the timeout handler is reset when lcb_wait() is invoked, however for SDKs which do not use lcb_wait() [ i.e. node.js ] this will trigger the handler.

Operations are not immediately failed since the failure of the operation is dependent on the actual current time vs the time of the first packet in the queue, however lcb_bootstrap_errcount_incr() is called, eventually triggering a config refresh after a given amount of time.

 Comments   
Comment by Mark Nunberg [ 23/Apr/14 ]
http://review.couchbase.org/#/c/36242/




[CCBC-388] Release Notes are missing defects. Created: 23/Apr/14  Updated: 23/Apr/14  Resolved: 23/Apr/14

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

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


 Description   
I believe these 3 defect have also been fixed in 2.3.0 can you please update the release notes

http://www.couchbase.com/issues/browse/CCBC-321
http://www.couchbase.com/issues/browse/CCBC-320
http://www.couchbase.com/issues/browse/CCBC-281

Might be good to run your eye down this list incase any other bugs were missed of the release notes.

http://www.couchbase.com/issues/issues/?jql=project%20%3D%20CCBC%20AND%20fixVersion%20%3D%20%222.3.0%22

Thanks,
Patrick

 Comments   
Comment by Patrick Varley [ 23/Apr/14 ]
I just came across this:

http://www.couchbase.com/issues/secure/ReleaseNote.jspa?projectId=10070&version=11406
Comment by Mark Nunberg [ 23/Apr/14 ]
https://github.com/couchbaselabs/docs-ng/pull/114




[CCBC-387] Publish docs for C SDK May 2014 release Created: 22/Apr/14  Updated: 16/May/14  Resolved: 16/May/14

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

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





[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-385] It is needed to handle CMD_GET_REPLICA in failout_single_request function Created: 22/Apr/14  Updated: 22/Apr/14  Resolved: 22/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: 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 tried to get data from replica. but some error was happend and because CMD_GET_REPLICA isn't handled in
failout_single_request function the lcb_assert("unexpected opcode while purging the server" && 0); was called
and my application was terminated.

I think it is needed to add CMD_GET_REPLICA handling like this:
static void failout_single_request(lcb_server_t *server,
                                   protocol_binary_request_header *req,
                                   struct lcb_command_data_st *ct,
                                   lcb_error_t error,
                                   const void *keyptr,
                                   lcb_size_t nkey,
                                   const void *packet)
...
    switch (req->request.opcode) {
    case PROTOCOL_BINARY_CMD_NOOP:
        break;
    case CMD_GET_LOCKED:
    case PROTOCOL_BINARY_CMD_GAT:
    case PROTOCOL_BINARY_CMD_GATQ:
    case PROTOCOL_BINARY_CMD_GET:
    case PROTOCOL_BINARY_CMD_GETQ:
    case CMD_GET_REPLICA: <- add this line!!!!
...


 Comments   
Comment by Mark Nunberg [ 22/Apr/14 ]
http://review.couchbase.org/#/c/36139/




[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-383] Provide async API to determine bootstrap success or failure Created: 21/Apr/14  Updated: 29/Apr/14  Resolved: 29/Apr/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.0.0, 2.3.0
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


 Description   
Currently no API exists to determine bootstrap success or failure. We may either extend the configuration callback for this purpose, or provide a new API upon which to provide notification.

 Comments   
Comment by Matt Ingenthron [ 21/Apr/14 ]
Should it perhaps be callbacks on state changes? Just a thought-- you probably have a good idea of what you want here.
Comment by Mark Nunberg [ 21/Apr/14 ]
We already have callbacks for state changes. However if the bootstrap fails the library has no way to know about this (there are several "heuristics" to apply, but no definitive API saying "I couldn't bootstrap").
Comment by Mark Nunberg [ 24/Apr/14 ]
http://review.couchbase.org/#/c/36229/




[CCBC-382] Retry throttle queue Created: 21/Apr/14  Updated: 23/Apr/14  Resolved: 23/Apr/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.0.0, 2.3.0
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


 Description   
This feature allows retries to be performed in a throttled fashion rather than immediately routing the failed item to a new node. This decreases network load and makes the retry handling nicer from a code level as well.




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

[CCBC-381] Deprecate all the simple lcb_set_FOO/lcb_get_FOO in favor of lcb_cntl Created: 21/Apr/14  Updated: 29/Apr/14  Resolved: 29/Apr/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: 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   
These functions cause a lot of line noise.




[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-379] lcb_cntl API to change LCB_DEFAULT_NODECONFIG_TIMEOUT Created: 21/Apr/14  Updated: 22/Apr/14  Resolved: 22/Apr/14

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

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


 Comments   
Comment by Mark Nunberg [ 21/Apr/14 ]
https://github.com/couchbase/libcouchbase/blob/master/include/libcouchbase/cntl.h#L380-395
Comment by Sergey Avseyev [ 21/Apr/14 ]
Thank you
Comment by Mark Nunberg [ 22/Apr/14 ]
Not a duplicate per-se, but this already exists and is implemented.




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

[CCBC-378] lcb_socket_t is DWORD on Win32, not int Created: 20/Apr/14  Updated: 28/Apr/14  Resolved: 28/Apr/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-dp1
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





[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-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-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-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-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-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-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-370] lcb_get_host/lcb_get_port may not return host:port for same host Created: 17/Apr/14  Updated: 22/Apr/14  Resolved: 22/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: 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 [ 22/Apr/14 ]
http://review.couchbase.org/#/c/35980/




[CCBC-369] lcb_create manpage does not mention v2 layout of struct lcb_create_st Created: 17/Apr/14  Updated: 12/May/14  Resolved: 12/May/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: docs
Affects Version/s: 2.4.0-dp1
Fix Version/s: 2.3.1
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

Issue Links:
Dependency
depends on CCBC-375 Migrate to Doxygen Resolved




[CCBC-368] Incorrect error raised when using node_list: property Created: 11/Apr/14  Updated: 21/Apr/14  Resolved: 21/Apr/14

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

Type: Bug Priority: Major
Reporter: Anonymous 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 scalabl3 [ 11/Apr/14 ]
I tried it by connecting to a 2-node cluster and it was a script that creates a bucket if it doesn't exist, I had a rescue statement for BucketNotFound but not Timeout....
Comment by Sergey Avseyev [ 17/Apr/14 ]
$ cbc cat -b bucket_does_not_exist -h "localhos:8091;localhost:8091" foo
ERROR: Client-Side timeout exceeded for operation. Inspect network conditions or increase the timeout
"No more bootstrap providers remain"

$ cbc version
cbc built from: libcouchbase 2.3.0 (rev. a62ff57ff12ad46d619193a501b1aca337ad851a)
    using libcouchbase: 2.3.0 (libevent)
    using libyajl: 2.0.4
Comment by Mark Nunberg [ 17/Apr/14 ]
Note even with a fix, you'll still get an auth error from CCCP if a bucket is not found (assuming _only_ CCCP is enabled)
Comment by Sergey Avseyev [ 17/Apr/14 ]
http://review.couchbase.org/35979




[CCBC-367] Couchbase::Error::Invalid: failed to schedule document request (key="/pools/default/buckets/default/ddocs", error=0x07) after upgrade to 2.3 Created: 16/Apr/14  Updated: 22/Apr/14  Resolved: 22/Apr/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: 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 [ 16/Apr/14 ]
This works similarly the same inside libcouchbase:

from couchbase.admin import Admin
Admin("Administrator", "123456").http_request("/pools/default/buckets/default/ddocs")


Sergey, are using the 'raw' request? Maybe that's the issue.
Comment by Sergey Avseyev [ 17/Apr/14 ]
This is libcouchbase bug.

https://github.com/couchbase/libcouchbase/blob/master/src/http.c#L475 lcb_confmon_get_rest_host(instance->confmon); returns NULL as host, therefore it will get invalid base ":" later in https://github.com/couchbase/libcouchbase/blob/master/src/http.c#L481
Comment by Sergey Avseyev [ 17/Apr/14 ]
and ruby uses management request to get list of design documents
Comment by Sergey Avseyev [ 22/Apr/14 ]
http://review.couchbase.org/35981




[CCBC-366] download links in tutorial are redirecting to page with 404 status Created: 07/Apr/14  Updated: 16/Apr/14  Resolved: 16/Apr/14

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

Type: Bug Priority: Major
Reporter: Iryna Mironava Assignee: Amy Kurtzman
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: http://docs.couchbase.com/couchbase-sdk-c-1.0/


 Description   
http://docs.couchbase.com/couchbase-sdk-c-1.0/
Link from section Downloading the Couchbase Client Library is redirecting to http://files.couchbase.com/developer-previews/clients/couchbase-server-2.0.0-compatible/c/ with 404 error

 Comments   
Comment by Wayne Siu [ 16/Apr/14 ]
Amy,
Can you please check if the URL is correct? http://files.couchbase.com/developer-previews/clients/couchbase-server-2.0.0-compatible/c/
Comment by Amy Kurtzman [ 16/Apr/14 ]
This document is for the 1.0 version of the software, which is very old. Unless you have a specific reason to use such an old version, please refer to the documentation for the current release at http://docs.couchbase.com/couchbase-sdk-c-2.3/.

The current download page for the C library is at http://www.couchbase.com/communities/c-client-library.
Comment by Amy Kurtzman [ 16/Apr/14 ]
Updated link in the version 1.0 documentation.




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

[CCBC-365] Restore syncmode functionality (if needed) Created: 15/Apr/14  Updated: 12/Jun/14  Resolved: 12/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-dp1
Security Level: Public

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


 Comments   
Comment by Matt Ingenthron [ 16/Apr/14 ]
Curious, what does this one mean?
Comment by Mark Nunberg [ 16/Apr/14 ]
In the process of converting the operations to use an entirely different buffer and object system, much of the code has been isolated so far from the "Core" with the aim of creating isolated and well defined modules within the library itself.

The "Syncmode" was introduced in 1.x and its entire purpose is to implicitly call lcb_wait() after each operation. As such it provided a fairly intrusive and cumbersome internal API to be had.

It is optional behavior and the only thing that relies on it currently is the PHP extension - though it would be about 10 minutes work to adapt the PHP extension to call lcb_wait explicitly. We've removed/disabled this either temporarily or indefinitely (the bug is basically here to provide a reminder to restore it if needed) depending on how compatible packet-ng will end up being.
Comment by Matt Ingenthron [ 16/Apr/14 ]
Thanks for the description. It's only broken in .future I'll assume since that's what the bug says.
Comment by Mark Nunberg [ 11/Jun/14 ]
http://review.couchbase.org/#/c/38161/

Since we're trying to make this a 2.4 and not a 3.0, syncmode functionality goes back in.




[CCBC-364] cbc-pillowfight slow during topology changes Created: 15/Apr/14  Updated: 25/Apr/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: 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:
Gantt: start-finish
is triggered by CCBC-332 libcouchbase does not compare revids ... Resolved

 Description   
When using CCCP, pillowfight exhibits a performance drop during a topology change. This may be related to not comparing the rev of various configurations received.



 Comments   
Comment by Mark Nunberg [ 15/Apr/14 ]
This _may_ be related to CCBC-332 - but I'm not sure at the moment.
Comment by Mark Nunberg [ 15/Apr/14 ]
Workaround is to use -C HTTP
Comment by Mark Nunberg [ 25/Apr/14 ]
I've tested this again with the newer patchsets on gerrit. I can confirm this is indeed triggered by CCBC-332.




[CCBC-363] Documentation for homebrew install points to unmaintained repository Created: 15/Apr/14  Updated: 22/Apr/14  Resolved: 15/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://docs.couchbase.com/couchbase-sdk-c-2.3/index.html#installing-using-packages-on-mac-os-x

 Comments   
Comment by Mark Nunberg [ 15/Apr/14 ]
Fixed:

http://docs.couchbase.com/couchbase-sdk-c-2.3/#installing-using-packages-on-mac-os-x




[CCBC-362] OS X Homebrew script for C-SDK points at a downlevel version ... Created: 13/Apr/14  Updated: 16/Apr/14  Resolved: 16/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: adonoho Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: install
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: OS X v10.9.2


 Description   
Gentlefolk,

The Homebrew script for the C SDK on OS X still points at libcouchbase-2.2.0. As of this morning:

astraeus:~ awd$ brew install https://github.com/couchbase/homebrew/raw/stable/Library/Formula/libcouchbase.rb
######################################################################## 100.0%
Warning: libcouchbase-2.2.0 already installed
astraeus:~ awd$ brew upgrade https://github.com/couchbase/homebrew/raw/stable/Library/Formula/libcouchbase.rb
######################################################################## 100.0%
Error: libcouchbase-2.2.0 already installed

Please upgrade the script as part of your release process.

Anon,
Andrew


 Comments   
Comment by Mark Nunberg [ 13/Apr/14 ]
We've submitted a pull request to the main homebrew repo. Assigning to Sergey
Comment by Sergey Avseyev [ 13/Apr/14 ]
brew update?

it should be there https://github.com/Homebrew/homebrew/pull/28287
Comment by Matt Ingenthron [ 16/Apr/14 ]
It looks like it's up to date now:

ingenthr-mbp:~ ingenthr$ brew install libcouchbase
==> Downloading http://packages.couchbase.com/clients/c/libcouchbase-2.3.0.tar.g
######################################################################## 100.0%
==> ./configure --prefix=/usr/local/Cellar/libcouchbase/2.3.0 --disable-examples
==> make install
🍺 /usr/local/Cellar/libcouchbase/2.3.0: 118 files, 1.2M, built in 17 seconds




[CCBC-361] RPM: Upgrade subpackage does not upgrade core Created: 09/Apr/14  Updated: 09/Apr/14  Resolved: 09/Apr/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.0.7, 2.3.0-dp2
Fix Version/s: 2.3.0
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   
Upgrading a subpackage (e.g. libcouchbase2-bin) does not upgrade the core (libcouchbase2-core). The expected behavior is that subpackages should depend on the same version as the core itself.




[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-359] add feature test ensuring that E2BIG is returned on append above 20MB Created: 07/Apr/14  Updated: 07/Apr/14

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

Type: Improvement Priority: Major
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
depends on MB-10778 Append do not return the correct erro... Resolved

 Description   
When continuing to append beyond the maximum value of 20MByte, we should verify that applications receive the correct error response.




[CCBC-358] lcb_get_host/lcb_get_port do not work with CCCP Created: 07/Apr/14  Updated: 08/Apr/14  Resolved: 08/Apr/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: 2.3.0-dp2
Fix Version/s: 2.3.0
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 [ 07/Apr/14 ]
Since get_host/get_port return the "Currently connected REST endpoint", these do not currently do anything running under CCCP mode (where there is no "Currently connected REST endpoint"). The fix here would be to return a valid endpoint anyway, attempting to get information from a variety of sources.
Comment by Mark Nunberg [ 08/Apr/14 ]
http://review.couchbase.org/35382




[CCBC-357] Authentication Errors during rebalance Created: 07/Apr/14  Updated: 02/Jun/14

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

Type: Bug Priority: Critical
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:
Relates to
relates to CCBC-409 Lacking a way to definitively determi... Open

 Description   
Authentication errors may be delivered to the application during a rebalance and while CCCP is being employed.

 Comments   
Comment by Mark Nunberg [ 14/May/14 ]
This _may_ have been fixed in 2.3.1
Comment by Mark Nunberg [ 14/May/14 ]
And.. apparently not. This has been a fairly difficult one to track down and reproduce.
Comment by Mark Nunberg [ 14/May/14 ]
A possible explanation is that since we depend on network errors and not-my-vbucket replies for new configuration information, we might end up in a situation where we don't end up with a wrong mapping until well after a node has been removed (including the 10 second grace period). Need more info to confirm.
Comment by Mark Nunberg [ 02/Jun/14 ]
This one will be open for quite a while. It may have been resolved in packet-ng, however the difficulty to reproduce this means we can't really verify for certain




[CCBC-356] operations stop for 12 seconds entirely during re-add test case Created: 27/Mar/14  Updated: 29/May/14  Resolved: 29/May/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.2.0
Fix Version/s: 2.3.0
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   
During testing of cluster 2.5.1, it was found that operations fail entirely for over 10 seconds.

See: http://sdk-testresults.couchbase.com.s3.amazonaws.com/SDK-SDK/CB-2.5.1-1083/ReAdd2-HYBRID/03-27-14/076505/1a810d18eee7145c7f1c175efb2287dc-MC.txt

 Comments   
Comment by Mark Nunberg [ 28/Mar/14 ]
This seems to be one or two operations taking 17-30s to complete. Why it's taking that long I do not know - there's potentially a bug inside 2.2.0. In any event we should be seeing if this same condition is present with 2.3 and if it is [typo in email, "if not"], investigate it further.

The mere fact that we're getting timeouts for this long however indicates an issue in the client and not the server.




[CCBC-355] update docs with 2.3.0 features Created: 27/Mar/14  Updated: 07/Apr/14  Resolved: 07/Apr/14

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

Type: Bug Priority: Critical
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   
Set up 2.3.0 documentation templates and augment with:
- Section on logging
- Whatever is appropriate for error classifications
- CCCP behavior and new envvars

 Comments   
Comment by Matt Ingenthron [ 27/Mar/14 ]
See https://github.com/couchbaselabs/docs-ng/commit/93de39d05867536d2f550807250e18fe591a3f95 for an example of creating a new manual.
Comment by Mark Nunberg [ 31/Mar/14 ]
https://github.com/couchbaselabs/docs-ng/pull/110
Comment by Mark Nunberg [ 31/Mar/14 ]
Assigning to Matt for review. Re-assign to amy when done




[CCBC-354] libcouchbase tests failing on windows Created: 27/Mar/14  Updated: 31/Mar/14  Resolved: 31/Mar/14

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

Type: Bug Priority: Critical
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   
Current tests are failing on windows CI.

 Comments   
Comment by Mark Nunberg [ 27/Mar/14 ]
http://review.couchbase.org/#/c/35031/




[CCBC-353] Add couchbase cluster compatibility to documentation Created: 25/Mar/14  Updated: 07/Apr/14

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

Type: Improvement Priority: Major
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:
Gantt: finish-start
has to be done after JCBC-438 Add table for 1.8, 2.x and 3.x compat... Open

 Description   
We should probably specify for this given major.minor of the SDK, one of three things for Couchbase Cluster releases:
- unsupported
- supported
- supports all features

These might be an 'x', '—' and "✓" in a table, or whatever Amy comes up with.

This is, in part, planning for 3.0 including beta.

This should be based on the work done in JCBC-438, so it's blocked by that issue.

 Comments   
Comment by Mark Nunberg [ 31/Mar/14 ]
Should we move this to .future, or should I just make my own list and see how ti works? Not a super complicated thing to do




[CCBC-352] libvbucket will return same server on found_incorrect_master causing timeouts Created: 25/Mar/14  Updated: 25/Mar/14  Resolved: 25/Mar/14

Status: Resolved
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: Test 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   
vbucket will direct not-my-vbucket responses to the same server it originated from if the fast forward map claims it should be mapped there. This causes heavy network traffic and times out the command.

 Comments