Over a million developers have joined DZone.

Couchbase .NET Client 1.3.4 Released!

DZone's Guide to

Couchbase .NET Client 1.3.4 Released!

· Java Zone ·
Free Resource

Download the Scale-Out and High Availability whitepaper. Learn why leading enterprises choose the Couchbase NoSQL database over MongoDB™ after evaluating side by side.

This article was originally written by Jeff Morris

This release is another bug fix/stability release concentrating on improving the retry algorithm for Views and adding more refined logging to the client, along with a few other miscellaneous fixes.

Improving the consistency of View operations is important given that Couchbase is a distributed database and nodes can be leaving or entering the cluster at any time. This becomes problematic for Couchbase Clients when, for example, a specific node leaves the cluster while an operation targeting that node is in mid-flight. The question is, what to do next? We _could_ simply fail and allow the hosting application handle the error and perhaps retry the operation by its own means, but we don’t feel that is the correct approach or the type of experience that an application developer using the client would appreciate.

With 1.3.4, when a view operation fails, the client uses the HTTP status code and some heuristics to determine whether or not to retry the operation or to bubble the error message back to the application with its success value set to false. If a retry is in order, the client uses an Exponential Back-off Strategy where for each retry, the duration between retries is doubled until the hard cap is reached or the operation is successful. The first attempt is not counted, but the client pauses for each subsequent retry: 1ms, 2ms, 4ms, etc. This is ensures that the client gives the cluster time to resolve any stability issues before outright failing the operation without causing a DoS attack on the cluster.

The algorithm is tunable via the ViewRetryCount property within the configuration and defaults to 2. Note that with this setting of 2, the client will try the operation four times before giving up: the first try is not counted, then the client will try at 1ms, then 2ms, and finally at 4ms. You can chose a setting between 0 and 10; 0 will disable the retries and 10 will do its last retry at 1024ms (actually it’s the sum of time between the first attempt and the last attempt, so the total time is much longer). Note that this algorithm may change in subsequent releases.

Official release notes can be found here.

Learn how to scale enterprise applications easily, efficiently, and reliably with NoSQL. See why Couchbase beats MongoDB™ for scale-out and high availability.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}