[CCBC-549] misconfigured .cbcrc can lead to accidentally writing to the wrong bucket Created: 16/Nov/14  Updated: 21/Nov/14  Resolved: 17/Nov/14

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

Type: Bug Priority: Major
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   
I configured .cbcrc but then had a problem with the password. I removed the password configuration and it complained when trying to copy in a file, but then it went ahead and wrote to the default bucket!

Expected behavior: bail out if you have the config username but not the config password. There is a low risk this could cause inadvertent data corruption, thus the blocker.

[ingenthr@reporting ~/s3logs]$ cbc cp packages.couchbase.com-access-log-2014-10-06-00-22-37-50FD194677E5D44C
Warning: File /home/ingenthr/.cbcrc present but has problems (Configuration file must be formatted as key-value pairs)
packages.couchbase.com-access-log-2014-10-06-00-22-37-50FD194677E5D44CStored. CAS=0xcaec619ead470000

After removing the offending password line, it still writes to the default bucket!

[ingenthr@reporting ~/s3logs]$ cat ~/.cbcrc
# Generated by cbc at Sun Nov 16 19:42:00 2014

connstr=http://localhost/default?
user=s3logs
[ingenthr@reporting ~/s3logs]$ cbc cp packages.couchbase.com-access-log-2014-10-
06-00-22-37-50FD194677E5D44C
packages.couchbase.com-access-log-2014-10-06-00-22-37-50FD194677E5D44CStored. CAS=0xccde8ea08480000
[ingenthr@reporting ~/s3logs]$ # This wrote to the default bucket!!!


 Comments   
Comment by Mark Nunberg [ 16/Nov/14 ]
Username is currently ignored by the library. You're explicitly passing `default` in the connection string, which is telling the library to connect to the default bucket.

It might still be a bug that we don't actually use username via `cbc`, but I don't think this is a blocker.
Comment by Matt Ingenthron [ 16/Nov/14 ]
Actually, I wasn't passing it explicitly, that was there when cbc generated the config for me when I passed it just a username and a password.

Brett pointed out that I probably, more than the average user, misconfigured things by doing something unusual by using username without bucket name.

Lowering the priority here. What do you think is appropriate?
Comment by Mark Nunberg [ 16/Nov/14 ]
I think you are probably the first user to employ the cbcrc functionality in a while :) -- but I guess major (which is the default level) is alright here.
Comment by Mark Nunberg [ 16/Nov/14 ]
http://review.couchbase.org/#/c/43286/




[CCBC-553] libcouchbase doc page should list debian as a supported platform Created: 19/Nov/14  Updated: 21/Nov/14

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

Type: Bug Priority: Major
Reporter: Cihan Biyikoglu Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: http://docs.couchbase.com/developer/c-2.4/download-install.html
does not reference debian as supported at the top list: should add debian 7 to the list.
"
The installation process is different for each platform. You can install the C SDK on the following platforms:

CentOS 5, CentOS 6
Ubuntu 10.04, Ubuntu 12.04, Ubuntu 14.04
Mac OS X
Windows"





[CCBC-550] cbc-pillowfight value for "-r" over 50 produces only sets Created: 18/Nov/14  Updated: 21/Nov/14

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

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


 Description   
When modifying the "-r" or "--set-pcnt", any value of 50 or below produces the desired ratio of gets to sets, but above 50 (even 51) produces only sets.




[CCBC-554] No debuginfo rpm provided for RHEL/CentOS Created: 20/Nov/14  Updated: 21/Nov/14

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

Type: Bug Priority: Minor
Reporter: Robert Groenenberg Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: supportability
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: CentOS 6.6 + Couchbase 3.0.1 + libcouchbase 2.4.4


 Description   
The tarball with libcouchbase rpms does not include the debuginfo package. The debuginfo package is needed to analyze issues related to or in lcb.
It used to be there a while ago (2.0.x versions), but somewhere along the line it was dropped.

When building the rpms from the sources, the debuginfo rpm is created, depending on the rpmmacros of the build server.
File /usr/lib/rpm/macro from the redhat-rpm-config package should take care of setting '%debug_package' and related macros to cause the debuginfo package to be build.

 Comments   
Comment by Mark Nunberg [ 20/Nov/14 ]
Thanks for the report. The reason is because our build scripts were using `buildsys-build` rather than `@buildsys-build`; the former does not exist, while the latter includes the proper redhat-rpm-config, among other things.




[CCBC-552] Add documentation advising proper diagnostic routines when debugging crashes. Created: 19/Nov/14  Updated: 19/Nov/14

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

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





[CCBC-544] lcb_wait3 does not wait for execution Created: 06/Nov/14  Updated: 11/Nov/14  Resolved: 06/Nov/14

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


 Description   
lcb_wait3 with LCB_WAIT_DEFAULT does not wait for execution to complete

 Comments   
Comment by Subhashni Balakrishnan [ 06/Nov/14 ]
Not a bug was missing libevent-devel.




[CCBC-539] libcouchbase client crashes on stats when server stops Created: 04/Nov/14  Updated: 11/Nov/14  Resolved: 05/Nov/14

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

Type: Bug Priority: Critical
Reporter: Robert Groenenberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: CentOS 6.6 x86_64, Couchbase-server-enterprise 3.0.1, libcouchbase2-libevent-2.4.3


 Description   
My application periodically retrieves the server stats via lcb_server_stats(). When one of the Couchbase servers is stopped or restarted ($ /etc/init.d/couchbase-server restart) the application often crashes.

