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

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

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

Issue Links:
Relates to
relates to CCBC-409 Lacking a way to definitively determi... Open

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

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




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

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

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





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

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.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   
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-331] memcached buckets may receive operation failures during rebalance Created: 20/Feb/14  Updated: 06/Jun/14

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

Type: Task Priority: Major
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   
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.




[CCBC-324] Core dump script analyser Created: 13/Feb/14  Updated: 24/Apr/14

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

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


 Description   
Reading core dumps can be painful without access to the machine that created them.

On the server we have a script that allows a user to grab some useful information about the core dumps from memcached.

I think it would be useful to have the same thing for the library.

 Comments   
Comment by Mark Nunberg [ 24/Apr/14 ]
can you link to that script so I can possibly modify it?
Comment by Patrick Varley [ 24/Apr/14 ]
I made one of these today:

backtrace="thread apply all bt"
echo $backtrace > bt
gdb -q -batch -n -x bt /usr/bin/python --core core.2652 >BT.gdb

A link to the server one which looks a lot smarter:
https://github.com/couchbase/ep-engine/blob/master/management/cbanalyze-core

Comment by Matt Ingenthron [ 24/Apr/14 ]
On solaris, you type pstack <corefile>. And, you can do it on any machine (symbols are included). :)




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

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


 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?)




[CCBC-415] IPv6 Functionality Created: 14/May/14  Updated: 02/Jun/14

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

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


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


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

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




[CCBC-359] add feature test ensuring that E2BIG is returned on append above 20MB Created: 07/Apr/14  Updated: 07/Apr/14

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

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

Issue Links:
Dependency
depends on MB-10778 Append do not return the correct erro... Resolved

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




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

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

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

Issue Links:
Gantt: finish-start
has to be done after JCBC-438 Add table for 1.8, 2.x and 3.x compat... Open

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

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

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

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

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




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

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

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


 Description   
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




[CCBC-277] Provide pause_http_request, resume_http_request Created: 07/Oct/13  Updated: 25/Feb/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


 Description   
These functions will stop and resume the given request's activity on the event loop. It would be nice if we could implement something like this: https://twistedmatrix.com/documents/11.1.0/core/howto/producers.html#auto8




[CCBC-257] allow for setting bootstrap nodes via a configuration file, including dynamic updates Created: 27/Aug/13  Updated: 10/Jan/14

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

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


 Description   
Currently, bootstrap parameters may be supplied only via arguments to the constructor. A feature should be added to allow for URLs to be used for bootstrap to be configured via a properties file or something along those lines. This should be able to be edited, and then picked up, during a given client object's lifetime.

 Comments   
Comment by Perry Krug [ 27/Aug/13 ]
And this would need integration with the higher level languages (php/python/ruby/etc)
Comment by Sergey Avseyev [ 27/Aug/13 ]
Higher level languages have their own config systems. It isn't hard to pick any format you have in your application and initialize the instances. IMHO it isn't task of libcouchbase. We are trying to keep it simple and do not bloat with unnecessary features.

For example, you want to write command line utilities for couchbase, and you'd like to use libcouchbase to implement this task. Obviously having some rc file in home directory to configure these command line utilities will be awesome. And you must develop or integrate some solution for your particular project. We have done it for CBC, see man page cbcrc(4)
http://www.couchbase.com/autodocs/couchbase-c-client-2.1.1/cbcrc.4.html

We are building network library which will allow you to communicate you over couchbase protocols. There are better libraries for parsing configurations, I don't think we need to implement and maintain one in libcouchbase.

There is one place already, which used to keep configuration --the cluster itself, if we will bundle another one into libcouchbase, it will be be eventually out of sync with cluster configuration. And as soon as it will be our solution we will have to make it consistent and implement something which will keep it up to date
Comment by Perry Krug [ 27/Aug/13 ]
Thanks Sergey, but maybe we're not seeing the same thing here.

This bug is simply referring to the need for updating the internal list of bootstrap nodes in libcouchbase without updating the config string and restarting the application. Matt can provide more insight into the goal here.

My comment about the higher level languages was just to remind ourselves that whatever we build into libcouchbase needs a way of being controlled from those as well.
Comment by Mark Nunberg [ 10/Jan/14 ]
The idea here is to add another 'dynamic file' which would be used to contain the bootstrap nodes? I feel this would honestly be better managed by an external configuration system rather than in the library itself, as it would not be in sync with a common "properties" format for whatever HLL was wrapping LCB.
Comment by Perry Krug [ 10/Jan/14 ]
Mark, The problem we're trying to solve is the occasional need to update the "bootstrap" list of nodes without changing code or restarting the running instances of the library. Think about when the entire set of nodes of a cluster are removed and swapped with different IP's...the next time an instance starts up, it needs to get the updated list.

