[JCBC-449] Add an overview to the javadoc and the CouchbaseClient class Created: 15/Apr/14  Updated: 15/Apr/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: Public

Type: Improvement Priority: Critical
Reporter: Matt Ingenthron Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The HTML generated autodocs should have a better intro and get the user to the CouchbaseClient class more directly. For instance, if you go here:
http://www.couchbase.com/autodocs/couchbase-java-client-1.4.0/index.html

One would have to click around for a bit to find what they're searching for.




[JCBC-445] 'Internal Server Error' in case of views for the latest jcbc Created: 02/Apr/14  Updated: 03/Apr/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Critical
Reporter: Deepti Dawar Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive 1.4-master_2.5.0.zip     Zip Archive 1.4-master_2.5.1.zip    
Issue Links:
Dependency
depends on MB-10743 View request may return 500 when node... Open

 Description   
Tested with the master on github i.e. 1.4-dp, reports have been shared.
Http return code 500 is being returned for the views because of which re-add and rebalance out scenarios are failing, each corresponding to the server version 2.5.0 and 2.5.1. Need to check with the server team for the 'Internal Server Error' that is being returned.




[JCBC-444] add more annotations for what is thrown from methods in CouchbaseClient Created: 27/Mar/14  Updated: 27/Mar/14

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: None
Fix Version/s: .next
Security Level: Public

Type: Improvement Priority: Critical
Reporter: Matt Ingenthron Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
At the moment, there are a number of un-checked exceptions which may be thrown and aren't well described in the javadoc annotations. It would be good to add these so developers can identify things they may want to handle.




[JCBC-441] add SSL support in support of Couchbase Server 3.0 Created: 27/Mar/14  Updated: 27/Mar/14

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: None
Fix Version/s: 2.0
Security Level: Public

Type: New Feature Priority: Critical
Reporter: Matt Ingenthron Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks MB-10084 Sub-Task: Changes required for Data E... Open

 Description   
Add support to the client library in support of SSL. Behavior should be that the client will try SSL first, unless otherwise specified.

See other specifications and details on CCBC-344




[JCBC-437] implement JSR-107 Java Temporary Caching API Created: 25/Mar/14  Updated: 25/Mar/14

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: None
Fix Version/s: .next
Security Level: Public

Type: Task Priority: Critical
Reporter: Matt Ingenthron Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
As previously discussed, we should look to implement JSR-107 to meet the standards.




[JCBC-434] update logging documentation to cover SLF4J, etc. Created: 21/Mar/14  Updated: 21/Mar/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: .next
Security Level: Public

Type: Task Priority: Critical
Reporter: Matt Ingenthron Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Current advanced usage section on logging doesn't cover SLF4J. Please add that.




[JCBC-433] Java SDK Docs: comprehensive best practices example Created: 19/Mar/14  Updated: 19/Mar/14

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.3.2
Fix Version/s: None
Security Level: Public

Type: Improvement Priority: Critical
Reporter: Perry Krug Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
As a possible improvement to our existing docs, I was thinking that a comprehensive example of Java code showing the various components and strategies that an end-user would need to be aware of and how to handle those within our best practices would be helpful.

It's along the lines of the existing tutorial, but might actually be something separate since it's more about best practices rather than actually developing to Couchbase and can be used as a reference for seeing all those best practices come together.

We certainly have a lot of this existing already, I just haven't been able to see it all in one place to point a customer to.

From a format perspective, I think it would be helpful to have the full set of code on a page with various breakpoints/callouts/even inline comments that explain the various techniques and link further into the documentation for further reading. There can be commented-out sections for "other application logic <here>" as this really just needs to highlight the best practices of working with our Java library.

At least to include:
-Singleton creation and reuse of the client object across multiple threads. with error handling around if the connection can't be established
-Using set to overwrite some data and add() to enforce uniqueness, maybe even incr() and append() examples
-Using async operations with callbacks/listeners
-Using the "AtomicInteger" to track outstanding async operations before shutting down the object
-Proper exception catching and error handling around TMP_OOM, timeouts, failed add(), failed incr/decr, etc, possibly with some exponential back-off or other way of passing feedback up the stack
-Handling of "not found" from the get()
-Bulk gets
-Example of bulk set()s (different than a single async set, if the user knows that there are many items they want to set in bulk)
-Possibly putting some error handling code within the callbacks
-Turning on of our profiling feature
-Object->JSON encoding/decoding as well as handling of writing/reading non-JSON data to CB
-more?

Obviously there's a lot to put in here but I would also think that it doesn't need to be an all-or-nothing but can start with some simple pieces and be built upon. Certainly as we add more functionality or different ways of doing things this doc will have to be extended anyway.




[JCBC-430] Situational Test Java CCCP upgrade : Results are showing auth issues causing latency with the java client. Created: 18/Mar/14  Updated: 18/Mar/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Critical
Reporter: Deepti Dawar Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency

 Description   
Description of specific scenarios is available in the respective SDKQE JIRA tasks.




[JCBC-413] Race condition in cluster manager class Created: 11/Feb/14  Updated: 15/Apr/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 1.4.1
Security Level: Public

Type: Bug Priority: Critical
Reporter: Juan Manuel Musacchio Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
I've been experiencing some connection issues ("Unable to connecto to cluster") while listing the couchbase buckets. After some debugging I realized that could be a race condition in the ClusterManager sendRequest method. The following are the involved lines (took it from master branch):

latch.countDown(); //line 474
success.set(true); //line 475
response.set(result); //line 476

The thing is that the mutex is decreased before setting sucess and response values, so later the code will check the success variable and could fail if success is not set before the thread starts (mutex is 0). I think the code should be:

success.set(true);
response.set(result);
latch.countDown();




[JCBC-405] Allow custom server ports in the test suite (was: apache http library throws 'badurl' error while running Java SDK ant test against cluster on non-default port.) Created: 23/Jan/14  Updated: 15/Apr/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 1.4.1
Security Level: Public

Type: Improvement Priority: Critical
Reporter: Venu Uppalapati Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: CentOS 6.4 64-bit
RAM:256GB
Dual 2.9GHz 8-core Xeon E5-2690 for 32 total cores (16 + hyperthreading)


 Description   
This is part of multi-instance testing for customer 'A'.

Steps to reproduce:
1)Setup a 3 instances per physical machine. configure a cluster of 5 such instances. The instances are modified to run on non-default ports by modifying static config file. for example:
{rest_port,9000}.
{mccouch_port,9001}.
{memcached_port,12000}.
{memcached_dedicated_port,12001}.
{moxi_port,12002}.
{short_name,"ns11"}.
{ssl_rest_port,11000}.
{ssl_capi_port,11001}.
{ssl_proxy_downstream_port,11002}.
{ssl_proxy_upstream_port,11003}.

2)clone java SDK project. change the server ip address and server port number(internal memcached port) in the build.xml file to reflect the server address and non-default internal memcached port (12001 in this case).
example:sysproperty key="server.address_v6" value="${server.address_v6}"/>
            <sysproperty key="server.port_number" value="12001"/>

3) the junit tests in the Java SDK contain hardcoded REST port, so modify all of them to non-default REST port:
find . -name "*.java" -print0 | xargs -0 sed -i '' -e 's/8091/9000/g'

4)Run 'ant test'. the ClusterManager tests fail with following apache http library error. the library methods are called from ClusterManager.java

2014-01-23 16:35:03.786 WARN com.couchbase.client.ClusterManager: Cluster Response failed with:
    [junit] java.net.UnknownHostException: badurl
    [junit] at org.apache.http.impl.nio.reactor.DefaultConnectingIOReactor.validateAddress(DefaultConnectingIOReactor.java:245)
    [junit] at org.apache.http.impl.nio.reactor.DefaultConnectingIOReactor.processSessionRequests(DefaultConnectingIOReactor.java:265)
    [junit] at org.apache.http.impl.nio.reactor.DefaultConnectingIOReactor.processEvents(DefaultConnectingIOReactor.java:141)
    [junit] at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor.execute(AbstractMultiworkerIOReactor.java:348)
    [junit] at com.couchbase.client.ClusterManager$2.run(ClusterManager.java:589)
    [junit] at java.lang.Thread.run(Thread.java:695)


 Comments   
Comment by Michael Nitschinger [ 23/Jan/14 ]
Alright, this will need some larger changes in the test suite, we didn't anticipate this back in the days.

Which ports do you need to have changed?
Comment by Venu Uppalapati [ 23/Jan/14 ]
All of the ports listed in step 1 of description need to be changed per instance.




[JCBC-401] Durability .get() with a custom Timeout higher than the default is ignored Created: 14/Jan/14  Updated: 15/Apr/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 1.3.0, 1.3.1
Fix Version/s: 1.4.1
Security Level: Public

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





[JCBC-342] TAP Client streams should be reconfigure-aware (reestablish streams) Created: 06/Aug/13  Updated: 06/Sep/13

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: .next
Security Level: Public

Type: Improvement Priority: Critical
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates to
relates to JCBC-340 Tap client should only connect to act... Closed




[JCBC-341] TapClient should tap only vbuckets on nodes to avoid duplicate network traffic. Created: 06/Aug/13  Updated: 06/Sep/13

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: .next
Security Level: Public

Type: Improvement Priority: Critical
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates to
relates to JCBC-340 Tap client should only connect to act... Closed




[JCBC-269] subsequent resubscribers should not run if a resubscriber is successful Created: 13/Mar/13  Updated: 06/Sep/13

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1.2
Fix Version/s: .next
Security Level: Public

Type: Bug Priority: Critical
Reporter: Matt Ingenthron Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
When investigating a case recently, I noticed many resubscribers running once a second. Looking at the code, it appears the kind of threadpool being used would just queue more and more up, but only run one at a time.

The subsequent resubscribers should exit immediately if resubscribe is no longer needed. Or the threadpool could be changed so we can't queue another while one is running.




[JCBC-258] documentation needs to be much clearer about Query.setKey() requiring JSON encoded strings or use of ComplexKey Created: 06/Mar/13  Updated: 06/Sep/13

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.1.3
Fix Version/s: .next
Security Level: Public

Type: Improvement Priority: Critical
Reporter: Matt Ingenthron Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Neither the javadoc nor the existing documentation really cover the potential issues with setKey using a number or something that will autobox into a string value. This should be much clearer.




[JCBC-89] re-enable optimization after error handling in binary optimized sets is fixed in dependent spymemcached Created: 31/Jul/12  Updated: 19/Jul/13

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: None
Fix Version/s: .next
Security Level: Public

Type: Bug Priority: Critical
Reporter: Matt Ingenthron Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Matt Ingenthron [ 17/Dec/12 ]
I do think this one needs to be addressed before 1.2.




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

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.3.2, 1.4.0-dp1
Fix Version/s: None
Security Level: Public

Type: Improvement Priority: Major
Reporter: Matt Ingenthron Assignee: Michael Nitschinger
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.




[JCBC-443] javadoc on OperationStatus.success() could be more clear Created: 27/Mar/14  Updated: 27/Mar/14

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: None
Fix Version/s: .next
Security Level: Public

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


 Description   
The javadoc for OperationStatus.isSuccess() is rather confusing: "Does this status indicate success?"




[JCBC-440] Inconsistent result of paginated query. Created: 26/Mar/14  Updated: 26/Mar/14

Status: Open
Project: Couchbase Java Client
Component/s: Core, Views
Affects Version/s: 1.3.2
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Major
Reporter: Vladislav Koroteev Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Red Hat Enterprise Linux Server release 6.3 (Santiago)
Java 7
Couchbase Server Community Edition 2.2.0


 Description   
I get a strange behavior with paginated query. While I paginate on the result set, I get duplicates of some documents. I'm doing the following in my code:

// force start indexing of view
query.setStale(Stale.FALSE);
query.setReduce(true);
ViewResponse respFromReduce = client.query(view, query);
String expectedCountFromScroll = null;
for (ViewRow viewRow : respFromReduce) {
    expectedCountFromScroll = viewRow.getValue();
}
query.setReduce(false);
query.setIncludeDocs(false);
//disable indexing of view from sdk
query.setStale(Stale.OK);
Paginator scroll = client.paginatedQuery(view, query, SCROLL_SIZE);
int docsFromScrollCnt = 0;
while (scroll.hasNext()) {
    ViewResponse response = scroll.next();
    docsFromScrollCnt += response.size();
}

And I see, that docsFromScrollCnt > expectedCountFromScroll.
I think, that while query Couchbase auto-indexing view, so I decide to disable auto-indexing by set viewUpdateDeamon's parameters. I set updateInterval to value, that greater then querying time, updateMinChanges and replicaUpdateMinChanges to zero.

It's not helped, but I noticed following interesting feature. Count of duplicate documents always equals n*SCROLL_SIZE.

How can I avoid duplicate of document from paginated query?

- See more at: http://www.couchbase.com/communities/q-and-a/strange-behavior-paginated-query#sthash.MLFf15Gx.dpuf