It seems that a LCB_NETWORK_ERROR is not properly handle while collecting the stats from the servers in the cluster.
Program terminated with signal 11, Segmentation fault.
Stack trace:
#0 0x00007f25c7206e3c in vfprintf () from /lib64/libc.so.6
#1 0x00007f25c7228619 in vsprintf () from /lib64/libc.so.6
#2 0x00007f25c720e2c8 in sprintf () from /lib64/libc.so.6
#3 0x00007f25c8ff4530 in stats_handler (pl=<value optimized out>, req=<value optimized out>, err=LCB_NETWORK_ERROR, arg=0x0)
    at src/operations/stats.c:45
#4 0x00007f25c90006b4 in H_verbosity (pipeline=0x7f25a8a1c950, req=0x7f254c0c5ae0, res=0x7f25a8a1cba0, immerr=<value optimized out>)
    at src/handler.c:413
#5 mcreq_dispatch_response (pipeline=0x7f25a8a1c950, req=0x7f254c0c5ae0, res=0x7f25a8a1cba0, immerr=<value optimized out>)
    at src/handler.c:564
#6 0x00007f25c8ff0933 in bail_op (rq=0x2311100, op=0x7f254c0c9b10, err=LCB_ETIMEDOUT) at src/retryq.c:145
#7 0x00007f25c8ff0e1d in rq_flush (rq=0x2311100, throttle=1) at src/retryq.c:210
#8 0x00007f25c8fef104 in timer_callback (sock=<value optimized out>, which=<value optimized out>, arg=0x23d83a0)
    at src/lcbio/timer.c:45
#9 0x00007f25c9234b44 in event_base_loop () from /usr/lib64/libevent-1.4.so.2
#10 0x000000000048e42c in con_thr (arg=0x23d4738) at src/store_couchbase.c:2946
#11 0x00007f25c755a9d1 in start_thread () from /lib64/libpthread.so.0
#12 0x00007f25c72a786d in clone () from /lib64/libc.so.6

The SEGV occurs in operations/stats.c:45 :
    sprintf(epbuf, "%s:%s", mcserver_get_host(server), mcserver_get_port(server));

Building the client lib from source w/o optimisation provides a bit more insight:
(gdb) p server
$3 = (mc_SERVER *) 0x7f8d77ffe970
(gdb) p *server
$4 = {pipeline = {requests = {first = 0x0, last = 0x0}, parent = 0x112c138, flush_start = 0, index = 0, ctxqueued = {first = 0x0,
      last = 0x0}, buf_done_callback = 0, nbmgr = {sendq = {pending = {first = 0x0, last = 0x0}, pdus = {first = 0x0, last = 0x0},
        last_requested = 0x0, last_offset = 0, pdu_offset = 0, elempool = {active = {first = 0x0, last = 0x0}, avail = {
            first = 0x0, last = 0x0}, basealloc = 0, maxblocks = 0, curblocks = 0, cacheblocks = 0x0, ncacheblocks = 0,
          mgr = 0x0}}, datapool = {active = {first = 0x0, last = 0x0}, avail = {first = 0x0, last = 0x0}, basealloc = 0,
        maxblocks = 0, curblocks = 0, cacheblocks = 0x0, ncacheblocks = 0, mgr = 0x0}, settings = {sndq_cacheblocks = 0,
        sndq_basealloc = 0, dea_cacheblocks = 0, dea_basealloc = 0, data_cacheblocks = 0, data_basealloc = 0}}, reqpool = {sendq = {
        pending = {first = 0x0, last = 0x0}, pdus = {first = 0x0, last = 0x0}, last_requested = 0x0, last_offset = 0,
        pdu_offset = 0, elempool = {active = {first = 0x0, last = 0x0}, avail = {first = 0x0, last = 0x0}, basealloc = 0,
          maxblocks = 0, curblocks = 0, cacheblocks = 0x0, ncacheblocks = 0, mgr = 0x0}}, datapool = {active = {first = 0x0,
          last = 0x0}, avail = {first = 0x0, last = 0x0}, basealloc = 0, maxblocks = 0, curblocks = 0, cacheblocks = 0x0,
        ncacheblocks = 0, mgr = 0x0}, settings = {sndq_cacheblocks = 0, sndq_basealloc = 0, dea_cacheblocks = 0, dea_basealloc = 0,
        data_cacheblocks = 0, data_basealloc = 0}}}, datahost = 0x0, viewshost = 0x0, resthost = 0x0, instance = 0x112c130,
  settings = 0x0, state = 0, compsupport = 0, io_timer = 0x0, connctx = 0x0, connreq = {type = 0, u = {cs = 0x0, preq = 0x0,
      p_generic = 0x0}, dtor = 0}, curhost = 0x0}
(gdb) p server->curhost
$5 = (lcb_host_t *) 0x0

Obviously retrieving the host and port number from a NULL-pointer doesn't fly.

 Comments   
Comment by Robert Groenenberg [ 04/Nov/14 ]
Moving the retrieval of the host/port into the else part resolves the issue, at least for this particular crash. I'm not familiar enough with the code to judge whether all cases where curhost is not set go into the 1st leg of the if.

--- src/operations/stats.c.orig 2014-11-04 11:46:50.130824769 +0100
+++ src/operations/stats.c 2014-11-04 11:47:33.378971270 +0100
@@ -42,7 +42,6 @@
     lcb_RESPCALLBACK callback;
     lcb_t instance = server->instance;
 
