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




Generated at Wed Jul 30 03:21:00 CDT 2014 using JIRA 5.2.4#845-sha1:c9f4cc41abe72fb236945343a1f485c2c844dac9.