[JCBC-438] Add table for 1.8, 2.x and 3.x compatibility Created: 25/Mar/14  Updated: 25/Mar/14

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: .next
Fix Version/s: None
Security Level: Public

Type: Improvement Priority: Major
Reporter: Matt Ingenthron Assignee: Michael Nitschinger
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 before CCBC-353 Add couchbase cluster compatibility t... Open
has to be done before JSCBC-102 Add couchbase cluster compatibility t... Open
has to be done before NCBC-423 Add couchbase cluster compatibility t... Open
has to be done before PCBC-270 Add couchbase cluster compatibility t... Open
has to be done before PYCBC-238 Add couchbase cluster compatibility t... Open
has to be done before RCBC-167 Add couchbase cluster compatibility t... Open

 Description   
Please specify the info to go into the table and pass this to Amy who will add it to the SDK docs in appropirate formatting.

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.




[JCBC-435] update README info on maven repos Created: 21/Mar/14  Updated: 21/Mar/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: Public

Type: Task Priority: Major
Reporter: Matt Ingenthron Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
I happened to look at the README earlier and it still has old maven repository info.




[JCBC-429] Possible race condition with add() multiple times on the same key Created: 14/Mar/14  Updated: 18/Mar/14

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.3.2
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Major
Reporter: Michael Nitschinger Assignee: Jasdeep Jaitla
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Gantt: start-finish

 Description   
public class CouchbaseAddTest {

    private ExecutorService pool;

    public static void main(String[] args) {
        new CouchbaseAddTest().run();
    }
    
    public void run() {
        // create a pool of 4 threads
        pool = Executors.newFixedThreadPool(4);
        
        // create 4 writers to run in parallel
        List<Future> fs = new ArrayList<Future>(4);
        for (int i=0; i<4; i++) {
                fs.add(pool.submit(new Writer(i+1)));
        }
        
        for (Future f : fs) {
            try {
                f.get();
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
        pool.shutdown();
    }
    
    private class Writer implements Runnable {
        private int id;
        private Gson gson;

        public Writer(int id) {
            this.id = id;
            gson = new Gson();
        }
        
        @Override
        public void run() {
            try {
                // Connect to the Cluster
                CouchbaseClient client = getClient();
                
                for (int i=0; i<1; i++) {
                    addDoc(client, i);

                    try {
                        Thread.sleep(200);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                }
               
                // Shutting down client
                client.shutdown();
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
        
        private CouchbaseClient getClient() throws IOException, URISyntaxException {
            
            CouchbaseConnectionFactoryBuilder builder = new CouchbaseConnectionFactoryBuilder();
            builder.setReadBufferSize(16384); //16384
            builder.setOpTimeout(60000); //60000
            builder.setFailureMode(FailureMode.Redistribute);
            builder. setOpQueueMaxBlockTime(5000); // add extra
            
            List<URI> couchServers = Arrays.asList(
                    new URI("http://server1:8091/pools"),
                    new URI("http://server2:8091/pools"),
                    new URI("http://server3:8091/pools"),
                    new URI("http://server4:8091/pools")
            );

            CouchbaseConnectionFactory connectionFactory =
                    builder.buildCouchbaseConnection(couchServers,
                            "usage", "", "");

            return new com.couchbase.client.CouchbaseClient(connectionFactory);
        }
        
        private void addDoc(CouchbaseClient client, int n) {
            Doc doc = null;
            String value = null;

            String key = String.format("dc1-daily-%d", n);
            if (get(client, key)==null) {
                doc = new Doc();
                value = gson.toJson(doc);
                add(client, key, value);
            }
            
            key = String.format("daily-%d", n);
            if (get(client, key)==null) {
                doc = new Doc();
                value = gson.toJson(doc);
                add(client, key, value);
            }
        }
        
        private Object get(CouchbaseClient client, String key) {
            return client.gets(key);
        }
        
        private void add(CouchbaseClient client, String key, String value) {
            
            OperationFuture f = client.add(key, value);
            OperationStatus status = null;
            try {
                status = f.getStatus();
            } catch (Exception e) {
                e.printStackTrace();
            }
            if (status!=null && status.isSuccess()) {
                System.out.println(String.format("%d Writer %d - Added %s", System.currentTimeMillis(), id, key));
            } else {
                System.out.println(String.format("%d Writer %d - Add failed %s", System.currentTimeMillis(), id, key));
            }

        }
    }
    
    private static class Doc {
        
        public String[] s = {
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890"
        };
    }
}



In some environments, this leads to duplicate adds being reported:

1393524003358 Writer 3 - Added dc1-daily-0
1393524003360 Writer 4 - Added dc1-daily-0
1393524003363 Writer 4 - Added daily-0
1393524003363 Writer 3 - Added daily-0
1393524003367 Writer 2 - Added dc1-daily-0
1393524003368 Writer 1 - Add failed dc1-daily-0
1393524003370 Writer 2 - Added daily-0
  

instead of the correct

1393524753507 Writer 1 - Added dc1-daily-0
1393524753507 Writer 2 - Add failed dc1-daily-0
1393524753507 Writer 4 - Add failed dc1-daily-0
1393524753507 Writer 3 - Add failed dc1-daily-0
1393524753510 Writer 2 - Added daily-0
1393524753510 Writer 4 - Add failed daily-0
1393524753510 Writer 1 - Add failed daily-0
1393524753511 Writer 3 - Add failed daily-0


reproduction was not yet successful

 Comments   
Comment by Matt Ingenthron [ 17/Mar/14 ]
I also tried to reproduce this, to no avail. One suspicion (originally raised by Michael) is perhaps the nodes being used for bootstrap aren't clustered or there is something unhealthy in the cluster?

It would be great to get a debug level log which will probably point to the issue. See http://docs.couchbase.com/couchbase-sdk-java-1.3/#configuring-logging for information on setting up logging.




[JCBC-425] document profiling capabilties Created: 04/Mar/14  Updated: 04/Mar/14

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.3.0, 1.3.2
Fix Version/s: .next
Security Level: Public

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


 Description   
The profiling added in 1.2 has not been documented. We should add a section for that. It doesn't even seem to be in the release notes. I found it on Michael's blog, but it should be in the documentation too.




[JCBC-424] investigate adding a ping or other check to idle connections Created: 02/Mar/14  Updated: 02/Mar/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Major
Reporter: Matt Ingenthron Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
There have been a couple of reports of idle TCP connections causing operation failures. The underlying cause seems to be that some of these environments terminate seemingly idle TCP connections.

There are probably two solutions.
1) Don't let them go idle. On some existing thread or maybe with some kind of timer, do a version() operation or such regularly.
2) If it's possibly idle, send a ping before trying to send an op.

Of course, a 3rd solution is to automatically retry idempotent operations.




[JCBC-422] add discussion of timeout accuracy and implementation to documentation Created: 27/Feb/14  Updated: 27/Feb/14

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: None
Fix Version/s: .next
Security Level: Public

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


 Description   
Since our timeouts are only as accurate as the underlying APIs/subsystems we use, we should document this for our users so they can plan accordingly. For instance, if processes aren't scheduled for a long period of time owing to CPU or memory contention... or in some cases IO doesn't happen for a long time and our timeout is IO event driven, we may not timeout to the application until later.





[JCBC-416] Client throws exception "Cannot cache data larger than 20971520 bytes" when receiving uncompressed document from server Created: 17/Feb/14  Updated: 17/Feb/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Major
Reporter: Venu Uppalapati Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Steps to reproduce:
1) generate a 30MB document. compress the document, in my case the compressed size is ~15MB.
2) using a 3.0 client, send this compressed doc with datatype 0x02 to the server. server stores this as is.
3) using a 2.x client, request a GET for this document. The server uncompresses the doc since the request if from 2.x client that is not flex metadata aware and sends the raw doc to client.
4) client throws following exception and connection resets..java.lang.IllegalArgumentException: Cannot cache data larger than 20971520 bytes (you tried to cache a 31211520 byte object)
5) we should release appropriate hot patch or workaround information on how to handle this scenario from 2.x clients.




[JCBC-409] clarify behavior or *getFromReplica in javadoc Created: 03/Feb/14  Updated: 03/Feb/14

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.3.0, 1.3.1
Fix Version/s: None
Security Level: Public

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


 Description   
I've seen questions a few times on how replica read behaves w.r.t. multiple replicas and recovery of the active location.

IIRC, the getFromReplica() will give you the first responder and the asyncGetFromReplica() will give you a future which has all the responses? The javadoc doesn't indicate this though, so it'd be great if we can clarify.




[JCBC-408] javadoc for ComplexKey class formatted incorrectly Created: 02/Feb/14  Updated: 15/Apr/14

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.3.1
Fix Version/s: 1.4.1
Security Level: Public

Type: Bug Priority: Major
Reporter: Matt Ingenthron Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Some of the code examples in the javadoc are not formatted correctly.

See:
http://www.couchbase.com/autodocs/couchbase-java-client-1.3.1/com/couchbase/client/protocol/views/ComplexKey.html




[JCBC-407] Add Utility to load bootstrap URIs from DNS SRV Created: 29/Jan/14  Updated: 15/Apr/14

Status: In Progress
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 1.4.1
Security Level: Public

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





[JCBC-406] create release notes for 1.4.0 release Created: 28/Jan/14  Updated: 28/Jan/14

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: None
Fix Version/s: .next
Security Level: Public

Type: Task Priority: Major
Reporter: Matt Ingenthron Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
If documentation changes are small or none, plan is to supply Amy the release notes markdown and she'll handle the creation of the new doc set for 1.4.0.

Please attach it here and assign to Amy when complete.




[JCBC-404] Views created via with carriage returns are not executable via web admin Created: 23/Jan/14  Updated: 23/Jan/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Major
Reporter: Brad Wood Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
When looking at a view created via the Java SDK in the web admin, the "Show Results" button is greyed out when the map or reduce function contain a carriage return. The view can be executed via the SDK as well as the REST interface, but the "Show Results" button is disabled.

This was reported in the forums over a year ago:
http://www.couchbase.com/forums/thread/design-docs-views-created-rest-api-dont-work-show-results-grayed-out-404-error-client

I can't find a ticket for it and it doesn't appear to be resolved.

As a work around, I am manually replacing carriage returns (CFML code)
{code}
/**
* Normalize view functions to not have any carridge returns.
* The presence of ASCII code 13 in map or reduce functions will prevent you from
* being able to execute them from the Couchbase web admin.
* @viewFunction.hint The function string to normalize
*/
string function normalizeViewFunction( required string viewFunction ) {
var CR = chr(13);
var LF = chr(10);
var CRLF = CR & LF;
var CRLFPlaceholder = '__CRLF__';

// I'm doing this in two steps since if I just remove CR's that have no LF, that would completely remove line breaks and cause syntax issues
// but if I just replaced all CR's with LF's that would double all line breaks. Therefore, all CR's and CRLF's will be converted to an LF.
// Standalone LF's won't be touched.

// Set CRLF's aside for a moment
arguments.viewFunction = replace(arguments.viewFunction,CRLF,CRLFPlaceholder,'all');
// Replace single CR's with LF's
arguments.viewFunction = replace(arguments.viewFunction,CR,LF,'all');
// Put the CRLF's back as just LF's
arguments.viewFunction = replace(arguments.viewFunction,CRLFPlaceholder,LF,'all');

return arguments.viewFunction;
}
{code}


 Comments   
Comment by Brad Wood [ 23/Jan/14 ]
Ugh, you don't have Wiki markup enabled in JIRA. Please do so, it makes things so much prettier. I can't edit my ticket either to remove the unused "code" markup.
Comment by Michael Nitschinger [ 23/Jan/14 ]
Hi Brad,

do you mean that when you create view through the java SDK which has a CR in its name (design doc, view name?) it can't be used from the web UI, but otherwise works fine?

Either this is not allowed then we should check it or it is a bug on the server side.
Comment by Brad Wood [ 23/Jan/14 ]
No, the carriage returns are not in the name of the view or the design document-- they are in the map or reduce functions.

For instance, I might create a view with the CFML SDK (which proxies to the Java SDK) with the following code:

couchbase.saveView(
'beer',
'listBeersByBrewery',
'function (doc, meta) {
if ( doc.type == ''beer'' ) {
emit(doc.brewery_id, null);
}
}',
'_count'
);

Since I am on Windows, each line ending in the map function is a carriage return followed by a line feed. The view will create and will be executable via the SDK and via the REST interface, but not via the web admin. After I modified the CFML SDK to strip out ASCII code 13 from the map and reduce functions, they work as expected.




[JCBC-402] Do you plan to add the java bindings for incr multi ? Created: 15/Jan/14  Updated: 15/Jan/14

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.3.1
Fix Version/s: None
Security Level: Public

Type: Improvement Priority: Major
Reporter: loolek Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: usability
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: linux


 Description   
I can't find any similar in the Java API to incrMulti() or incrBulk() or asyncIncrBulk() bindings!

We need this feature heavily and I sadly see the other drivers already have it ->

Perl: Multi version of "arithmetic"