- sprintf(epbuf, "%s:%s", mcserver_get_host(server), mcserver_get_port(server));
     callback = lcb_find_callback(instance, LCB_CALLBACK_STATS);
 
     if (!arg) {
@@ -59,6 +58,7 @@
         free(ck);
 
     } else {
+ sprintf(epbuf, "%s:%s", mcserver_get_host(server), mcserver_get_port(server));
         resp->server = epbuf;
         resp->cookie = (void *)ck->base.cookie;
         callback(instance, LCB_CALLBACK_STATS, (lcb_RESPBASE *)resp);


A check on server->curhost being valid before invoking mcserver_get_host() and mcserver_get_port() would seem to be required, also in handle_bcast().
Comment by Mark Nunberg [ 04/Nov/14 ]
I could not reproduce this using the current master; and I assume this issue has already been fixed in https://github.com/couchbase/libcouchbase/commit/5eb079130035db1c6dffb54b70c55a1c9aa8b417

This is still worth investigating into, as the reason for your crash is not so much related to stats as it is related to the fact that a 'dummy' server object is used to determine this information: https://github.com/couchbase/libcouchbase/blob/master/src/retryq.c#L130

This is required because some commands need extra context, when in fact there is no specific server for the given command.
Comment by Robert Groenenberg [ 04/Nov/14 ]
Looks like you are right on the first point: I built the library from the 2.4.3 tar-ball plus the mentioned fix. With that the crash doesn't happen anymore.




[CCBC-543] LCB_CNTL_DURABILITY_INTERVAL ignored Created: 06/Nov/14  Updated: 11/Nov/14  Resolved: 06/Nov/14

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

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


 Description   
This fixes a bug where the durability interval would be ignored if modified via lcb_cntl. Note that specifying the interval via the options structure would still work.

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




[CCBC-548] Build error on libcouchbase-master Created: 10/Nov/14  Updated: 10/Nov/14  Resolved: 10/Nov/14

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

Type: Bug Priority: Major
Reporter: Sergey Avseyev Assignee: Sergey Avseyev
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: 2.4.3-48-gcecab16


 Description   
config/dummy-c.c:1:0: error: ISO C forbids an empty translation unit [-Werror=pedantic]
cc1: all warnings being treated as errors
make[1]: *** [config/liblcbsnappy_la-dummy-c.lo] Error 1
make[1]: Leaving directory `/home/avsej/code/couchbase-ruby/libcouchbase'
make: *** [all] Error 2


 Comments   
Comment by Sergey Avseyev [ 10/Nov/14 ]
./config/autorun.sh && ./configure --enable-maintainer-mode && make
Comment by Sergey Avseyev [ 10/Nov/14 ]
http://review.couchbase.org/43042




[CCBC-546] Dead sockets returned from connection pool Created: 08/Nov/14  Updated: 10/Nov/14  Resolved: 10/Nov/14

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

Type: Improvement Priority: Critical
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-547 Detect dead sockets under UV Technical task Open Mark Nunberg  

 Description   
Because of how the server (and possibly other intermediaries) work, a socket may be closed while it is idle without any protocol-level indication warning the client of this event.

The end result is that sometimes (particularly with views), a cached socket is retrieved, and at the first I/O operation, the operation fails because the socket has been closed, which in turn gives an error back to the user.

The library should attempt to check and see if the socket is closed first before returning it back to lcbcore.

 Comments   
Comment by Mark Nunberg [ 09/Nov/14 ]
http://review.couchbase.org/#/c/43029/
Comment by Mark Nunberg [ 09/Nov/14 ]
A temporary workaround for this is to always disable connection pooling, so that there are no cached sockets.
Comment by Matt Ingenthron [ 10/Nov/14 ]
I don't think sockets should be closed by the cluster side. Have you observed this? Is this cbmcd or cbhttp sockets?
Comment by Mark Nunberg [ 10/Nov/14 ]
This is HTTP. I don't think the server should be doing this either (and it violates the HTTP spec, strictly speaking), but then again the server has never been truly HTTP compliant anyway.

I've never observed this issue personally, but then again I've heard this come from a variety of sources, and the nature of this error is always "sometimes"




Dead sockets returned from connection pool (CCBC-546)

[CCBC-547] Detect dead sockets under UV Created: 08/Nov/14  Updated: 09/Nov/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.4.4
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   
Currently it's not clear how this is done.




[CCBC-545] No default for lcb_store3 operation Created: 07/Nov/14  Updated: 07/Nov/14

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

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


 Description   
It would be good to have LCB_SET as default




[CCBC-541] Include installation instructions for libcouchbase onto Debian 7 Created: 06/Nov/14  Updated: 06/Nov/14  Resolved: 06/Nov/14

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

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


 Description   
Debian is a supported platform for Couchbase Server,
please include instructions how to install libcouchbase on Debian 7.

On this page http://docs.couchbase.com/developer/c-2.4/download-install.html
Remove "These packages should work for Debian...."

Add "deb http://packages.couchbase.com/ubuntu wheezy wheezy/main"
 to the sources table.

 Comments   
Comment by Mark Nunberg [ 06/Nov/14 ]
https://github.com/couchbase/docs/pull/26




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

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

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

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

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

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





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


..
Following the instructions from the manual (as I did today) work fine for me (just had to look them up earlier today for something else)
Comment by Matt Ingenthron [ 20/Oct/14 ]
Terry: With Mark's comments here, is it okay?
Comment by Ian McCloy [ 06/Nov/14 ]
I couldn't get the instructions in the documentation working on Debian 7

Copy/Pasted it directly.

wget -O- http://packages.couchbase.com/ubuntu/couchbase.key | sudo apt-key add
--2014-11-06 06:58:43-- http://packages.couchbase.com/ubuntu/couchbase.key
Resolving packages.couchbase.com (packages.couchbase.com)... gpg: can't open `': No such file or directory
Comment by Mark Nunberg [ 06/Nov/14 ]
Missing a trailing comma for 'apt-key add' on debian
Comment by Mark Nunberg [ 06/Nov/14 ]
https://github.com/couchbase/docs/pull/26




[CCBC-542] cbc-pillowfight --min_size not working Created: 06/Nov/14  Updated: 06/Nov/14  Resolved: 06/Nov/14

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

Type: Bug Priority: Major
Reporter: Benjamin Bryant Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Rightscale demo environment. CentOS 6.4.


 Description   
Followed instructions here: to install 2.4 libcouchbase.
http://docs.couchbase.com/developer/c-2.4/download-install.html

Installation successful. 'cbc-pillowfight --help' shows updated help output.

running the following command:
./cbc-pillowfight -U couchbase://ec2-50-18-100-223.us-west-1.compute.amazonaws.com/beer-sample -m 8192 -M 8192 -I 1340000 -B 1000 -p $HOSTNAME --num-threads=4 --timeout=5000000

the -m option does not work. Tried setting to 8091 just to see if a different value would work, but no. Pillowfight creates the dataset with variable value sizes.


 Comments   
Comment by Mark Nunberg [ 06/Nov/14 ]
http://review.couchbase.org/#/c/42908/




[CCBC-540] Documentation about lcb_durability_opts_st Created: 06/Nov/14  Updated: 06/Nov/14  Resolved: 06/Nov/14

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

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


 Description   
The documentation for the lcb_durability_opts_st structure at this address: http://docs.couchbase.com/sdk-api/couchbase-c-client-2.4.3/group___l_c_b___e_n_d_u_r_e.html#structlcb___d_u_r_a_b_i_l_i_t_y_o_p_t_sv0

provides information on the different parameters of the durability poll.However it does not specify which unit is used for the "interval" attribute. Will request to make it clear.

---
Looks like "timeout" field, "interval" field can also be specified in microseconds.

https://github.com/couchbase/libcouchbase/blob/2.4.3/src/settings.h#L53 - LCB_DEFAULT_DURABILITY_INTERVAL
https://github.com/couchbase/libcouchbase/blob/2.4.3/src/operations/durability.c#L648 - Default value of 100ms chosen when interval isn't specified.




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




[CCBC-537] cancel_http_request will not properly cancel if called before lcb_wait Created: 02/Nov/14  Updated: 03/Nov/14  Resolved: 02/Nov/14

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

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


 Description   
This sometimes manifests as hanging during destruction, or a segfault when the request is finally serviced.




[CCBC-538] Memory leak in HTTP request with body Created: 02/Nov/14  Updated: 03/Nov/14  Resolved: 03/Nov/14

Status: Closed
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: 2.4.3
Fix Version/s: 2.4.4
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 lcb HTTP code copies over the value of the request body to the internal structure, but does not free it once the request is freed.




[CCBC-535] add release notes to DITA docs Created: 30/Oct/14  Updated: 01/Nov/14  Resolved: 01/Nov/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: docs
Affects Version/s: 2.4.3
Fix Version/s: 2.4.4
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   
In the DITA migration, release notes were not covered other than through a link. Please bring the release notes into the versioned documentation as we do with the other SDKs.




[CCBC-534] LCB_CNTL_IMPLICIT_FLUSH not working with v2 API Created: 29/Oct/14  Updated: 30/Oct/14  Resolved: 30/Oct/14

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

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


 Description   
The LCB_CNTL_IMPLICIT_FLUSH exists to disable the automatic flushing of data when multiple scheduling APIs are called before waiting for the network. Currently this behavior does not work because the version 2 api wrappers call mcreq_sched_flush() directly, rather than proxying over to lcb_sched_flush() which abides by the settings of the given flag.




[CCBC-536] cb.endure_multi core dumps if the same key is more than once in the list. Created: 30/Oct/14  Updated: 30/Oct/14  Resolved: 30/Oct/14

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

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

Attachments: File endure_multi_test.py    

 Description   
While trying to simplify a customer test cast I came across this bug:

#! /usr/bin/env python
import couchbase

cb = couchbase.Couchbase.connect(bucket='default', host='192.168.63.101')
set_result=["key1", "key2", "key2"]
cb.endure_multi(set_result,persist_to=-1,replicate_to=-1,timeout=10)

./endure_multi_test.py
python-couchbase: self->nremaining == 0 at src/oputil.c:77. AbortAborted (core dumped)


Back trace from the core:


(gdb) thread apply all bt

Thread 1 (Thread 0x7fe75e889700 (LWP 3717)):
#0 0x0000003f3e832925 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x0000003f3e834105 in abort () at abort.c:92
#2 0x00007fe7574a7a79 in pycbc_handle_assert (msg=0x7fe7574baba8 "self->nremaining == 0", file=0x7fe7574bab04 "src/oputil.c", line=77) at src/exceptions.c:25
#3 0x00007fe7574b13b4 in pycbc_common_vars_wait (cv=0x7fffe7752110, self=0x14c0c80) at src/oputil.c:77
#4 0x00007fe7574b02db in pycbc_Connection_endure_multi (self=0x14c0c80, args=<value optimized out>, kwargs=<value optimized out>) at src/miscops.c:314
#5 0x00007fe75e8d0c63 in PyObject_Call (func=<built-in method endure_multi of Connection object at remote 0x14c0c80>, arg=<value optimized out>, kw=<value optimized out>) at Objects/abstract.c:2492
#6 0x00007fe75e95cc93 in PyEval_CallObjectWithKeywords (func=<built-in method endure_multi of Connection object at remote 0x14c0c80>, arg=(['key1', 'key2', 'key2'], -1, -1), kw=<value optimized out>) at Python/ceval.c:3663
#7 0x00007fe75e8e8b5c in methoddescr_call (descr=<value optimized out>, args=(['key1', 'key2', 'key2'], -1, -1), kwds={'interval': <float at remote 0x13725c8>, 'check_removed': False, 'timeout': 10}) at Objects/descrobject.c:246
#8 0x00007fe75e8d0c63 in PyObject_Call (func=<method_descriptor at remote 0x1495ea8>, arg=<value optimized out>, kw=<value optimized out>) at Objects/abstract.c:2492
#9 0x00007fe75e961f74 in do_call (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4012
#10 call_function (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:3817
#11 PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:2453
#12 0x00007fe75e964657 in PyEval_EvalCodeEx (co=0x7fe75e7c2d50, globals=<value optimized out>, locals=<value optimized out>, args=<value optimized out>, argcount=2, kws=0x13e2a08, kwcount=3, defs=0x1638a88, defcount=5, closure=0x0) at Python/ceval.c:3044
#13 0x00007fe75e962aa4 in fast_function (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:3890
#14 call_function (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:3815
#15 PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:2453
#16 0x00007fe75e964657 in PyEval_EvalCodeEx (co=0x7fe75e7a8cd8, globals=<value optimized out>, locals=<value optimized out>, args=<value optimized out>, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3044
#17 0x00007fe75e964732 in PyEval_EvalCode (co=<value optimized out>, globals=<value optimized out>, locals=<value optimized out>) at Python/ceval.c:545
#18 0x00007fe75e97ebac in run_mod (mod=<value optimized out>, filename=<value optimized out>, globals=
    {'__builtins__': <module at remote 0x7fe75e85d868>, 'cb': <Connection at remote 0x14c0c80>, '__file__': './endure_multi_test.py', 'set_result': ['key1', 'key2', 'key2'], '__package__': None, 'couchbase': <module at remote 0x7fe75e7c3130>, '__name__': '__main__', '__doc__': None}, locals=
    {'__builtins__': <module at remote 0x7fe75e85d868>, 'cb': <Connection at remote 0x14c0c80>, '__file__': './endure_multi_test.py', 'set_result': ['key1', 'key2', 'key2'], '__package__': None, 'couchbase': <module at remote 0x7fe75e7c3130>, '__name__': '__main__', '__doc__': None}, flags=<value optimized out>,
    arena=<value optimized out>) at Python/pythonrun.c:1358
