This document type has been added so that custom JSON libraries (like Jackson) can be used to directly insert a JSON value. It is supposed to be used like this, and can be used in combination with the other JSON documents:

// Create the RawJsonDocument with a JSON string
bucket.upsert(RawJsonDocument.create("id", "{\"hello\": true}"));

// Load the document raw again
// Prints RawJsonDocument{id='id', cas=123102208173, expiry=0, content={"hello": true}}
System.out.println(bucket.get("id", RawJsonDocument.class));

// Load the document through a JsonDocument and benefit from parsing
// Prints true
System.out.println(bucket.get("id").content().getBoolean("hello"));

When a remove() operation is executed and the CAS value is set, proper checks are now performed. Here is an example that manually modifies the CAS to simulate trying to remove an already changed one with an outdated CAS value:

// Create any document
JsonDocument created = bucket.upsert(JsonDocument.create("docid", JsonObject.create()));

// Remove it with the wrong cas value set (simulating an already changed one)
bucket.remove(JsonDocument.from(created, 132344545L));

The incorrect CAS value causes a CASMismatchException to be thrown:

Exception in thread "main" com.couchbase.client.java.error.CASMismatchException
  at com.couchbase.client.java.CouchbaseAsyncBucket$18.call(CouchbaseAsyncBucket.java:392)
  at com.couchbase.client.java.CouchbaseAsyncBucket$18.call(CouchbaseAsyncBucket.java:388)
  at rx.internal.operators.OperatorMap$1.onNext(OperatorMap.java:54)
...

The RC9 release brings additional bug fixes and stability improvements over the RC3 release that was shipped with 2.0.0 GA. We expect the Couchbase Java SDK 2.0.2 to ship with the 1.0.0 GA release shortly after its announcement.

Users reported that under certain conditions, View responses would hang the threads and application intervention was needed to bring it back to life (or a timeout kicks in). Changes were made to the application to prevent those kinds of hang-ups.

When applications were running for a longer time, exceptions would be raised during certain scenarios, leading to a death of the core engine threading. These messages were used during configuration reloading and are now properly rescheduled.

The newly added Diagnostics helper class was optionally using MXBeans from the com/sun package, but did not check whether those are available. This had the side effect of preventing start-up on JBoss Wildfly and IBM JVM type systems. Proper guards are now in place to prevent this.

Sometimes a view response gets stuck in the core. Subsequent requests have been identified to work again, so a workaround until it is fixed in the next bug-fix release is to retry after the operation times out. Make sure to apply a timeout when using the asynchronous API and maybe also use a shorter timeout than the default, which is 75 seconds for views.

A shorter timeout can be applied:

ViewResult query = bucket.query(ViewQuery.from("design", "view"), 10, TimeUnit.SECONDS);

If the asynchronous API is used, make sure to apply a timeout:

Observable<AsyncViewResult> result = bucket
    .async()
    .query(ViewQuery.from("design", "view"))
    .timeout(10, TimeUnit.SECONDS);