incr_multi(@keys)
decr_multi(@keys)
incr_multi( [key, amount], ... )
decr_multi( [key, amount], ... )

JavaScript: Now changed to arithmeticMulti()

http://review.couchbase.org/#/c/30792/


Cheers,

--

​"No trees were destroyed in the sending of this message.
However, a large number of electrons were terribly inconvenienced."




[JCBC-398] Extend CAS and asyncCAS operations to return new CAS value Created: 07/Jan/14  Updated: 15/Apr/14

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.2.3
Fix Version/s: 1.4.1
Security Level: Public

Type: New Feature Priority: Major
Reporter: Perry Krug Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The purpose being to prevent having to make a second get request if the CAS value is needed after the CAS operation.

 Comments   
Comment by loolek [ 15/Jan/14 ]
We need this feature too!
Comment by Michael Nitschinger [ 20/Feb/14 ]
Looking into it for 1.4, let's see.




[JCBC-395] Specify specific generated version in headers Created: 31/Dec/13  Updated: 31/Dec/13

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Currently we hardcode the user client string in http requests, this can be made better and more specific, based on a generated class file and constants.




[JCBC-384] couchbase java libs should use log4j or slf4j not JUL Created: 11/Sep/13  Updated: 28/Nov/13

Status: Open
Project: Couchbase Java Client
Component/s: Dependencies
Affects Version/s: None
Fix Version/s: 2.0
Security Level: Public

Type: Bug Priority: Major
Reporter: Timothy Ehlers Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 2
Labels: usability
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
log4j has more appends and is widely used, it is also more enterprise friendly thanks to the SocketAppender.

 Comments   
Comment by Timothy Ehlers [ 11/Sep/13 ]
A dependency you pull in uses log4j

net/spy/memcached/compat/log/Log4JLogger.java:import org.apache.log4j.Logger;

Then the couchbase lib uses JUL, this seems counter production
com/couchbase/client/CouchbaseClient.java:import java.util.logging.Logger;
Comment by Matt Ingenthron [ 27/Nov/13 ]
Note that we manage/maintain the net.spy.memcached project as well.

We have support for SLF4J, Log4J, and JUL. Because of how things are packaged, all dependencies are described via maven, but they're not all pulled in.
Comment by Matt Ingenthron [ 27/Nov/13 ]
Michael: do you think we can make our packaging better in the 2.0 client?
Comment by Michael Nitschinger [ 28/Nov/13 ]
That's right since 1.2 you can use slf4j. 2.0 will be slf4j only like most other projects out there, only shipping with the binding and you plug in your own impl.




[JCBC-377] Getting sdk error - 'Connection reconfiguration failed' while running situational tests Created: 11/Nov/13  Updated: 11/Nov/13

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 1.2.2
Fix Version/s: .next
Security Level: Public

Type: Bug Priority: Major
Reporter: Deepti Dawar Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: ec2 centos machines


 Description   
Following is the exception in the situational test logs shared at - https://docs.google.com/a/globallogic.com/spreadsheet/ccc?key=0AmLvaJ8oRZ-TdGRQUllQSWVpV0Q3WGwxOERsOFcwMnc&usp=sharing#gid=0

SEVERE: Connection reconfiguration failed
SDKD: java.nio.channels.ClosedByInterruptException
SDKD: at java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:202)
SDKD: at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:634)
SDKD: at net.spy.memcached.MemcachedConnection.createConnections(MemcachedConnection.java:225)
SDKD: at com.couchbase.client.CouchbaseConnection.reconfigure(CouchbaseConnection.java:131)
SDKD: at com.couchbase.client.CouchbaseClient.reconfigure(CouchbaseClient.java:283)
SDKD: at com.couchbase.client.vbucket.ReconfigurableObserver.update(ReconfigurableObserver.java:54)
SDKD: at java.util.Observable.notifyObservers(Observable.java:159)
SDKD: at com.couchbase.client.vbucket.BucketMonitor.replaceConfig(BucketMonitor.java:310)
SDKD: at com.couchbase.client.vbucket.BucketUpdateResponseHandler.messageReceived(BucketUpdateResponseHandler.java:81)
SDKD: at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:75)
SDKD: at com.couchbase.client.vbucket.BucketUpdateResponseHandler.handleUpstream(BucketUpdateResponseHandler.java:202)
SDKD: at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:565)
SDKD: at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:793)
SDKD: at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296)
SDKD: at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:455)
SDKD: at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:538)
SDKD: at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingDecoder.java:487)
SDKD: at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:75)
SDKD: at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:565)
SDKD: at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:560)
SDKD: at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
SDKD: at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
SDKD: at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:94)
SDKD: at org.jboss.netty.channel.socket.nio.AbstractNioWorker.processSelectedKeys(AbstractNioWorker.java:390)
SDKD: at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:261)
SDKD: at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:35)
SDKD: at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:102)
SDKD: at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
SDKD: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
SDKD: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
SDKD: at java.lang.Thread.run(Thread.java:722)




[JCBC-359] not all methods are documented on CouchbaseConnectionFactoryBuilder Created: 03/Sep/13  Updated: 15/Apr/14

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.1.9
Fix Version/s: 1.4.1
Security Level: Public

Type: Bug Priority: Major
Reporter: Matt Ingenthron Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Just happened to notice several methods aren't documented or don't have docs punching through from the superclass.

http://www.couchbase.com/autodocs/couchbase-java-client-1.1.9/com/couchbase/client/CouchbaseConnectionFactoryBuilder.html




[JCBC-356] NPE when sending null transcoder Created: 27/Aug/13  Updated: 06/Sep/13

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1.9
Fix Version/s: .next
Security Level: Public

Type: Bug Priority: Major
Reporter: Perry Krug Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Not blocking anyone, but the library could be more resilient by properly handling a null transcoder instead of throwing the following exception:

Aug 27 09:40:07: INFO: Reconnecting due to exception on {QA sa=localhost/127.0.0.1:11210, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: -108 Opaque: 41 Key: 10 Exp: 10, topWop=null, toWrite=0, interested=1}
Aug 27 09:40:07: java.lang.NullPointerException
Aug 27 09:40:07: at com.couchbase.client.CouchbaseClient$9.gotData(CouchbaseClient.java:953)
Aug 27 09:40:07: at net.spy.memcached.protocol.binary.GetlOperationImpl.decodePayload(GetlOperationImpl.java:59)
Aug 27 09:40:07: at net.spy.memcached.protocol.binary.OperationImpl.finishedPayload(OperationImpl.java:178)
Aug 27 09:40:07: at net.spy.memcached.protocol.binary.OperationImpl.readFromBuffer(OperationImpl.java:162)
Aug 27 09:40:07: at net.spy.memcached.protocol.binary.GetlOperationImpl.readFromBuffer(GetlOperationImpl.java:31)
Aug 27 09:40:07: at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:563)
Aug 27 09:40:07: at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:480)
Aug 27 09:40:07: at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:261)
Aug 27 09:40:07: at com.couchbase.client.CouchbaseConnection.run(CouchbaseConnection.java:288)

 Comments   
Comment by Michael Nitschinger [ 27/Aug/13 ]
what do you think is appropriate? The only thing that comes to my mind is checking for every command and throw a InvalidArgumentException?
Comment by Perry Krug [ 27/Aug/13 ]
I'm not sure what the right approach is (surely Matt can) but the customer indicated that an NPE was always something we shouldn't see




[JCBC-328] create tuneable for compressing JSON Created: 08/Jul/13  Updated: 06/Sep/13

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: None
Fix Version/s: .next
Security Level: Public

Type: Improvement Priority: Major
Reporter: Matt Ingenthron Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Currently, the compression of JSON or not is all the way down in spymemcached and hardcoded. This was probably intended to be tuneable and should be fixed up. For right now, if someone wants to compress their JSON, they have to implement an entire transcoder.

https://gist.github.com/ingenthr/5952891




[JCBC-316] noop on connect optional behavior needs to be documented Created: 10/Jun/13  Updated: 06/Sep/13

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.1.7
Fix Version/s: .next
Security Level: Public

Type: Bug Priority: Major
Reporter: Matt Ingenthron Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
One thing which needs to be better documented is how to enable the NOOP check on connect.

This should be done before 1.1.8, since it's part of the 1.1.7 ship.




[JCBC-310] Create a getBulk() operation that returns CASValue object Created: 23/May/13  Updated: 13/Jan/14

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1.6
Fix Version/s: .next
Security Level: Public

Type: New Feature Priority: Major
Reporter: Tug Grall (Inactive) Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The current client.getBulk(keys) returns the values only,

It would be useful to create an operation that returns the list of CASValue to allow developer to do CAS operations.

This should also be supported by the views when doing a "includeDocs" operation

 Comments   
Comment by Mladen Markov [ 31/Oct/13 ]
I also need this badly, for performance reasons.

Right now I'm looping through hundreds of documents per second, getting their CAS value one by one. I'm looking to do more bulk operations to save excessive round-trips to Couchbase. I see that net.spy.memcached.MemcachedClient does not have getsBulk() or asyncGetsBulk() methods, although the memcached protocol supports it.

So I'm not sure if this should be a feature request to Java Memcached Client or to Couchbase Java Client.
In any case, I would very much like to up-vote it.

Cheers
Mladen
Comment by mshaw [ 06/Jan/14 ]
I'm surprised that this is a minor issue. Same problem as Mladen, we require excessive round trips since this is the only way to ensure proper updates on bulk docs.
Comment by Michael Nitschinger [ 07/Jan/14 ]
Hi folks,

a bulk operation is nothing more than syntactic sugar on top of the regular get api, so looping does not get you more roundtrips or whatever. Can you give me a specific use case where you think bulking will help you to improve performance?

Also, mshaw, why do you think you'll have more network roundtrips because of looping?
Comment by Perry Krug [ 07/Jan/14 ]
Heard this request from another customer.

I agree that returning the CASvalue through a getBulk is a bit of syntactic sugar, but it's not intuitive to the user that they should have to do the async gets themselves and it should be easy enough to build that into getBulk right?

This also applies to include_docs via a view request where the user is actually forced to do a second round of gets (or again, implement it themselves manually)
Comment by mshaw [ 07/Jan/14 ]
Michael, I should have been more clear. It may be that it really is just a convenient API, but I was under the impression that the SDK is actually optimized for the bulk operations when compared to looping yourself.

By excessive I'm thinking of a scenario where we use a getBulk() which has no cas values. We then need to update some of those items so we need to get the updatable items again with the gets(), then apply the updates and save using the cas since there can be multiple writes to the file. We are using getBulk() because the Couchbase docs recommendation state it is more efficient than looping the calls. It seems that the only option around the above work around is to loop gets calls for all our items that may need updating, causing are calls at the very least to be inefficient according to Couchbase docs.
Comment by Matt Ingenthron [ 07/Jan/14 ]
One quick comment from a historical sense... I believe the getBulk() and thus it's API has been around longer than the CAS value has. This is legacy from spymemcached and the memcached protocol.

On the note about doing a loop versus a getBulk(), with the current code if you do a series of async gets(), it's going to be exactly the same as getBulk(). The internals of getBulk() perform the same logic. In fact, it's arguably faster if you're using the Futures directly, since you don't have to wait until they all arrive, You just block when the data is needed.

We should address that in the documentation.
Comment by mshaw [ 07/Jan/14 ]
Ok interesting thanks for that added info. I have seen getBulk() mentioned in webinars as the recommended way to get multiple records as well.
Comment by Matt Ingenthron [ 07/Jan/14 ]
For many clients, that will be the most efficient route which is why they say that in general introductions. Mostly it's described along with views, where you'll have a query and then multi-get the underlying docs. Java is a bit more advanced of a client with it's asynch capabilities, so it is a little different in this regard.
Comment by Mladen Markov [ 13/Jan/14 ]
Guys, correct me if I'm wrong but the memcached protocol supports bulk gets - getting CAS values for multiple keys with one call.
See the "gets <key>*" command at https://github.com/memcached/memcached/blob/master/doc/protocol.txt

Is one "gets 1000 keys" call not going to be way faster than 1000 (async) "get 1 key" calls?
Comment by Perry Krug [ 13/Jan/14 ]
Mladen, that part of the protocol only applies to asking for 1000 keys from the same node. In Couchbase-land, it's very likely that that set of 1000 keys actually comes from multiple nodes, in which case you need to make separate calls (at least one for each server). The Java client automatically does this for you and is just as fast as the single "get 1000 keys" call.




[JCBC-303] javadoc builds must include spymemcached Created: 14/May/13  Updated: 19/Jul/13

Status: In Progress
Project: Couchbase Java Client
Component/s: Infrastructure
Affects Version/s: 1.1.6
Fix Version/s: .next
Security Level: Public

Type: Bug Priority: Major
Reporter: Phil Labee Assignee: Phil Labee
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates JCBC-293 Clarification/Agreement on Javadocs B... Resolved

 Description   