#19 0x00007fe75e97ec80 in PyRun_FileExFlags (fp=0x13e1fb0, filename=0x7fffe77538df "./endure_multi_test.py", start=<value optimized out>, globals=
    {'__builtins__': <module at remote 0x7fe75e85d868>, 'cb': <Connection at remote 0x14c0c80>, '__file__': './endure_multi_test.py', 'set_result': ['key1', 'key2', 'key2'], '__package__': None, 'couchbase': <module at remote 0x7fe75e7c3130>, '__name__': '__main__', '__doc__': None}, locals=
    {'__builtins__': <module at remote 0x7fe75e85d868>, 'cb': <Connection at remote 0x14c0c80>, '__file__': './endure_multi_test.py', 'set_result': ['key1', 'key2', 'key2'], '__package__': None, 'couchbase': <module at remote 0x7fe75e7c3130>, '__name__': '__main__', '__doc__': None}, closeit=1, flags=
    0x7fffe77529c0) at Python/pythonrun.c:1344
#20 0x00007fe75e98016c in PyRun_SimpleFileExFlags (fp=0x13e1fb0, filename=0x7fffe77538df "./endure_multi_test.py", closeit=1, flags=0x7fffe77529c0) at Python/pythonrun.c:948
#21 0x00007fe75e98c8a2 in Py_Main (argc=<value optimized out>, argv=<value optimized out>) at Modules/main.c:618
#22 0x0000003f3e81ed1d in __libc_start_main (main=0x400710 <main>, argc=2, ubp_av=0x7fffe7752ae8, init=<value optimized out>, fini=<value optimized out>, rtld_fini=<value optimized out>, stack_end=0x7fffe7752ad8) at libc-start.c:226
#23 0x0000000000400649 in _start ()

 Comments   