I don't think we're particularly tied to an extra file, but keep in mind that libcouchbase is sometimes used all by itself, so I believe it also needs to provide this facility as well as the higher level wrappers such as php/python/etc.

Does that make more sense?




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

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


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

http://review.couchbase.org/13177




[CCBC-100] Allow Incremental Row Callbacks Created: 11/Sep/12  Updated: 09/Aug/13

Status: In Progress
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: None
Fix Version/s: None
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   
View query results may return large amounts of data. We should offer a row callback which returns a JSON string whose contents is a single row.

There are awesome JSON libraries to do this task, and it's something that I've found myself doing in the Perl client.. so why not move it into libcouchbase and let everyone be happy? :).

Basic idea:
Two callbacks are put into place. The first is a 'row callback' which receives rows, and the second is a complete callback, at which time any other non-row data is returned as a JSON object.

So for example

{ "total_rows" : 30,
  "rows" : [
   { "id" : "foo" },
   { "id" : bar" },
     ....

The row callback will first receive the string '{ "id" : "foo" }', then the second time around, '{"id":"bar"}'
The complete callback will return:
' { "total_rows" : 30 } '





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





3.0 API Changes (CCBC-462)

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

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

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


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




3.0 API Changes (CCBC-462)

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




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

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

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.2.0, 2.3.2
Fix Version/s: .future
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 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




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

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

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


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

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

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




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

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


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

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

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




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




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

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

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


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




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

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

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

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

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




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

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

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


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

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

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


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






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

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

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

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

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

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

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

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




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

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

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


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

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




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

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

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


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

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

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




[CCBC-292] Documentation/blog on how to use cbc-pillowfight Created: 12/Nov/13  Updated: 25/Feb/14

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

Type: Task Priority: Minor
Reporter: Patrick Varley Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: customer, pillowfight, stats
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
There is no documentation on how to use and read the output of cbc-pillowfight.
An article explaining how to use pillowfight and cbstats timings together would be useful.

 Comments   
Comment by Matt Ingenthron [ 12/Nov/13 ]
Note that pillowfight is a subcommand to cbc, and thus it's in that man page:
http://www.couchbase.com/autodocs/couchbase-c-client-2.2.0/cbc.1.html

Agreed that the output could be better described.




[CCBC-259] libuv plugin does not track real work vs idle work. Created: 27/Aug/13  Updated: 28/Aug/13

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

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


 Description   
The libuv plugin for libcouchbase does not properly keep track of 'active work' vs 'idle work' when dispatching libuv watchers. This causes an issue where the libuv event loop will continue idling even though there is no real work to complete. This particularly affects the node.js driver as a script that no longer has any work left will never exit if a Couchbase connection is still open (even though the connection is idle).




[CCBC-129] Add libevent support for win32 Created: 20/Nov/12  Updated: 25/Feb/14

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




[CCBC-409] Lacking a way to definitively determine if a bucket exists or not Created: 08/May/14  Updated: 26/Jun/14

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

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

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

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

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




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

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




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

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

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


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




[CCBC-302] cbc verify exit code Created: 12/Dec/13  Updated: 25/Feb/14

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

Type: Bug 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


 Description   
The exit value for cbc verify is 0 even when the files differ. For example...

ingenthr-mbp:~ ingenthr$ dd if=/dev/urandom of=afile count=1024 bs=1024
1024+0 records in
1024+0 records out
1048576 bytes transferred in 0.082984 secs (12635886 bytes/sec)
ingenthr-mbp:~ ingenthr$ cbc create -f 3735928559 afile < afile
Stored "afile" CAS:cae1d52a4f000000
ingenthr-mbp:~ ingenthr$ cbc verify afile
ingenthr-mbp:~ ingenthr$ dd if=/dev/urandom of=afile count=1024 bs=1024
1024+0 records in
1024+0 records out
1048576 bytes transferred in 0.084461 secs (12414917 bytes/sec)
ingenthr-mbp:~ ingenthr$ cbc verify afile
Content differ: "afile"
ingenthr-mbp:~ ingenthr$ echo $?
0


By the way, that should be "contents differ".




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

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

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


 Description   

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





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





Generated at Mon Jul 28 08:27:45 CDT 2014 using JIRA 5.2.4#845-sha1:c9f4cc41abe72fb236945343a1f485c2c844dac9.