Current javadoc build process does not include the spymemcached docs, which were included in previous releases. The documentation:

    http://hub.internal.couchbase.com/confluence/display/techpubs/Using+Existing+Docs+System+%28WIP%29

does not mention how to include, nor is there evidence of how it was done before.


Need to have:

* a process that includes correct third-party documentation, when required.

* one that is not tied to a particular host

* is fully documented

 Comments   
Comment by Phil Labee [ 15/May/13 ]
I modified the couchbase-java-client/build.xml file to also use the source files under

    ../spymemcached/src/main/java/

for generating javadocs, but I'm getting errors:

    package org.apache.log4j does not exist
    package org.springframework.beans.factory does not exist
    
so it looks like a classpath issue.
Comment by Michael Nitschinger [ 15/May/13 ]
Hi Phil,

normally log4j and spring beans are configured as "provided", so you should not need them during runtime in spy. maybe just run "ant jar" once in the directory so it fetches the dependencies in the right directories?
Comment by Phil Labee [ 29/May/13 ]
commit 0b2ddd7de1e963f1ad3e4817ee55c5ef7bc70901 adds to "docsjar" target to include spymemcached in docs jarfile

Requires spymemcached repo clones to workspace as peer to couchbase-java-client (or modify the extern.root property).
Comment by Phil Labee [ 29/May/13 ]
The generated ZIP file doesn't work right. It contains the docs from both projects, but I need to collate the package list files so that they appear together. Right now there are two copies of the top level html file (e.g. allclasses-frame.html) so depending on whether you answer yes or no to overwrite when unzipping, you get either the couchbase or the spymemcached files displayed.

Next step is to build the zip file with the proper index files.
Comment by Matt Ingenthron [ 29/May/13 ]
Phil: the idea is to use the javadoc command once using both projects as input, and then javadoc will build the appropriate indexes. Something like:

javadoc /path/to/couchbase-client/* /path/to/spymemcached/*
Comment by Michael Nitschinger [ 19/Jul/13 ]
Phil,

is the process finished and automated by now?




[JCBC-301] Strange Logic in CouchbaseClient observePoll method Created: 09/May/13  Updated: 06/Sep/13

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: .next
Fix Version/s: .next
Security Level: Public

Type: Bug Priority: Major
Reporter: Henri Chen Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
At CouchbaseClient.java line 2192 and line 2196

They both call

replicaPersistedTo++;

it means when r.getValue() == ObserveResponse.NOT_FOUND_PERSISTED) && !isMaster, replicaPersistedTo will be called twice.

Is that intensional. Looks odd to me.

 Comments   
Comment by Henri Chen [ 09/May/13 ]
BTW, The code is based on Github master.




[JCBC-296] Document changing compression threshold Created: 06/May/13  Updated: 06/Sep/13

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.1.5
Fix Version/s: .next
Security Level: Public

Type: Bug Priority: Major
Reporter: Mike Wiederhold Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Please see the feature request below.

http://www.couchbase.com/forums/thread/java-client-compression-threshold




[JCBC-294] OOME on ViewResponse for very large view Created: 02/May/13  Updated: 19/Jul/13

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1.5
Fix Version/s: .next
Security Level: Public

Type: Task Priority: Major
Reporter: Tug Grall (Inactive) Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Java application with large view


 Description   
We had some complain from developer that are using large view for example 500k elements. (with small content id+url for example). The total size of the view is in this case around 52Mb.

The result out of memory.
2013-05-01 16:47:06.536 INFO
com.couchbase.client.http.AsyncConnectionManager$ConnRequestCallback:
/192.168.63.99:8092 - Session request successful
Exception in thread "I/O dispatcher 3" java.lang.OutOfMemoryError: Java
heap space
    at org.apache.http.util.CharArrayBuffer.expand(CharArrayBuffer.java:61)
    at org.apache.http.util.CharArrayBuffer.append(CharArrayBuffer.java:91)
    at org.apache.http.util.EntityUtils.toString(EntityUtils.java:200)
    at org.apache.http.util.EntityUtils.toString(EntityUtils.java:221)
    at
com.couchbase.client.protocol.views.HttpOperationImpl.getEntityString(Http
OperationImpl.java:106)
    at
com.couchbase.client.protocol.views.ViewOperationImpl.handleResponse(ViewO
perationImpl.java:60)


Note from our community member

After digging into the SDK and apache code, it occurred that the viewResponse actually contains Strings (the json objects). I think the "problem" lies in handleResponse method in ViewOperationImpl.
Here the SDK are using the apache http core to get the json String via the call
String json = getEntityString(response);
Would it be smarter to give back a InputStream instead? This could quite
easily be fixed because the response could give back a HttpEntity that
again could give the developer a InputStream.
In this way the SDK did not have to copy each Char, which it actually
does in the apache http core library (see expand in
CharArrayBufffer.class ). It does the following: char newbuffer[] = new
char[Math.max(this.buffer.length << 1, newlen)];
I think it kind of chokes when it get 52MB it have to copy from Char to a
String and then deliver it back.

BTW: I've tried calling the same view and operating on it form node.js
(using baseview and the official sdk), it just worked like a charm. And
this is prob. because you get a stream of data chunks that you can work
on, which seems more effective.

 Comments   
Comment by Michael Nitschinger [ 19/Jul/13 ]
assigning this to .next, because this potentially requires larger changes and needs more investigations.




[JCBC-291] Authentication failed on 5-th client Created: 17/Apr/13  Updated: 06/Sep/13

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: None
Fix Version/s: .next
Security Level: Public

Type: Improvement Priority: Major
Reporter: Andrew Kulikov Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Debian GNU/Linux 6.0 (amd64), Couchbase community edition.


 Description   
Let's assume I have:
- a cluster made of 4 couchbase nodes (couchbase1-couchbase4);
- 10 instances of client application (client1-client10).

In my client Java application I connect to the cluster using login, password and the following server list string:

{code}
"http://couchbase1:8091/pools,http://couchbase2:8091/pools,http://couchbase3:8091/pools,http://couchbase4:8091/pools"
{code}

When I start four instances of client application on client1-client4 -- everything is going OK. But when I am trying to start 5-th instance of client application on client5 -- I get the following error:

{code}
Mar 29 12:56:28 client1: 2013-03-29 12:56:28.564 INFO com.couchbase.client.CouchbaseConnection: Reconnecting {QA sa=couchbase1/192.168.0.129:11210, #Rops=0, #Wops=1, #iq=0, topRop=null, topWop=SASL steps operation, toWrite=0, interested=0}
Mar 29 12:56:28 client1: 2013-03-29 12:56:28.565 INFO com.couchbase.client.CouchbaseConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@28a3001c
Mar 29 12:56:28 client1: 2013-03-29 12:56:28.565 WARN net.spy.memcached.auth.AuthThreadMonitor: Incomplete authentication interrupted for node {QA sa=couchbase1/192.168.0.129:11210, #Rops=0, #Wops=1, #iq=0, topRop=null, topWop=SASL steps operation, toWrite=0, interested=8}
Mar 29 12:56:28 client1: 2013-03-29 12:56:28.565 WARN net.spy.memcached.auth.AuthThread: Authentication failed to couchbase1/192.168.0.129:11210
Mar 29 12:56:28 client1: 2013-03-29 12:56:28.566 INFO com.couchbase.client.CouchbaseConnection: Reconnecting due to exception on {QA sa=couchbase1/192.168.0.129:11210, #Rops=1, #Wops=0, #iq=0, topRop=SASL auth operation, topWop=null, toWrite=0, interested=1}
Mar 29 12:56:28 client1: at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:453)
Mar 29 12:56:28 client1: at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:381)
Mar 29 12:56:28 client1: at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:243)
Mar 29 12:56:28 client1: at com.couchbase.client.CouchbaseConnection.run(CouchbaseConnection.java:229)
Mar 29 12:56:28 client1: 2013-03-29 12:56:28.566 WARN com.couchbase.client.CouchbaseConnection: Closing, and reopening {QA sa=couchbase1/192.168.0.129:11210, #Rops=1, #Wops=0, #iq=0, topRop=SASL auth operation, topWop=null, toWrite=0, interested=1}, attempt 0.
Mar 29 12:56:28 client1: 2013-03-29 12:56:28.566 WARN net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl: Discarding partially completed op: SASL auth operation
Mar 29 12:56:28 client1: 2013-03-29 12:56:28.666 WARN net.spy.memcached.auth.AuthThread: Authentication failed to couchbase1/192.168.0.129:11210
{code}

So, if I shutdown one of client1-client4 -- this moment client5 connects to the cluster without problems.

PS: No matter if I make cluster from 2 nodes. The behaveour is the same -- 5-th node get the same error.

 Comments   
Comment by Andrew Kulikov [ 20/May/13 ]
We have solved our problem! The reason was in limit for number of opened files. Have you ever tested couchbase with pam_limits enabled? If so, default configuration (nofile=1024) is suitable only for 3 clients simultaneously connected. 4-th client fails. We have greatly increased nofile parameter for couchbase user in limits.conf -- and the problem was solved.

I think you should add this issue in your documentation. Also, you should write an error in logfile -- if this limit (for open files or any other) is reached.
Comment by Michael Nitschinger [ 20/May/13 ]
Thanks for reporting your findings! I'll change it to a docs enhancement!




[JCBC-290] Support for publishing view from dev to prod Created: 22/Apr/13  Updated: 06/Sep/13

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.1.5
Fix Version/s: .next
Security Level: Public

Type: Task Priority: Major
Reporter: Perry Krug Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Matt Ingenthron [ 22/Apr/13 ]
"publishing" isn't a real action, it's just moving the same design document in under a different name. This should definitely be done, but as documentation about how to go from development to published.




[JCBC-289] Document manipulation of the designdoc/view interface Created: 22/Apr/13  Updated: 06/Sep/13

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.1.5
Fix Version/s: .next
Security Level: Public

Type: Task Priority: Major
Reporter: Perry Krug Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The library already supports programmatic creation of design docs and views, need to supply documentation around it.




[JCBC-287] Failover + Readd of Streaming Node against 1.8.1 fails Created: 18/Apr/13  Updated: 06/Sep/13

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1.5
Fix Version/s: .next
Security Level: Public

Type: Task Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Any Couchbase SDK against a 1.8 cluster


 Comments   
Comment by Michael Nitschinger [ 19/Apr/13 ]
Let me describe the observed behaviour in greater detail to clarify what is the issue.
I just verified against 2.0 that it's the same behaviour, but I don't know why wie didn't observe it there this way.

When someone clicks failover in the UI on the streaming node, our streaming connection gets closed. Now the client code is implemented that way that it gets back to the node list passed in and iterates over it. In the case observed it is the first node in the list which we failed over, but since it has not been removed yet the client is able to connect (and even retrieve the bucket information!).

Now comes the part that I don't understand fully. With the changeset not applied, it connects to the streaming connection from the failovered node but somehow it doesnt get the information fast enough when the same node (!) gets added back. Maybe because when the node gets rebalanced out the streaming connection gets closed again and we lag little bit behind to connect to the second node in the list.

That said, WITH the changeset applied we will not connect to the failovered node immediately because we recognize its in the cluster, but not part of the node list (which kinda sucks from a logical perspective in my opinion, because why do we close the streaming connection on failover AND allow to reestablish it afterwards?). So what will happen is that the SDK immediately connects to the second one and will observe the upcoming operations (rebalance out, rebalance in) correctly.

Does this make more sense now?
Comment by Matt Ingenthron [ 19/Apr/13 ]
Not 100%, no. Do we have a log that shows responses from nodes by chance?
Comment by Michael Nitschinger [ 19/Apr/13 ]
You mean the JSON responses from the nodes? Or the netty logs on the SDK side.
Comment by Michael Nitschinger [ 19/Apr/13 ]
So if you set "failover" on one of the nodes, all HTTP Rest resources are still 100% accessible, even if the streaming connection was closed from the server before. We can even establish it again.

The main diff is that the node shows up in pools, but not in the bucket node list. It also shows a "failovered" state, so we could also try to identify it at that point.

{
systemStats: {
cpu_utilization_rate: 1,
swap_total: 1069543424,
swap_used: 0
},
interestingStats: { },
uptime: "226",
memoryTotal: 1572306944,
memoryFree: 761069568,
mcdMemoryReserved: 1199,
mcdMemoryAllocated: 1199,
couchApiBase: "http://192.168.56.101:8092/",
clusterMembership: "inactiveFailed",
status: "healthy",
thisNode: true,
hostname: "192.168.56.101:8091",
clusterCompatibility: 131072,
version: "2.0.1-170-rel-enterprise",
os: "x86_64-unknown-linux-gnu",
ports: {
proxy: 11211,
direct: 11210
}
},

(this is pools) .. its not in the node list from the bucket info (see the clusterMembership part).

I can get you SDK debug logs as well, but they are already in the CBSE from mark.




[JCBC-283] Document how best to use expiry with times >30 days Created: 12/Apr/13  Updated: 06/Sep/13

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.1.5
Fix Version/s: .next
Security Level: Public

Type: Improvement Priority: Major
Reporter: Perry Krug Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Really needed across all languages...do you want me to file separate issues?

We have some documentation on how to use expiration with relative values, but nothing clearly showing how we recommend calculating a timestamp and sending it to the operation.




[JCBC-281] Document working with the cluster manager in java manual Created: 08/Apr/13  Updated: 06/Sep/13

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.1.5
Fix Version/s: .next
Security Level: Public

Type: Bug Priority: Major
Reporter: Perry Krug Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
http://www.couchbase.com/autodocs/couchbase-java-client-1.1.5/com/couchbase/client/ClusterManager.html

This is in the Java docs, but not yet in the manual.




[JCBC-279] Docs: Cross-link bulk loading and blocking queue documentation with async commands Created: 02/Apr/13  Updated: 19/Jul/13

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.1.4
Fix Version/s: .next
Security Level: Public

Type: Improvement Priority: Major
Reporter: Perry Krug Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Just had a customer potentially running >1M touch() operations all at once and not checking the return code nor having them in a blocking queue. I think it would be worthwhile to make sure that everyone realizes the importance of proper handling of async operations and it's not obvious when just looking at the API reference for an individual operation.




[JCBC-275] Slow performance in virtualized environments Created: 18/Mar/13  Updated: 19/Jul/13

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: None
Fix Version/s: .next
Security Level: Public

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


 Description   
This is a placeholder bug meant to indicate that there are disproportionate performance impacts in the Java client when running under a virtualized environment. There are no obvious bottlenecks but it is something we've seen in multiple situations and should be investigated.

In short, there is no specific CPU, network, or disk bottleneck being hit, but performance still seems to drop significantly.

Will update with specific stats later on.




[JCBC-262] Transcoder error not reported correctly Created: 11/Mar/13  Updated: 19/Jul/13

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1.3
Fix Version/s: .next
Security Level: Public

Type: Bug Priority: Major
Reporter: Perry Krug Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
When a custom transcoder has an error, certain CAS operations fail with an error about the operation being cancelled, which is misleading and doesn't point to the transcoder as a problem.

Logs:
Mar 7, 2013 10:20:37 AM net.spy.memcached.protocol.TCPMemcachedNodeImpl setupResend
WARNING: Discarding partially completed op: Cmd: 0 Opaque: 120 Key: *****
Mar 7, 2013 10:20:40 AM net.spy.memcached.auth.AuthThread$1 receivedStatus
INFO: Authenticated to 127.0.0.1/127.0.0.1:11210

The error occurs on the get on the future. It is in fact a marshalling error in the transcoder but that never gets reported.

Code:
OperationFuture<CASValue<documentType>> future = this.client.asyncGets(key, transcoder);
return future.get(5, TimeUnit.SECONDS);

Transcoder (incorrect):

@Component
public class TranscoderImpl<T> implements Transcoder<T> {

@Autowired
@Qualifier("JSON")
Marshaller marshaler;

@Autowired
@Qualifier("JSON")
Unmarshaller unmarshaler;

@Override
public boolean asyncDecode(CachedData arg0) {
// TODO Auto-generated method stub
return false;
}

@Override
public T decode(CachedData arg0) {
// TODO Auto-generated method stub
StreamSource str = new StreamSource(new java.io.ByteArrayInputStream(arg0.getData()));

Object obj;
try {
obj = unmarshaler.unmarshal(str);
} catch (Exception e) {
// TODO Auto-generated catch block
throw new RuntimeException(e);
}

return (T)obj;
}

@Override
public CachedData encode(T arg0) {
// TODO Auto-generated method stub
ByteArrayOutputStream sink = new ByteArrayOutputStream();

try {
marshaler.marshal(arg0, new StreamResult(sink));
} catch (Exception e) {
// TODO Auto-generated catch block
throw new RuntimeException(e);
}

return new CachedData(0, sink.toByteArray(), getMaxSize());
}

@Override
public int getMaxSize() {
// TODO Auto-generated method stub
return CachedData.MAX_SIZE;
}

}




[JCBC-255] improve warmup handing Created: 27/Feb/13  Updated: 19/Jul/13

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1.3
Fix Version/s: .next
Security Level: Public

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


 Description   
With the integration of JCBC-27, the client will do an exponential backoff at construction time when the server is unavailable, and then throw an exception (from the ctor, unfortunately) if it could not complete.

There are scenarios where this isn't ideal. For example, if someone were to cut off power to a datacenter, the app servers will start up much faster than the Couchbase cluster will. Unfortunately, this means someone will need to go around and restart the app servers after the DB cluster is up.

This process should be improved and bootstrapping should no longer block construction. It should block operations (there is a latch for that), but not construction.




[JCBC-248] ensure there is a floor to tuneables such that they can't be set so a client misbehaves Created: 15/Feb/13  Updated: 19/Jul/13

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.0.3, 1.1.0, 1.1.1, 1.1.2
Fix Version/s: .next
Security Level: Public

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


 Description   
There have been a few situations where people have either inavertently or not knowing what they're doing set various internal timings to incorrect values. We should create a floor or a ceiling for these and change them with a warning if the user attempts to misuse it.

From a recent code example:
    private static String serverList = "";
    private static long opTimeout = -1;
    private static long opQueueMaxBlockTime = -1;
    private static long obsPollInterval = -1;
    private static int obsPollMax = -1;
    private static long msReconnectThresholdTime = -1;
    private static long maxReconnectDelay = -1;
    private static boolean shouldOptimize = false;
    private static int timeoutExceptionThreshold = -1;
    private static boolean useNagleAlgorithm = false;
    private static FailureMode failureMode = FailureMode.Cancel;
    private static int ttl = 86400;
    private static int threads = 1;
    private static long msBeforeGet = 5000l;
    private static long repeat = -1;






[JCBC-246] Docs: No CAS+durability in API reference table Created: 12/Feb/13  Updated: 06/Sep/13

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.1.2
Fix Version/s: .next
Security Level: Public

Type: Bug Priority: Major
Reporter: Perry Krug Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The table here: http://www.couchbase.com/docs/couchbase-sdk-java-1.1/api-reference-summary.html

Doesn't contain CAS methods with durability constraints.




[JCBC-239] Docs: Document "paginator" Created: 06/Feb/13  Updated: 06/Sep/13

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.1.2
Fix Version/s: .next
Security Level: Public

Type: Improvement Priority: Major
Reporter: Perry Krug Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Docs still point to library version 1.1...will that be updated?

I see reference to a paginator (http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-rn_1-1-0c.html) but can't find any further documentation on how to use it

 Comments   
Comment by Michael Nitschinger [ 06/Feb/13 ]
Library version is 1.1.2?

Docs for the paginator will be added soon!




[JCBC-237] Docs: Document how to use observe properly outside of the "wrapped" methods Created: 05/Feb/13  Updated: 06/Sep/13

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.1.1
Fix Version/s: .next
Security Level: Public

Type: Improvement Priority: Major
Reporter: Perry Krug Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
There will be some cases where a user wants to use the observe functionality outside of the set()/add()/replace() methods what we have allowed for them to specify the "durabililty requirements".

Specifcally this may come up when using incr/decr/prepend/append and wanting to "observe" on that...or just using observe manually to control the behavior, retry, timeouts, etc.






[JCBC-234] Write the Java on Mac OS X using Eclipse section of the Essentials Guide Created: 04/Feb/13  Updated: 19/Jul/13

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: None
Fix Version/s: .next
Security Level: Public

Type: New Feature Priority: Major
Reporter: MC Brown (Inactive) Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Write the Java on Mac OS X using Eclipse section of the Essentials Guide

Needs to cover:

Basic Installation/Setup of Eclipse
Adding the Couchbase Java components to Eclipse
Writing your first (small) app using Couchbase within Eclipse

Submissions should be to MC, either through the couchbase/docs repo, or direct to MC in whatever format suits. Must include both the text and images.


 Comments   
Comment by Michael Nitschinger [ 19/Jul/13 ]
Same here!
Comment by kzeller [ 19/Jul/13 ]
ditto, not now at all




[JCBC-233] Write the Java on Windows with Eclipse installation instructions for essentials guide Created: 04/Feb/13  Updated: 19/Jul/13

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: None
Fix Version/s: .next
Security Level: Public

Type: New Feature Priority: Major
Reporter: MC Brown (Inactive) Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Write the Java on Windows using Eclipse section of the Essentials Guide

Needs to cover:

Basic Installation/Setup of Eclipse
Adding the Couchbase Java components to Eclipse
Writing your first (small) app using Couchbase within Eclipse

Submissions should be to MC, either through the couchbase/docs repo, or direct to MC in whatever format suits. Must include both the text and images.


 Comments   
Comment by Michael Nitschinger [ 19/Jul/13 ]
aaand same here ;)
Comment by kzeller [ 19/Jul/13 ]
Tag, you're it (but not really yet at all, maybe October?)




[JCBC-229] Find a way to proper test JCBC-227 Created: 01/Feb/13  Updated: 09/Dec/13

Status: In Progress
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1.2
Fix Version/s: .next
Security Level: Public

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

Issue Links:
Dependency

 Description   
The issue fixed in jcbc-227 needs proper testing. Can you please add tests for this either as a unit test, or integrate it into sdkd? I'm not sure where it fits - what do you think?

 Comments   
Comment by Deepti Dawar [ 01/Feb/13 ]
Alright, I can add unit/integration test for the same.
Comment by Deepti Dawar [ 11/Feb/13 ]
http://review.couchbase.org/#/c/24520/
Comment by Michael Nitschinger [ 12/Feb/13 ]
Please only close once the change has been merged in, thanks.
Comment by Deepti Dawar [ 14/Feb/13 ]
http://review.couchbase.org/#/c/24520/6




[JCBC-228] a no-args constructor and an init method are needed Created: 31/Jan/13  Updated: 19/Dec/13

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1.0, 1.1.1
Fix Version/s: 2.0
Security Level: Public

Type: New Feature Priority: Major
Reporter: Matt Ingenthron Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Currently, the CouchbaseClient does a number of things that are not so pretty, like spinning up a thread from it's ctor. It would be better to add an additional, optional no-args constructor which expects an init method to be called with the other params needed, start thread, etc.

 Comments   
Comment by Michael Nitschinger [ 31/Jan/13 ]
Assigning towards 1.1.2 but we can defer it to 1.1.3 as well.
Comment by Michael Nitschinger [ 19/Dec/13 ]
We'll have something like this in 2.0




[JCBC-222] prioritized disk write queue - java client Created: 28/Jan/13  Updated: 19/Jul/13

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: None
Fix Version/s: .next
Security Level: Public

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


 Description   
ability for the client to specify that a write should be prioritized and the server to fast track that write to disk ahead of whatever might be in the disk write queue. Especially important during the case of rebalance where they may be a million+ items in the queue and the write needs to be prioritized for whatever purpose.

Should be able to work with observe operations as well as observe+xdcr(http://www.couchbase.com/issues/browse/MB-7614)




[JCBC-217] Create Source-Code Styleguide Created: 23/Jan/13  Updated: 19/Jul/13

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.1.0
Fix Version/s: .next
Security Level: Public

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


 Description   
A style guide for all java applications should be developed and paired with checkstyle rules. If possible, also provide a howto on IDE integration and git hooks.

 Comments   
Comment by Michael Nitschinger [ 31/Jan/13 ]
Moving to 1.1.2, depending on the size of the change maybe will be 1.1.3 or in between.




[JCBC-208] HTTP flush needs to be async Created: 09/Jan/13  Updated: 06/Sep/13

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1.0
Fix Version/s: .next
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Since flush can take a long time, it should be possible to handle this async.

 Comments   
Comment by Michael Nitschinger [ 09/Jan/13 ]
See also http://www.couchbase.com/forums/thread/java-sdk-1-1-asynchronous-implementation-operation-requests




[JCBC-206] Need clear info and examples on proper error handling Created: 02/Jan/13  Updated: 06/Sep/13

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.1.0
Fix Version/s: .next
Security Level: Public

Type: Improvement Priority: Major
Reporter: Tim Smith (Inactive) Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: http://www.couchbase.com/docs/couchbase-sdk-java-1.1/getting-started.html

Issue Links:
Duplicate
is duplicated by JCBC-236 Error handling documentation Resolved

 Description   
It's very difficult for people to understand the error handling behavior of the client library, and how to properly handle errors. The async methods make it even more difficult. Information is spread across multiple sections, hidden in individual method descriptions, or else not mentioned at all. The docs should provide a clear description of how to use the API correctly, including example code that does correct error handling that can be cut-and-pasted.

There is a brief mention of error handling here, but it's hidden and very cursory, with no example code:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/create-update-docs.html

This doc mentions that .get() returns null on failure, but gives no hints on how to determine why, or what the right way to recover is:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/read-docs.html

This gives a very cursory mention of failure, but no way to get further details:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/delete-docs.html

No mention of JSON encoding errors or what to expect:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/json-handling-docs.html

Mentions that OperationFuture may return false even if operation succeeds due to durability requirement failure, but no clear example of how to tell the difference, what status codes to expect in each case, etc.:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/advanced-persistence.html

Mentions that synchronous call may return an exception, but no info on what the exception would be, or in what circumstances it may return null with no exception:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-summary-synchronous.html

No mention of .isSuccess() method, or any info on how errors are reported via *Future objects. Also no mention of when the async method may fail immediately vs. when the failure will be reported only after checking .isSuccess() or another method on the future. No mention of what errors are reported as exceptions vs. what errors are reported only via the future object's methods.:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-summary-asynchronous.html

No mention of when the constructor might fail or what exceptions might be thrown:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/api-reference-connection.html

No mention of how to tell if the FALSE result is due to timeout, impossible persistence requirements, or other problem:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-set-observe.html

Not clear enough that .add(), .set(), .replace() are an async methods, too easy for new user to misunderstand how to use them:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-set-add.html
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-set-set.html
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-update-replace.html

No mention that .get() may throw an exception, or how errors other than NotFound may be reported:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-retrieve-get.html

Yay, here is an example that has a bit of error handling! Unfortunately, it is a "catch(Exception)" (i.e., very generic, and not intended to catch Couchbase-specific errors or timeouts), and no indication of how to handle actual Couchbase errors. Also gives false impression that get() will throw an exception on all failure, when in fact you need to check for failure with .isSuccess() or something.:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-retrieve-get-async.html

Also on that page (async get), mentions that a TimeoutException may be thrown. But that won't happen on asyncGet() call, instead it will be when checking .get() on the Future result. I think. It is welcome to list exceptions that can be thrown, but I think this one is incorrect.
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-retrieve-get-async.html

.getBulk() and .asyncGetBulk() are complicated enough that they deserve their own example of proper error handling, and what happens when one server node is down and other nodes are up, so partial results are available, etc.:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-retrieve-bulk.html

Nice that these pages mention what exceptions can be thrown, so I can infer how to tell a timeout from a not found, etc. But why only here? Shouldn't these exceptions be more generally described elsewhere as applying to all operations (RuntimeException, InterruptedException, OperationTimeoutException)?:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-retrieve-get-and-lock.html
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-retrieve-unlock.html

Append and Prepend should normally use 0 for the casunique, and then I would not expect an EXISTS error. The example code is clunky, less efficient (suggests doing a .gets() call just to get the cas id), and likely to fail much more often. The example code does not do proper retry handling on an EXISTS error. It does not show how to distinguish an EXISTS, NOTFOUND, or server down error.:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-update-append.html
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-update-prepend.html

View queries might time out, on all or some servers. Should document how the client should handle errors from view queries. Also, if client requests a view that doesn't exist, how is that handled:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/api-reference-view.html



There is no mention of error handling in the "Using the APIs" nor "Java Troubleshooting" sections, either:

http://www.couchbase.com/docs/couchbase-sdk-java-1.1/api-reference-started.html
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/api-reference-troubleshooting.html

There is a brief mention of RuntimeException being "returned" (should say "thrown") in the section on handling timeouts, but this is too buried and too specific to be of real use. And there is no example code:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/api-reference-troubleshooting.html

Also, the tutorial doesn't do error handling at all, for example:

http://www.couchbase.com/docs/couchbase-sdk-java-1.1/managing-beers.html

Look for "client.set" and "client.query" on that page and you'll see it ignores error handling entirely. I think this is a mistake in tutorial code, it should be complete and correct, or at least it should provide a warning saying that there is no error handling, with a link to the docs that describe how to do proper error handling.



 Comments   
Comment by Michael Nitschinger [ 31/Jan/13 ]
Moving to 1.1.2, depending on the size of the change maybe will be 1.1.3 or in between.




[JCBC-204] document increment/decrement behavior with non-numeric value Created: 02/Jan/13  Updated: 13/Feb/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 1.1.0
Fix Version/s: .next
Security Level: Public

Type: Improvement Priority: Major
Reporter: Tim Smith (Inactive) Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-update-incr.html


 Description   
Increment and decrement should document what happens if the key exists on the server, but the value is invalid. It should describe what a valid value is (and link to the Developer's Guide page that describes the server-side behavior in greater detail).

Valid value is a string. String is decimal representation of an unsigned 64-bit integer.

 Comments   
Comment by Michael Nitschinger [ 31/Jan/13 ]
Moving to 1.1.2, depending on the size of the change maybe will be 1.1.3 or in between.




[JCBC-203] append/prepend are ASYNC, and can specify 0 for casunique Created: 02/Jan/13  Updated: 13/Feb/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: .next
Security Level: Public

Type: Improvement Priority: Major
Reporter: Tim Smith (Inactive) Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-update-append.html


 Description   
This is a two-for-one bug report for the docs. First, the return value of append/prepend is Future<Boolean>, not "Object ( Binary object )". These are async ops, and need to be documented as such.

Next, the append and prepend methods say that the casunique argument must be specified, but don't mention that it is OK to pass 0 here if you just want to append to whatever is there.

In fact, using 0 for casunique is going to be the normal use case for these functions, since memcached (and Couchbase) defines them to be atomic. It's too bad that spymemcached made this interface clunky, but we can at least document this normal use case.

 Comments   
Comment by Michael Nitschinger [ 31/Jan/13 ]
Moving to 1.1.2, depending on the size of the change maybe will be 1.1.3 or in between.




[JCBC-201] All async ops should link to the Asynchronous Operations page Created: 02/Jan/13  Updated: 06/Sep/13

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: None
Fix Version/s: .next
Security Level: Public

Type: Improvement Priority: Major
Reporter: Tim Smith (Inactive) Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-set-add.html
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-retrieve-get-async.html

Etc., there are a bunch of these.


 Description   
There are a lot of async operations. They return *Future<*>. They should all have a link back to the overview of how Asynchronous Operations work, at http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-summary-asynchronous.html

 Comments   
Comment by Michael Nitschinger [ 31/Jan/13 ]
Moving to 1.1.2, depending on the size of the change maybe will be 1.1.3 or in between.




[JCBC-199] constructor documented as client method returning "(none)" Created: 02/Jan/13  Updated: 06/Sep/13

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.1.0
Fix Version/s: .next
Security Level: Public

Type: Bug Priority: Major
Reporter: Tim Smith (Inactive) Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: http://www.couchbase.com/docs/couchbase-sdk-java-1.1/api-reference-connection.html


 Description   
The constructor is documented to return "(none)", which isn't really correct.

http://www.couchbase.com/docs/couchbase-sdk-java-1.1/api-reference-connection.html

Also, the docs make it look like it's a method call on an existing client object ("client.new"), which isn't accurate:

"client.new CouchbaseClient([ url ] [, urls ] [, username ] [, password ])"



 Comments   
Comment by Michael Nitschinger [ 31/Jan/13 ]
Moving to 1.1.2, depending on the size of the change maybe will be 1.1.3 or in between.




[JCBC-184] API reference should show return types Created: 14/Dec/12  Updated: 06/Sep/13

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.1.0
Fix Version/s: .next
Security Level: Public

Type: Improvement Priority: Major
Reporter: Tim Smith (Inactive) Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 8h
Time Spent: Not Specified
Original Estimate: 8h
Environment: http://www.couchbase.com/docs/couchbase-sdk-java-1.1/api-reference-summary.html


 Description   
The return type is critical for understanding how to use a function. In particular with the Java client library, it's critical to know if a function returns a Future (i.e., it's an async function) or not. Otherwise it's impossible to use it correctly.

Currently one must click through, scroll around, and pick out the return value somewhere in a list of parameters on the details page. It would be worth the extra screen real estate on the api reference page to show the return value as well.






[JCBC-183] Many methods in api reference don't link to corresponding documentation page Created: 14/Dec/12  Updated: 06/Sep/13

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.1.0
Fix Version/s: .next
Security Level: Public

Type: Bug Priority: Major
Reporter: Tim Smith (Inactive) Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 0.5h
Time Spent: Not Specified
Original Estimate: 0.5h
Environment: http://www.couchbase.com/docs/couchbase-sdk-java-1.1/api-reference-summary.html


 Description   
Many of the links in the api-reference-summary.html don't go anywhere. They should all link to the detail page for the particular method.

http://www.couchbase.com/docs/couchbase-sdk-java-1.1/api-reference-summary.html

It *may* be just the ones with durability requirements (persistto, replicateto) in the signature.




[JCBC-180] Allow for default value to append/prepend Created: 12/Dec/12  Updated: 01/Aug/13

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1.0
Fix Version/s: .next
Security Level: Public

Type: Improvement Priority: Major
Reporter: Perry Krug Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: customer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on MB-7653 Allow for default value to append/pre... Open

 Description   
As with incr/decr, it would be very helpful to have a default value come along with the append/prepend operation to keep them atomic and avoid the extra round-trip of an add()

 Comments   
Comment by Michael Nitschinger [ 31/Jan/13 ]
Moved to .next until this is clarified on the server side.




[JCBC-169] add overloaded methods for various types to the Query class Created: 06/Dec/12  Updated: 19/Jul/13

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1.0
Fix Version/s: .next
Security Level: Public

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


 Description   
Currently, all types other than strings must go through the ComplexKey class. This may not be the best approach since it leads to a bit of oddness with needing to tell the ComplexKey class to handle a single element differently.

One alternative is to improve the Query class to handle other types, then deprecate the special handling in the ComplexKey class and change the behavior for a single element. This would be a small API change, but maybe small enough that with sufficient warning, we can do it in a minor release.




[JCBC-117] mention that OperationFuture.get(tmo) changes state when timeout has been reached Created: 24/Sep/12  Updated: 06/Sep/13

Status: Reopened
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.0.3
Fix Version/s: .next
Security Level: Public

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

Issue Links:
Dependency
blocks JCBC-114 Command Futures never receive results... Reopened

 Description   
get(tmo) should not change the underlying state of the command to being timed out. It should simply respond with a TimeoutException but allow the command to continue.

Specifically, when the arg-tmo (timeout passed as an argument) expires, the underlying command is marked as timed out. For example, if one waits for 50ms on the command and a response has not been received within that time, the command is now dead ('TIMEDOUT', or similar) and waiting again will not help.

It is understandable that some code might rely on the old behavior, so at the very least, this should be documented in 'BIG RED LETTERS' in the get(tmo) method.

 Comments   
Comment by Matt Ingenthron [ 05/Oct/12 ]
Please explain further.
Comment by Michael Nitschinger [ 16/Oct/12 ]
Hey Mark,

Can you explain in more detail what you want to see changed? When the argument is timed-out what should happen then with it?

Thanks,
Michael
Comment by Matt Ingenthron [ 24/Oct/12 ]
As currently designed, the client uses get() to determine timeout. This is not going to change at the moment. There's no other appropriate place internal to the client to check for this timeout of the operation at the moment.
Comment by Mark Nunberg [ 24/Oct/12 ]
Moving this as a documentation bug
Comment by Matt Ingenthron [ 06/Nov/12 ]
Michael, I'd like you to give this one a shot as your first docs bug, I'll help you with this as needed.




[JCBC-116] Implement the ObserveSet for better observing of replication/persistence Created: 18/Sep/12  Updated: 19/Jul/13

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: None
Fix Version/s: .next
Security Level: Public

Type: New Feature Priority: Major
Reporter: Matt Ingenthron Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-115] thoroughly test on_error arguments Created: 18/Sep/12  Updated: 19/Jul/13

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: None
Fix Version/s: .next
Security Level: Public

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


 Description   
Support for on_error was recently added, but it does does not currently have a test for on_error=stop.

 Comments   
Comment by Michael Nitschinger [ 09/Nov/12 ]
Mark,

Can you add this to your sdkd testsuite? Its hard to deal with this in unit tests (would require lots of mocking) and I assume you can shutdown nodes and verify the behavior is correct?

Thanks,
Michael
Comment by Michael Nitschinger [ 29/Nov/12 ]
We can do this in functional tests as well, there are easy ways to produce errors on the server.
Comment by Mark Nunberg [ 29/Nov/12 ]
Please share :)




[JCBC-114] Command Futures never receive results after rebalance-out (or other sorts of topology/network changes) Created: 17/Sep/12  Updated: 06/Sep/13

Status: Reopened
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.0.3
Fix Version/s: .next
Security Level: Public

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

Issue Links:
Dependency
depends on JCBC-117 mention that OperationFuture.get(tmo)... Reopened

 Comments   
Comment by Mark Nunberg [ 03/Oct/12 ]
This is a real blocker, and seems to be related to a few vbuckets. This issue is preventing me from properly measuring command durations
Comment by Farshid Ghods (Inactive) [ 03/Oct/12 ]
Matt/Rags,

This issue is a blocker for executing more integration tests on java sdk. are there workarounds to avoid this use case or a fix on the way ?
Please assign this back to Mark if more information or logs needed for this issue
Comment by Matt Ingenthron [ 04/Oct/12 ]
Please have a look at this.
Comment by Mark Nunberg [ 05/Oct/12 ]
Michael,

I would not try this test manually.. the use case in more detail is as follows:

- Single CouchbaseClient object
- 20 user threads. 10 setting and 10 getting the same sorts of kv
- Operations are done asynchronously. They are submitted into a queue which is then checked periodically for isDone/isCancelled.
- 4 node cluster. Nodes are removed, connections are broken

The issue is those polling methods never returning true, unless they are retrieved synchronously (i.e. ft.get()).. which is actually an accidental detail
Comment by Matt Ingenthron [ 24/Oct/12 ]
We looked at this pretty closely today. The issue here is that the client as designed relies on the get() from the caller to trigger the timeout. An operation will, somewhat correctly, never transition to isDone() or isCancelled() unless someone cares to use it.

The scenario that was likely in play over the WAN here is that the request was in flight to the server while the config was in flight down to the client. It arrives at the server, but is never responded to. Since the get() is never called, it'll never time out and transition to the canceled state.

We recommend you change the test code to use the queue more like a queue and just get() each one. Iterating through the queue is a bit funny in the first place, but if using the get() on the Future objects, you'll still have asynchronous behavior and much of the time the get() will be returning since the data is already there.
Comment by Matt Ingenthron [ 24/Oct/12 ]
This behavior should be better documented, both in the javadoc and in the API reference.




[JCBC-108] observe loop implementation behind mutations should be adaptive to server persistence latencies Created: 11/Sep/12  Updated: 19/Jul/13

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: None
Fix Version/s: .next
Security Level: Public

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


 Description   
The current observe loop implementation does not acknowledge the average persistence latency which is in the observe response.




[JCBC-28] refactor the entire cluster stream connection Created: 03/Apr/12  Updated: 06/Sep/13

Status: Reopened
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: None
Fix Version/s: .next
Security Level: Public

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


 Description   
Because of the codebase's legacy, the handling of the Bucket and Configuration is rather odd. It used to exist outside the client to serve a different purpose. At that time, not changing the client internals was desirable.

Fast forwarding to now, the internals should be updated to have the NodeLocator or the connection abstract away much of the configuration details.




[JCBC-18] NPE if hostnames in server bootstrap list are mixed case Created: 12/Mar/12  Updated: 19/Jul/13

Status: Reopened
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1-dp4
Fix Version/s: .next
Security Level: Public

Type: Bug Priority: Major
Reporter: Matt Ingenthron Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
A user described a scenario where using mixed case in their URIs lead to an NPE. This is from the map lookup, since what the couchbase cluster sends us is different than what the user entered, I think.

See: http://www.couchbase.com/forums/thread/java-client-101-exception-using-couchbaseclient-servlet-filter




[JCBC-15] add showtype-options to documentation Created: 23/Feb/12  Updated: 06/Sep/13

Status: Reopened
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: None
Fix Version/s: .next
Security Level: Public

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


 Description   
Many of the Java docs should show the type in the options summary.

 Comments   
Comment by Michael Nitschinger [ 15/Nov/12 ]
Can you give me a quick example on what you mean? Reassign it back to me then and I'll fix it!
Comment by Matt Ingenthron [ 15/Nov/12 ]
If you look at the docs, there are many places where we have types that are returned, but we don't sufficiently describe those types. For example:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-set-add.html#table-couchbase-sdk_java_add

It mentions the OperationFuture, but nowhere really tell how to use it (to my knowledge).

You should be able to work with MC on the right way to fix these.




[JCBC-432] Get a null value when the deserialization fails Created: 18/Mar/14  Updated: 19/Mar/14

Status: Open
Project: Couchbase Java Client
Component/s: Dependencies
Affects Version/s: 1.3.2, 1.4.0-dp1
Fix Version/s: None
Security Level: Public

Type: Improvement Priority: Minor
Reporter: syu.hsh Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
CouchbaseClient.getBulk

 Comments   
Comment by syu.hsh [ 18/Mar/14 ]
 key-values returned by CouchbaseClient.getBulk contain null value
caused by net.spy.memcached.transcoders.BaseSerializingTranscoder
protected Object deserialize(byte[] in) {
    Object rv=null;
    ByteArrayInputStream bis = null;
    ObjectInputStream is = null;
    try {
      if(in != null) {
        bis=new ByteArrayInputStream(in);
        is=new ObjectInputStream(bis);
        rv=is.readObject();
        is.close();
        bis.close();
      }
    } catch (IOException e) {
      getLogger().warn("Caught IOException decoding %d bytes of data",
          in == null ? 0 : in.length, e);
    } catch (ClassNotFoundException e) {
      getLogger().warn("Caught CNFE decoding %d bytes of data",
          in == null ? 0 : in.length, e);
    } finally {
      CloseUtil.close(is);
      CloseUtil.close(bis);
    }
    return rv;
  }
Comment by Michael Nitschinger [ 19/Mar/14 ]
can you share an example to reproduce?




[JCBC-385] Configurable number of threads for client Created: 02/Dec/13  Updated: 19/Dec/13

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0
Security Level: Public

Type: Task Priority: Minor
Reporter: James Mauss Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Often the Client will create a number of threads for some features that the client does not plan on using, like views. This causes some extra overhead that is not needed.

It would be nice if the total number of threads that a client object creates is configurable.

 Comments   
Comment by Michael Nitschinger [ 19/Dec/13 ]
note that this will e fully fixed in 2.0, but in 1.3 we will be much better with that on views.




[JCBC-357] Bulk touch function to batch multiple updates Created: 29/Aug/13  Updated: 06/Sep/13

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 1.1.9
Fix Version/s: .next
Security Level: Public

Type: New Feature Priority: Minor
Reporter: David Haikney Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: customer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
A customer has requested a function to batch multiple touches into one network call similar to the "multitouch" call of the php SDK.




[JCBC-317] Implement a multi delete operation Created: 11/Jun/13  Updated: 19/Jul/13

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1.7
Fix Version/s: .next
Security Level: Public

Type: New Feature Priority: Minor
Reporter: Tug Grall (Inactive) Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
It would be useful to provide a multi delete operation in the Couchbase Java API (and other SDK) this has been done inthe Python SDK:
https://github.com/couchbase/couchbase-python-client/blob/master/tests/test_delete.py#L73






[JCBC-311] Expose the Server Error Code in the OperationStatus Created: 23/May/13  Updated: 06/Sep/13

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1.6
Fix Version/s: .next
Security Level: Public

Type: New Feature Priority: Minor
Reporter: Tug Grall (Inactive) Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The Java SDK does not use the Error Code from the server side, as documented here:
http://blog.couchbase.com/handling-runtime-errors-ruby-python-and-c-clients

It would be very useful for the developer to be able to use the same code in Java. We could use the OperationStatus to expose this enumeration.




[JCBC-306] Add a method that returns the list of design document for a bucket Created: 21/May/13  Updated: 06/Sep/13

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1.6
Fix Version/s: .next
Security Level: Public

Type: Improvement Priority: Minor
Reporter: Tug Grall (Inactive) Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
It would be great to add a method to return the list of design document for a bucket.

We should do something like:

List< DesignDocument > client.getDesignDocuments()

 Comments   
Comment by Didier Bathily [ 11/Jul/13 ]
+1

Exist in php sdk http://www.couchbase.com/issues/browse/PCBC-186




[JCBC-300] Add as Example: Java/NoSQL Tricks Created: 28/Mar/13  Updated: 19/Jul/13

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: None
Fix Version/s: .next
Security Level: Public

Type: Improvement Priority: Minor
Reporter: Anonymous Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
http://www.infoworld.com/d/application-development/how-teach-java-ee-app-new-nosql-tricks-215277

 Comments   
Comment by kzeller [ 09/May/13 ]
I'm not sure i would take this request as high priority, but back in March, someone (I can't remember) sent me an email saying we should add this type of content to our doc set.

I would just keep this in your queue for now. It might just be more informational/inspirational......My suspicions is this is a priority 2.




[JCBC-273] Unknown Host Exception should be caught Created: 15/Mar/13  Updated: 19/Dec/13

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: None
Fix Version/s: .next
Security Level: Public

Type: Bug Priority: Minor
Reporter: Deepti Dawar Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Encountered these errors while running on Jenkins. These need to be handled.

Stack Trace :

  [junit] Testcase: testMessageReceived took 0.173 sec
    [junit] Testsuite: com.couchbase.client.vbucket.ConfigurationProviderHTTPDownNodeTest
    [junit] 2013-03-15 04:07:54.268 WARN com.couchbase.client.vbucket.ConfigurationProviderHTTP: Connection problems with URI http://bogus:8091/pools ...skipping
    [junit] java.net.UnknownHostException: bogus
    [junit] at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:175)
    [junit] at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
    [junit] at java.net.Socket.connect(Socket.java:546)
    [junit] at sun.net.NetworkClient.doConnect(NetworkClient.java:173)
    [junit] at sun.net.www.http.HttpClient.openServer(HttpClient.java:409)
    [junit] at sun.net.www.http.HttpClient.openServer(HttpClient.java:530)
    [junit] at sun.net.www.http.HttpClient.&lt;init&gt;(HttpClient.java:240)
    [junit] at sun.net.www.http.HttpClient.New(HttpClient.java:321)
    [junit] at sun.net.www.http.HttpClient.New(HttpClient.java:338)
    [junit] at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:935)
    [junit] at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:876)
    [junit] at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:801)
    [junit] at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1139)
    [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.readToString(ConfigurationProviderHTTP.java:417)
    [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.readPools(ConfigurationProviderHTTP.java:210)
    [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.getBucketConfiguration(ConfigurationProviderHTTP.java:147)
    [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTPDownNodeTest.testGetBucketConfiguration(ConfigurationProviderHTTPDownNodeTest.java:67)
    [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    [junit] at java.lang.reflect.Method.invoke(Method.java:616)
    [junit] at junit.framework.TestCase.runTest(TestCase.java:168)
    [junit] at junit.framework.TestCase.runBare(TestCase.java:134)
    [junit] at junit.framework.TestResult$1.protect(TestResult.java:110)
    [junit] at junit.framework.TestResult.runProtected(TestResult.java:128)
    [junit] at junit.framework.TestResult.run(TestResult.java:113)
    [junit] at junit.framework.TestCase.run(TestCase.java:124)
    [junit] at junit.framework.TestSuite.runTest(TestSuite.java:232)
    [junit] at junit.framework.TestSuite.run(TestSuite.java:227)
    [junit] at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
    [junit] at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
    [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420)
    [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911)
    [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:768)
    [junit] 2013-03-15 04:07:54.724 WARN com.couchbase.client.vbucket.ConfigurationProviderHTTP: Connection problems with URI http://bogustoo:8091/pools ...skipping
    [junit] java.net.UnknownHostException: bogustoo
    [junit] at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:175)
    [junit] at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
    [junit] at java.net.Socket.connect(Socket.java:546)
    [junit] at sun.net.NetworkClient.doConnect(NetworkClient.java:173)
    [junit] at sun.net.www.http.HttpClient.openServer(HttpClient.java:409)
    [junit] at sun.net.www.http.HttpClient.openServer(HttpClient.java:530)
    [junit] at sun.net.www.http.HttpClient.&lt;init&gt;(HttpClient.java:240)
    [junit] at sun.net.www.http.HttpClient.New(HttpClient.java:321)
    [junit] at sun.net.www.http.HttpClient.New(HttpClient.java:338)
    [junit] at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:935)
    [junit] at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:876)
    [junit] at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:801)
    [junit] at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1139)
    [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.readToString(ConfigurationProviderHTTP.java:417)
    [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.readPools(ConfigurationProviderHTTP.java:210)
    [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.getBucketConfiguration(ConfigurationProviderHTTP.java:147)
    [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTPDownNodeTest.testGetBucketConfiguration(ConfigurationProviderHTTPDownNodeTest.java:67)
    [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    [junit] at java.lang.reflect.Method.invoke(Method.java:616)
    [junit] at junit.framework.TestCase.runTest(TestCase.java:168)
    [junit] at junit.framework.TestCase.runBare(TestCase.java:134)
    [junit] at junit.framework.TestResult$1.protect(TestResult.java:110)
    [junit] at junit.framework.TestResult.runProtected(TestResult.java:128)
    [junit] at junit.framework.TestResult.run(TestResult.java:113)
    [junit] at junit.framework.TestCase.run(TestCase.java:124)
    [junit] at junit.framework.TestSuite.runTest(TestSuite.java:232)
    [junit] at junit.framework.TestSuite.run(TestSuite.java:227)
    [junit] at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
    [junit] at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
    [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420)
    [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911)
    [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:768)
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.991 sec
    [junit] ------------- Standard Error -----------------
    [junit] 2013-03-15 04:07:54.268 WARN com.couchbase.client.vbucket.ConfigurationProviderHTTP: Connection problems with URI http://bogus:8091/pools ...skipping
    [junit] java.net.UnknownHostException: bogus
    [junit] at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:175)
    [junit] at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
    [junit] at java.net.Socket.connect(Socket.java:546)
    [junit] at sun.net.NetworkClient.doConnect(NetworkClient.java:173)
    [junit] at sun.net.www.http.HttpClient.openServer(HttpClient.java:409)
    [junit] at sun.net.www.http.HttpClient.openServer(HttpClient.java:530)
    [junit] at sun.net.www.http.HttpClient.&lt;init&gt;(HttpClient.java:240)
    [junit] at sun.net.www.http.HttpClient.New(HttpClient.java:321)
    [junit] at sun.net.www.http.HttpClient.New(HttpClient.java:338)
    [junit] at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:935)
    [junit] at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:876)
    [junit] at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:801)
    [junit] at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1139)
    [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.readToString(ConfigurationProviderHTTP.java:417)
    [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.readPools(ConfigurationProviderHTTP.java:210)
    [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.getBucketConfiguration(ConfigurationProviderHTTP.java:147)
    [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTPDownNodeTest.testGetBucketConfiguration(ConfigurationProviderHTTPDownNodeTest.java:67)
    [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    [junit] at java.lang.reflect.Method.invoke(Method.java:616)
    [junit] at junit.framework.TestCase.runTest(TestCase.java:168)
    [junit] at junit.framework.TestCase.runBare(TestCase.java:134)
    [junit] at junit.framework.TestResult$1.protect(TestResult.java:110)
    [junit] at junit.framework.TestResult.runProtected(TestResult.java:128)
    [junit] at junit.framework.TestResult.run(TestResult.java:113)
    [junit] at junit.framework.TestCase.run(TestCase.java:124)
    [junit] at junit.framework.TestSuite.runTest(TestSuite.java:232)
    [junit] at junit.framework.TestSuite.run(TestSuite.java:227)
    [junit] at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
    [junit] at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
    [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420)
    [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911)
    [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:768)
    [junit] 2013-03-15 04:07:54.724 WARN com.couchbase.client.vbucket.ConfigurationProviderHTTP: Connection problems with URI http://bogustoo:8091/pools ...skipping
    [junit] java.net.UnknownHostException: bogustoo
    [junit] at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:175)
    [junit] at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
    [junit] at java.net.Socket.connect(Socket.java:546)
    [junit] at sun.net.NetworkClient.doConnect(NetworkClient.java:173)
    [junit] at sun.net.www.http.HttpClient.openServer(HttpClient.java:409)
    [junit] at sun.net.www.http.HttpClient.openServer(HttpClient.java:530)
    [junit] at sun.net.www.http.HttpClient.&lt;init&gt;(HttpClient.java:240)
    [junit] at sun.net.www.http.HttpClient.New(HttpClient.java:321)
    [junit] at sun.net.www.http.HttpClient.New(HttpClient.java:338)
    [junit] at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:935)
    [junit] at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:876)
    [junit] at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:801)
    [junit] at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1139)
    [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.readToString(ConfigurationProviderHTTP.java:417)
    [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.readPools(ConfigurationProviderHTTP.java:210)
    [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.getBucketConfiguration(ConfigurationProviderHTTP.java:147)
    [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTPDownNodeTest.testGetBucketConfiguration(ConfigurationProviderHTTPDownNodeTest.java:67)
    [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    [junit] at java.lang.reflect.Method.invoke(Method.java:616)
    [junit] at junit.framework.TestCase.runTest(TestCase.java:168)
    [junit] at junit.framework.TestCase.runBare(TestCase.java:134)
    [junit] at junit.framework.TestResult$1.protect(TestResult.java:110)
    [junit] at junit.framework.TestResult.runProtected(TestResult.java:128)
    [junit] at junit.framework.TestResult.run(TestResult.java:113)
    [junit] at junit.framework.TestCase.run(TestCase.java:124)
    [junit] at junit.framework.TestSuite.runTest(TestSuite.java:232)
    [junit] at junit.framework.TestSuite.run(TestSuite.java:227)
    [junit] at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
    [junit] at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
    [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420)
    [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911)
    [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:768)

 Comments   
Comment by Michael Nitschinger [ 15/Mar/13 ]
Why should it be caught? The UnknownHostException is semantically 100% spot on.
Comment by Deepti Dawar [ 15/Mar/13 ]
If it is not caught, it should be handled in the junit test such that the junit test should expect that exception otherwise the test fails.
Comment by Michael Nitschinger [ 19/Jul/13 ]
Has this been resolved with recent changes to the tests?
Comment by Deepti Dawar [ 22/Jul/13 ]
No, this still exists.
Comment by Deepti Dawar [ 03/Sep/13 ]
I have tried to catch the UnknownHostException at very many places, but that does not seem to resolve the problem.
Even tried debugging the same, but seems like there is a logging level issue. Michael, can you please let me know where do we set the logging level and related properties ?
Comment by Michael Nitschinger [ 19/Dec/13 ]
Any progress on this? Still don't know what we need to fix here :)




[JCBC-247] ViewReponse: Provide a way to return the JSON as it is Created: 14/Feb/13  Updated: 19/Jul/13

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: None
Fix Version/s: .next
Security Level: Public

Type: Improvement Priority: Minor
Reporter: Tug Grall (Inactive) Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The Java API provide most of the time access to the JSON document (as string):
- get commands
- view command using the ViewRow.getDocument

When we call a view the result is a ViewResponse, but it is not possible to get the JSON document out of it, and the view engine returned a JSON doc.

It could be interesting for some development, to be able to do a viewResponse.toJSON() that returns the exact result of the view. (this function may not be compliant with the includesDoc(true) option)

The use case is simple, suppose I am creating a REST API and I would like to call the view and return the result to the user it would be good to do something like :


@GET
@Produces({ "application/json"})
@Path("/person/")
public String getPersons( ) {

           View view = client.getView(PERSON_DSGN_DOC, PERSON_BY_NAME_VIEW);
            Query query = new Query();
            ViewResponse viewResponse = client.query(view, query);
            return viewResponse.toJSON();


 }



Today I have to loop on each result and create a new object/document







[JCBC-205] docs for touch() should mention getAndTouch() Created: 02/Jan/13  Updated: 06/Sep/13

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: None
Fix Version/s: .next
Security Level: Public

Type: Improvement Priority: Minor
Reporter: Tim Smith (Inactive) Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-update-touch.html


 Description   
It would be nice for the touch() docs to mention getAndTouch() as a common optimization:

http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-retrieve-gat.html




[JCBC-113] code injection during development/debug causing IllegalStateException Created: 13/Sep/12  Updated: 19/Dec/13

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1dp, 1.1dp2, 1.1.0
Fix Version/s: .next
Security Level: Public

Type: Bug Priority: Minor
Reporter: Matt Ingenthron Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Caused by: java.lang.IllegalStateException: Shutting down
at net.spy.memcached.MemcachedConnection.checkState(MemcachedConnection.java:824) ~[spymemcached-2.8.4.jar:2.8.4]
at net.spy.memcached.MemcachedConnection.enqueueOperation(MemcachedConnection.java:640) ~[spymemcached-2.8.4.jar:2.8.4]
at net.spy.memcached.MemcachedClient.asyncGet(MemcachedClient.java:841) ~[spymemcached-2.8.4.jar:2.8.4]
at net.spy.memcached.MemcachedClient.get(MemcachedClient.java:1003) ~[spymemcached-2.8.4.jar:2.8.4]
at net.spy.memcached.MemcachedClient.get(MemcachedClient.java:1024) ~[spymemcached-2.8.4.jar:2.8.4]

It happens everytime I change the code in debug mode (JVM code injection)

From thread: http://www.couchbase.com/forums/thread/java-client-issue-after-code-injection

 Comments   
Comment by Michael Nitschinger [ 16/Nov/12 ]
Asked "cb" on the forums for more information to be able to reproduce the issue.
Comment by cb [ 23/Dec/12 ]
I tested on v1.1 and there are still issues:

Caused by: java.lang.IllegalStateException: Shutting down
at net.spy.memcached.MemcachedConnection.checkState(MemcachedConnection.java:825) ~[spymemcached-2.8.9.jar:2.8.9]
at net.spy.memcached.MemcachedConnection.enqueueOperation(MemcachedConnection.java:641) ~[spymemcached-2.8.9.jar:2.8.9]
at net.spy.memcached.MemcachedClient.asyncGetAndTouch(MemcachedClient.java:1284) ~[spymemcached-2.8.9.jar:2.8.9]
at net.spy.memcached.MemcachedClient.getAndTouch(MemcachedClient.java:955) ~[spymemcached-2.8.9.jar:2.8.9]
at net.spy.memcached.MemcachedClient.getAndTouch(MemcachedClient.java:978) ~[spymemcached-2.8.9.jar:2.8.9]
at models.AdminUserSession.findByKey(AdminUserSession.java:35) ~[classes/:na]
Comment by Michael Nitschinger [ 24/Dec/12 ]
Hi cb,

thanks for responding. Would it be possible to help me out reproducing it? What kind of setup are you using? (OS, IDE, App Server) and so on? I never encountered this in my environments here... thanks very much!
Comment by cb [ 24/Dec/12 ]
Play Framewok 1.0.4
Couchbase 2 GA
Java Client 1.1

You can use the example app that you created in your Blog Post. (BTW - Still looking forward for the rest of the parts of this super good post!!)
Change something in the code - while running in sbt like this:

~run (note the "~") which tells sbt to inject any change into the running process.

Let me know if you can reproduce the bug.

Comment by Michael Nitschinger [ 24/Dec/12 ]
You mean 2.0.4?

Are you running on 1.6 or 1.7 java? Or which scala version? On which operating system are you running it?

Never came across this (neither while working on the blog posts nor working on it from other apps).

Comment by cb [ 24/Dec/12 ]
sorry 2.0.4

Jave Version:

Java(TM) SE Runtime Environment (build 1.6.0_37-b06-434-11M3909)
Java HotSpot(TM) 64-Bit Server VM (build 20.12-b01-434, mixed mode)

OSX 10.8.2
Comment by Michael Nitschinger [ 19/Jul/13 ]
Hey, are you still facing this issue? We've never seen it coming up somewhere else!
Comment by Michael Nitschinger [ 19/Dec/13 ]
cb, are you still running into this? If so, we should track that down finally.




[JCBC-83] replace use of java assert in tests with junit assertions, including messages Created: 12/Jul/12  Updated: 13/Feb/14

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: None
Fix Version/s: .next
Security Level: Public

Type: Improvement Priority: Minor
Reporter: Mike Wiederhold Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Michael Nitschinger [ 31/Jan/13 ]
Moving to 1.1.2 because its a smaller change.




[JCBC-33] Reconfiguration strategy used in TapConnectionProvider can lead to temporary deadlock of the ConfigurationProvider thread Created: 12/Apr/12  Updated: 19/Jul/13

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.0.2
Fix Version/s: .next
Security Level: Public

Type: Bug Priority: Minor
Reporter: Marty Schoch Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: tested on linux


 Description   
Let's assume for now that a new node has been added to the cluster.

1. When a configuration change is detected, the reconfigure() method of TapConnectionProvider is called.
2. TapConnectionProvider will call ((CouchbaseConnection)conn).reconfigure(bucket);
3. Inside CouchbaseConnection reconfigure() the new server will be found and added to the list newServers
4. Then createConnections(newServers) will be called in the parent class MemcachedConnection
5. Depending on the log level you'll see the message logged from getLogger().info("Added %s to connect queue", qa);
6. Then the code will hang at the line: https://github.com/couchbase/spymemcached/blob/master/src/main/java/net/spy/memcached/MemcachedConnection.java#L155

qa.setSk(ch.register(selector, ops, qa));

The code will hang until another packet is received on the channel. This is the expected behavior in Java NIO. The recommended practice is perform registrations from the same thread as selects. In this case we're registering from the thread that was monitoring for configuration changes, and selecting from the main run loop of the MemcachedConnection.

See http://stackoverflow.com/questions/1057224/thread-is-stuck-while-registering-channel-with-selector-in-java-nio-server

It's not a huge problem for us, because even in an idle situation we eventually receive a NOOP. However, this combined with another bug I was hitting and made it really hard to troubleshoot. I'd suggest we look at ways to avoid this problem.

It's also possible this is a bug in Spy and not the Java client, but I haven't studied how createConnections() is used in other contexts within spy, so it might just be how we use it when reconfiguring from the java client.







[JCBC-292] Missing documentation about delete method with durability option Created: 25/Apr/13  Updated: 06/Sep/13

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.1.5
Fix Version/s: .next
Security Level: Public

Type: Task Priority: Trivial
Reporter: Tug Grall (Inactive) Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The Delete chapter of the documentation does not mention the methods with durability parameter (persistedto and replicatedto)

http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-update-delete.html#table-couchbase-sdk_java_delete

We need to put the same type of content that the one used for the store operation:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-set-durability.html

may be "join/merge" the store and delete?




Generated at Sun Apr 20 11:23:43 CDT 2014 using JIRA 5.2.4#845-sha1:c9f4cc41abe72fb236945343a1f485c2c844dac9.