Comment by Mark Nunberg [ 30/Oct/14 ]
I am surprised the library did not return with an error despite the fact that multiple keys are not allowed in endure.
Comment by Mark Nunberg [ 30/Oct/14 ]
http://review.couchbase.org/42643
Comment by Patrick Varley [ 30/Oct/14 ]
Tested it against master it cores dump there too:

[vagrant@localhost vagrant]$ LD_LIBRARY_PATH=/usr/local/lib ./endure_multi_test.py
python-couchbase: self->nremaining == 0 at src/oputil.c:77. AbortAborted (core dumped)
Comment by Mark Nunberg [ 30/Oct/14 ]
Yes, the change hasn't been merged yet :)




[CCBC-530] Pillowfight performance drops to near-0 during rebalance Created: 23/Oct/14  Updated: 30/Oct/14  Resolved: 30/Oct/14

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

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

Attachments: PNG File Screen Shot 2014-10-23 at 11.54.58 AM.png    

 Description   
Running this pillowfight command which should be very light in usage:
cbc-pillowfight -U couchbase://ec2-54-176-27-210.us-west-1.compute.amazonaws.com/event_stream?retry_backoff=0.0 -t 4 -B 1 -I 300000 -m 1024 -M 1024 -c -1

I rebalance one node out of the cluster and the performance becomes very erratic during the rebalance and then returns to very smooth once completed. See attached screenshot for what I'm observing.

