[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-331] memcached buckets may receive operation failures during rebalance Created: 20/Feb/14  Updated: 25/Oct/14

Status: In Progress
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.
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: 25/Oct/14  Resolved: 25/Oct/14

Status: Resolved
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: 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-353] Add couchbase cluster compatibility to documentation Created: 25/Mar/14  Updated: 25/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: Mark Nunberg
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-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-531] Document the behaviour of Arithmetic/Counter operations max/min values Created: 24/Oct/14  Updated: 25/Oct/14

Status: In Progress
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: Unresolved 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




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

Status: In Progress
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: Mark Nunberg
Resolution: Unresolved 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




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

Status: Resolved
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-527] Durability timeouts may be a bit jumpy Created: 18/Oct/14  Updated: 24/Oct/14  Resolved: 24/Oct/14

Status: Resolved
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-530] Pillowfight performance drops to near-0 during rebalance Created: 23/Oct/14  Updated: 23/Oct/14

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

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: 21/Oct/14  Resolved: 21/Oct/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: 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 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-520] Incorrect commands for installing libcouchbase on Debian/Ubuntu Created: 10/Oct/14  Updated: 20/Oct/14  Resolved: 13/Oct/14

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

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

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

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

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





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


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




Generated at Sat Oct 25 05:15:59 CDT 2014 using JIRA 5.2.4#845-sha1:c9f4cc41abe72fb236945343a1f485c2c844dac9.