According to Mark, an improvement could be made to have the client keep using the ffmap as it gets NMV responses instead of throwing it away each time.






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

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

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

Issue Links:
Dependency

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

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




[CCBC-331] memcached buckets may receive operation failures during rebalance Created: 20/Feb/14  Updated: 29/Oct/14  Resolved: 29/Oct/14

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

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


 Description   
When updating the config received on http stream, the client returns an error LCB_CLIENT_ETMPFAIL for memcached buckets. Please clarify if this design is intentional.

https://github.com/couchbase/libcouchbase/blob/master/src/bconf_provider.c#L183


 Comments   
Comment by Mark Nunberg [ 20/Feb/14 ]
I'd argue this is by design as a memcached bucket is usually intended for lightweight caching purposes. Rather than rescheduling all commands we just fail them all out. The error message might need to be a bit more helpful?
Comment by Matt Ingenthron [ 18/Mar/14 ]
This came up during a test of an upgrade. Usually during upgrade with memcached buckets, we just fire the request at the node we're aware of. That does mean that there is a possible lack of consistency between two actors on where to fire a request, based on the config they're using and the ketama hashing, but that's okay for a cache.

I don't think we'd expect failing out requests though in this case.

From reading the code, it looks like maybe we just need to do nothing during this replace_config() if it's for memcached buckets? Looking at that, right now if we have an add node case (which comes up in this test), we'll push a bunch of errors up to the app that would have otherwise been successful.
Comment by Mark Nunberg [ 18/Mar/14 ]
Because we support hashkey, we have no way to route requests to a server without that kind of context. With Couchbase buckets we already have the vbucket so we don't need to re-hash; however this isn't the case with memcached buckets as the destination bucket depends on the hash of the actual key which we forget about once the operation is scheduled.

In order to make this work, we'd either need to disable support for hashkey or keep the (hash)key around for future operations.
Comment by Matt Ingenthron [ 18/Mar/14 ]
I think the right thing to do here is to use the previously hashed location. Anything different would be a change over what we do in other clients and moxi. it'd also be a change over what we did in previous releases, I believe.

Looking at it from a cache perspective, when adding a node to the cluster the old node has a cached value, and the new node will eventually have a cached value. The old location would slowly LRU out and the requests would get to the new place eventually.

So if we don't rehash, we actually will likely get correct behavior, see what I mean? It's different than vbucket situations, but memcached buckets are different than couchbase buckets.
Comment by Mark Nunberg [ 18/Mar/14 ]
For storage, the stored data will never be read back out again - so it's pointless to send the data there.

For retrieval, a potentially stale version of the data may be retrieved (assuming it hasn't been updated on the "correct" node yet). I think the "Correct" behavior in that light is to retry retrieval operations but not storage operations. This would still "fail" operations, but I think it's the correct thing to do.

If you agree, please change the title of this ticket to reflect this - and we'll try to fix it -- maybe in this release or in the next.
Comment by Matt Ingenthron [ 18/Mar/14 ]
What was the behavior before the integration of confmon?

For storage, it may be pointless to send the data there, but it's more disruptive if we start returning errors to the caller when there was no error. There was a topology change which has a defined behavior.

For retrieval, the potentially stale is the expected behavior with memcached buckets. I believe that's the behavior in the current release too.

Is it a large change to just not do anything in that section of code? It doesn't seem like it. We'd just let the operations go to the node they're hashed for and then we'd have (approximately) the same behavior as in the current release, right?
Comment by Mark Nunberg [ 18/Mar/14 ]
2.3 has not changed the way we handle this. This has always been the behavior -- I'm just explaining why the behavior has been the way it has been.

See: https://github.com/mnunberg/libcouchbase/blob/2.2.0/src/bconf_provider.c#L320-339 (2.2.0)
See: https://github.com/mnunberg/libcouchbase/blob/2.0.7/src/instance.c#L734-744 (2.0.7)

You'd need a bit more code out there to relocate properly to a memcached bucket (we relocate currently based on the vbucket destination -- in this case we'd need to remember the _old_ destination). Also, this does not help if a server was _removed_ from the cluster (in which case the prior "Destination Index" may no longer exist).
Comment by Matt Ingenthron [ 19/Mar/14 ]
I didn't realize this was the behavior through release 2.2. We should definitely release note this.

I don't think we need to relocate, as previously mentioned. We don't do that elsewhere, but we don't have failures either. Also, not worried as much about the remove case.
Comment by Mark Nunberg [ 25/Oct/14 ]
See http://review.couchbase.org/#/c/42445/ for a prospective fix. I'm not sure when this change will actually make it through; just that it exists.




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

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

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


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

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

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

 Comments   
Comment by Mark Nunberg [ 25/Oct/14 ]
See: http://docs.couchbase.com/developer/c-2.4/handling-errors.html
See: http://docs.couchbase.com/sdk-api/couchbase-c-client-2.4.2/group___l_c_b___e_r_r_o_r_s.html
Comment by Mark Nunberg [ 25/Oct/14 ]
These pretty much cover it (the first is a "guide" on how to handle errors, the second is an enumeration of the errors thrown by the library). Please file additional bugs if something isn't clear there




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

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

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


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

 Comments   
Comment by Mark Nunberg [ 25/Oct/14 ]
commit b8f2c1e67e69eba4ea99507084e866be65043b53
http://review.couchbase.org/39255

Appears to have been done already?




[CCBC-353] Add couchbase cluster compatibility to documentation Created: 25/Mar/14  Updated: 29/Oct/14  Resolved: 25/Oct/14

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

Type: Improvement Priority: Major
Reporter: Matt Ingenthron Assignee: Matt Ingenthron
Resolution: Fixed 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
Comment by Mark Nunberg [ 25/Oct/14 ]
This is done in the newer documentation with the "Compatibility matrix"




[CCBC-529] Return error for ignored command options Created: 22/Oct/14  Updated: 29/Oct/14  Resolved: 24/Oct/14

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

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


 Description   
The library should return an error code if a command structure contains an option that does not make sense for a given command, or conflicts with another option specific in the same structure




[CCBC-533] Ubuntu installation instructions Created: 28/Oct/14  Updated: 29/Oct/14  Resolved: 29/Oct/14

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

Type: Bug Priority: Minor
Reporter: Jim Walker Assignee: Jim Walker
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Specifically I had issues following the installation on Ubuntu 14.04, but looks Ubuntu specific.


 Description   
(I was guided to create a CCBC for C SDK docs)

Issue relates to the Ubuntu install information found here:

http://docs.couchbase.com/developer/c-2.4/download-install.html#concept553__install-deb

I found these instructions required tweaking to work.

1) Copy and paste of the wget resulted in a failing command. The apt-key portion needs a '-' to say read key from stdin.

"wget -O- http://packages.couchbase.com/ubuntu/couchbase.key | sudo apt-key add -"

2) "Next, using your favorite editor, create a new file in the /etc/apt/sources.list.d directory."

This should state that the file needs to be called <something>.list, or it is ignored and if you don't know you may have to play a google guessing game for the correct suffix.





 Comments   
Comment by Mark Nunberg [ 29/Oct/14 ]
https://github.com/couchbase/docs/pull/19
Comment by Mark Nunberg [ 29/Oct/14 ]
In the future we should simply offer a `noarch` deb file which will do this stuff for us; manually modifying files might be a bit annoying for basic users




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

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

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


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

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

Tried building master, release 2.4.2 and 2.3.2.

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

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

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

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




[CCBC-531] Document the behaviour of Arithmetic/Counter operations max/min values Created: 24/Oct/14  Updated: 28/Oct/14  Resolved: 28/Oct/14

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

Type: Improvement Priority: Minor
Reporter: Ian McCloy 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   
http://docs.couchbase.com/sdk-api/couchbase-c-client-2.4.0/group___l_c_b___a_r_i_t_h.html

The following should be documented in the API reference. In libcouchbase the values that are incremented and decremented are unsigned 64bit int values. So valid values are integers from 0 to 18,446,744,073,709,551,615 If you have the maximum value 18,446,744,073,709,551,615 and increment it by 100 it will wrap to 0 and keep incrementing, this will set the value to 99. If the value is 0 and you decrement the value by 1 it will stay at 0, it does not wrap.

 Comments   
Comment by Mark Nunberg [ 25/Oct/14 ]
http://review.couchbase.org/42444
Comment by Ian McCloy [ 28/Oct/14 ]
This information needs to be added to the API reference http://docs.couchbase.com/sdk-api/couchbase-c-client-2.4.2/group___l_c_b___a_r_i_t_h.html as well please.
Comment by Mark Nunberg [ 28/Oct/14 ]
The updates will happen when 2.4.4 is released. The API documentation is bundled and versioned with the library itself, and is generated from the header.




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

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

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


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

From the customer:

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

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

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

ASK: Is the customer concern valid?

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

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

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




[CCBC-532] Incr / Decr with TTL doesn't change TTL value Created: 23/Oct/14  Updated: 28/Oct/14  Resolved: 27/Oct/14

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

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


 Description   
Ubuntu 12.04.5
Python 2.7.3
CB 3.0
LCB Version= 2.4.3
Python SDK - 2014-10-06 10:33:08.652762 __version__ = '1.2.4'

Setting a new TTL value to a document during an increment or decrement call doesn't change the TTL value for the document. *Am still testing this against other SDKs/LCB as well*



Have this is a try/except block to print any errors, no errors are printed.

=========

print "Setting foo now"

c.set("foo", 18446744073709551615, ttl=300)

try:
  data = c.get("foo")

except CouchbaseError as e:
    print "Couldn't retrieve value for key", e
    # Rethrow the exception, making the application exit
    raise

====

print out the key_exptime

then run

====


print "Incrementing with TTL"

try:
  c.incr("foo", amount=100, ttl=10)

except CouchbaseError as e:
    print "Couldn't incr value for key", e
    # Rethrow the exception, making the application exit
    raise

=====

The value is incremented as expected.
print out key_exptime and it hasn't changed and doc still exists.

 Comments   
Comment by Mark Nunberg [ 23/Oct/14 ]
#!/usr/bin/env python
from couchbase import Couchbase
from time import sleep

cb = Couchbase.connect(bucket='default')
cb.delete('counter', quiet=True)
cb.incr('counter',amount=1, initial=100, ttl=1)
sleep(2)
cb.get('counter')

===============
Traceback (most recent call last):
  File "ttl.py", line 9, in <module>
    cb.get('counter')
  File "/Users/mnunberg/Source/pycbc-stable/couchbase/connection.py", line 500, in get
    return _Base.get(self, key, ttl, quiet, replica, no_format)
couchbase.exceptions._NotFoundError_0xD (generated, catch NotFoundError): <Key=u'counter', RC=0xD[The key does not exist on the server], Operational Error, Results=1, C Source=(src/multiresult.c,282)>
Comment by Mark Nunberg [ 23/Oct/14 ]
Apparently, TTL only works if `create` is true, per the protocol specs.

https://github.com/couchbase/libcouchbase/blob/master/src/operations/counter.c#L57-66
Comment by Mark Nunberg [ 24/Oct/14 ]
Will fix this in LCB
Comment by Mark Nunberg [ 28/Oct/14 ]
https://github.com/couchbase/libcouchbase/commit/c272003370bfa8a63831577762646fc695d96530




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

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

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


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

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

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

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




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

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

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


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




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

Status: Closed
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: None
Fix Version/s: 2.4.4
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   
Server 3.0.0 sometimes returns an empty config. We should test for this and ensure the parse fails rather than crashing the client.

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




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

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

Type: Improvement 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-108] Allow per-command retries for not-my-vbucket and other transient errors Created: 04/Oct/12  Updated: 25/Oct/14  Resolved: 25/Oct/14

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

Type: Improvement Priority: Major
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   
We should avoid the possibility of 'infinite' errors and allow the user the ability of seeing the 'real' error which caused the command to fail..

http://review.couchbase.org/13177

 Comments   
Comment by Mark Nunberg [ 25/Oct/14 ]
While this is a nice fix, I think it's beyond the scope of this library for now. The library handles these items fairly simply and efficiently now.




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

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

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


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

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


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

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

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




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

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.0-dp2
Fix Version/s: None
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 MB-11875 memcached should respond with differe... Resolved

 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-501] Hide no_verify SSL option Created: 25/Aug/14  Updated: 17/Oct/14  Resolved: 26/Aug/14

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

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


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




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

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

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


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




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

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

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


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




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

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

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


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

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




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

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

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


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




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

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

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


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




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

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

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


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

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




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

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

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


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

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




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

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

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


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

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




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

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

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


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

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

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

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

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

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

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

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




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

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

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


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

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

I am thinking about something like 3 seconds for this?

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




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

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

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

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

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




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

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

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


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

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




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

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

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


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

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




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

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

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


 Description   
We should print out the following info:

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

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




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

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

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


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


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

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

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

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

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




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

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

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


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

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

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

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




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

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

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

Attachments: Zip Archive win32libevent.zip    

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

Files affected:
iofactory.c
plugin-libevent.c

New file:
NMakefile.libevent

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

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

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




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

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

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


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

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

make "DESTDIR=" clean

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

make failed, exit code 2

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


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




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

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

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


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

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

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

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




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

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

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


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




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

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

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

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

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

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

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




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

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

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


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

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

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

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




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

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

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


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

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

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

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


Thanks,

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

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


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




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

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

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


 Description   
Before 2.4.0:

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

2.4.0 and onwards

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


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

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




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

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

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


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

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

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




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

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

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


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

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

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

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




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

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

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


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

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

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

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

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

This was previously working

Please let me know if you require any further information

Cheers

Martin


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

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

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




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

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

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


 Description   
When handling network errors on view requests, lcb segfaults

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

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

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




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

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

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


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




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

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

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

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


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

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




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

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

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


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

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




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

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

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


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

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




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

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

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


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

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




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

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

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


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

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

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




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

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

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


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




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

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

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


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

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




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

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

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


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

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




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

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

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


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

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




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

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

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


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




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

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

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


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

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




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

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

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


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




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

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

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


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




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

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

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


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




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

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

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


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

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




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

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

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





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

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

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


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

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




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

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

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


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

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




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

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

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

Issue Links:
Relates to

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




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

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

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


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

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

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




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

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

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


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

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

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

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




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

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

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


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

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




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

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

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

Issue Links:
Dependency

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

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


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

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




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

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

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


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

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

It would be good if the error message was better.

get-loop.py

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

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

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




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

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

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


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

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




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

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

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


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




3.0 API Changes (CCBC-462)

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

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

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


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




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

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

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


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

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

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

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

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




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

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

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

Issue Links:
Relates to

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

Steps to reproduce:

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

Thanks in advance for your support.

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

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




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

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

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

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

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




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

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

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


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

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

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




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

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

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

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

Attachments: File minimal.c    

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

See 'minimal.c' attached

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


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


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

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


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

Observe:

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


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




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

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

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


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

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

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

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




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

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

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

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

 Description   
Keep-Alive

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

no doubt ingenthr @ 2:31

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

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

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

that sounds familiar ingenthr @ 2:32

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




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

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

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


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

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




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

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

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


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

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




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

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

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


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

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

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

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

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

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

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

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

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

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

Thanks for your great support!!




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

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

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


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

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

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

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

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




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

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

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

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

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

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

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

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

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




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

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

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


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




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

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

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


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

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




3.0 API Changes (CCBC-462)

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

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

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


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

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




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

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

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





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

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

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

Issue Links:
Gantt: start-finish
Relates to

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

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




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

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

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


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

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

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

etc, etc

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




3.0 API Changes (CCBC-462)

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

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

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


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

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

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




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

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

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


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

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

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




3.0 API Changes (CCBC-462)

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

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

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


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




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

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

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

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

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

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




3.0 API Changes (CCBC-462)

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

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

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


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




3.0 API Changes (CCBC-462)

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

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

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


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




3.0 API Changes (CCBC-462)

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

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

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


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




3.0 API Changes (CCBC-462)

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

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

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





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

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

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


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

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

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




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

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

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

Issue Links:
Dependency

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

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

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


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

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

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

Any idea of how important this is?




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

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

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


 Description   
On our current page, it has this section:

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

That's phrased a bit odd. Please fix.

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

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

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




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

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

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

Attachments: Text File package-index.txt    

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

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

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

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

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




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

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

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


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

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




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

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

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


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

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

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

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

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




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

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

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


 Description   
[EDIT] remove previous description after analysis

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

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




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

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

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





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

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

Type: Task Priority: Critical
Reporter: Brent Woodruff Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None