[JCBC-162] re-enable delete observe against 2.0 server Created: 03/Dec/12  Updated: 03/Dec/12  Resolved: 03/Dec/12

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 1.1-dp3, 1.1-dp4
Fix Version/s: 1.1-beta
Security Level: Public

Type: New Feature Priority: Blocker
Reporter: Matt Ingenthron Assignee: Matt Ingenthron
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
At one point, the observe delete had been disabled on the master branch owing to changes in approach and needing to get a change merged for delete. Once this is complete, we need to revert the change.

See the review for the remove here: http://review.couchbase.org/20918

 Comments   
Comment by Michael Nitschinger [ 03/Dec/12 ]
implemented and pushed to master, will be available in beta.




[JCBC-160] merge in changes from the release10 branch for 1.1beta Created: 03/Dec/12  Updated: 03/Dec/12  Resolved: 03/Dec/12

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 1.1-dp4
Fix Version/s: 1.1-beta
Security Level: Public

Type: Bug Priority: Blocker
Reporter: Matt Ingenthron Assignee: Matt Ingenthron
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
In particular, the fix for JCBC-70 is needed, but there are a couple of changes which need to be merged in

 Comments   
Comment by Michael Nitschinger [ 03/Dec/12 ]
merged, will be available in the beta release.




[JCBC-158] add a debug=true option to view query options Created: 29/Nov/12  Updated: 03/Dec/12  Resolved: 03/Dec/12

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 1.1-dp4
Fix Version/s: 1.1-beta
Security Level: Public

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


 Description   
To be able to diagnose issues that may come up with views, please add a debug=true query parameter. Optionally, we could add a cbclient.properties parameter to be able to turn on view debugging (for all view requests or just some that match a regex?) without code changes (though, with restarts).

 Comments   
Comment by Michael Nitschinger [ 30/Nov/12 ]
http://review.couchbase.org/#/c/22923
Comment by Michael Nitschinger [ 03/Dec/12 ]
pushed to master, will be available in the beta relase.




[JCBC-157] Unsure if CouchbaseConnectionFactory.pastReconnThreshold really does what it's suppose to do Created: 28/Nov/12  Updated: 03/Dec/12  Resolved: 03/Dec/12

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.0.3
Fix Version/s: 1.1-beta
Security Level: Public

Type: Bug Priority: Major
Reporter: Marcus Nylander Assignee: Matt Ingenthron
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Oracle Jdk 1.6.0_26


 Description   
{code}
  private boolean pastReconnThreshold() {
    long currentTime = System.nanoTime();
    if (currentTime - thresholdLastCheck > 100000000) { //if longer than 10 sec
      configThresholdCount = 0; // it's been more than 10 sec since last
                                // tried, so don't try again just yet.
    }
    configThresholdCount++;
    thresholdLastCheck = currentTime;

    if (configThresholdCount >= maxConfigCheck) {
      return true;
    }
    return false;
  }
{code}

Does the above really work as expected? It looks strange. 100000000 in nanos is only 100 millis and not 10 seconds as stated in comments.
If there is more than 100 millis between calls we always reset configThresholdCount and will never return true, which seems very strange.


 Comments   
Comment by Michael Nitschinger [ 28/Nov/12 ]
can you take a look at this?
Comment by Michael Nitschinger [ 29/Nov/12 ]
http://review.couchbase.org/#/c/22902/
Comment by Marcus Nylander [ 29/Nov/12 ]
Checking the fix. Not that I've looked deeply into what pastReconnThreshold() should do, but just increasing the timeout?
Isn't it more like it should return true every maxConfigCheck calls or return true if last call was more than 10 seconds ago?

Comment by Michael Nitschinger [ 03/Dec/12 ]
fixed and pushed to master, will be available in beta.




[JCBC-156] several javadoc warnings emitted Created: 27/Nov/12  Updated: 03/Dec/12  Resolved: 28/Nov/12

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 1.1-beta
Fix Version/s: 1.1-beta
Security Level: Public

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


 Description   
During build of javadoc:

  [javadoc] /Users/ingenthr/src/couchbase-java-client/src/main/java/com/couchbase/client/ClusterManager.java:128: warning - @param argument "memorySize" is not a parameter name.
  [javadoc] /Users/ingenthr/src/couchbase-java-client/src/main/java/com/couchbase/client/ClusterManager.java:143: warning - @param argument "memorySize" is not a parameter name.
  [javadoc] /Users/ingenthr/src/couchbase-java-client/src/main/java/com/couchbase/client/ClusterManager.java:143: warning - @param argument "password" is not a parameter name.
  [javadoc] /Users/ingenthr/src/couchbase-java-client/src/main/java/com/couchbase/client/ClusterManager.java:158: warning - @param argument "memorySize" is not a parameter name.
  [javadoc] /Users/ingenthr/src/couchbase-java-client/src/main/java/com/couchbase/client/ViewConnection.java:199: warning - @return tag has no arguments.

 Comments   
Comment by Michael Nitschinger [ 28/Nov/12 ]
http://review.couchbase.org/#/c/22877/
Comment by Michael Nitschinger [ 28/Nov/12 ]
Fixed, will be available in beta/dp5




[JCBC-155] add javadoc for AbstractView, View, SpatialView Created: 27/Nov/12  Updated: 03/Dec/12  Resolved: 29/Nov/12

Status: Resolved
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.1-dp4
Fix Version/s: 1.1-beta
Security Level: Public

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


 Description   
When fixing up a test after a merge commit, I noted that I had to create a View object directly. In the process, I found that many of these classes are public, have public ctors, but have no javadoc. The client API takes AbstractView as an argument, so it may be tempting to just construct one. Is it correct to do so? Maybe. Javadoc doesn't tell me much.

The arguments to the ctors could also be expanded as they're a bit outside code style. Specifically, variable names should be meaningful and at least three or more characters if the variable is to be around for a while.

 Comments   
Comment by Michael Nitschinger [ 28/Nov/12 ]
http://review.couchbase.org/#/c/22872/
Comment by Michael Nitschinger [ 29/Nov/12 ]
Pushed to master, will be available in dp5/beta.




[JCBC-154] merge in changes from the release11c branch Created: 26/Nov/12  Updated: 03/Dec/12  Resolved: 03/Dec/12

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: None
Fix Version/s: 1.1-beta
Security Level: Public

Type: Bug Priority: Blocker
Reporter: Matt Ingenthron Assignee: Matt Ingenthron
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
When reviewing some changes on the "c" branch, I happened to notice there may be one change that hasn't been submodule merged

Upon further inspection, it looks like a few other changes haven't been merged either. We'll need to merge this branch back in.

 Comments   
Comment by Michael Nitschinger [ 29/Nov/12 ]
You already did the work, so assigning it to you.
Comment by Matt Ingenthron [ 03/Dec/12 ]
http://review.couchbase.org/#/c/22973/
Comment by Michael Nitschinger [ 03/Dec/12 ]
merged into master, available in beta.




[JCBC-153] Raise view timeout from 60s to 75s Created: 21/Nov/12  Updated: 03/Dec/12  Resolved: 27/Nov/12

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1-dp4
Fix Version/s: 1.1-beta
Security Level: Public

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


 Description   
Since the server side view timeout is 60s, we should raise the client side a bit higher. 75s seems like the right number. It should be tuneable though.

 Comments   
Comment by Michael Nitschinger [ 22/Nov/12 ]
http://review.couchbase.org/#/c/22755/
Comment by Michael Nitschinger [ 27/Nov/12 ]
Pushed to master, will be available in dp5/beta.




[JCBC-152] Document testing procedures for unit/functional tests Created: 21/Nov/12  Updated: 03/Dec/12  Resolved: 29/Nov/12

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1-dp4
Fix Version/s: 1.1-beta
Security Level: Public

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

Issue Links:
Dependency

 Description   
It would be good to have clear documentation in the repo about how to:

(1) run individual tests
(2) change cluster parameters
(3) write more tests

This might be trivial or obvious to do, but very much needed.

For an example of what should be available, see:

(This does not say how to run individual tests though)
https://github.com/couchbase/libcouchbase#run-the-testsuite-towards-a-running-cluster

A more extensive example for a more complex test suite:
https://github.com/couchbase/php-ext-couchbase/blob/master/TESTING.pod

I'm marking this as a 'library' bug because this would require some detailed knowledge of how the tests are written :)

 Comments   
Comment by Michael Nitschinger [ 28/Nov/12 ]
http://review.couchbase.org/#/c/22874/
Comment by Michael Nitschinger [ 29/Nov/12 ]
This has been fixed and is available under TESTING.md in the lib.




[JCBC-148] Issue with Observe API Persist.TWO and 1 dead node: Time Out when doing set operation Created: 18/Nov/12  Updated: 03/Dec/12  Resolved: 03/Dec/12

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1-dp4
Fix Version/s: 1.1-beta
Security Level: Public

Type: Bug Priority: Critical
Reporter: Tug Grall (Inactive) Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: 2 nodes cluster on couchbase-server-community_x86_2.0.0-1947-rel
  1 node on Ubuntu (VM)
  1 node on OS X

Bucket configure with 1 replica

Attachments: Zip Archive CouchbaseSamples.zip    

 Description   
I have a very simple Java program that connect to the 2 nodes and do a set with the following code:

1. So I try to connect to multiple nodes
{code}
            List<URI> couchbaseServerUris = new ArrayList<URI>();
            couchbaseServerUris.add( new URI("http://192.168.0.108:8091/pools") );
            couchbaseServerUris.add( new URI("http://192.168.0.104:8091/pools") );
            CouchbaseClient client = new CouchbaseClient( couchbaseServerUris , "default" , "" );
{code}

2. Then I call the set operation
{code}

        OperationFuture<Boolean> stored = client.set( "my-dummy-key",0, "{\"name\" : \"foo\", \"title\" : \"bar-test\"}", PersistTo.TWO);
{code}

---
So everything is working as expected when the 2 nodes are up.

When I kill 1 node (for example : disconnecting, or stopping, or pausing the Ubuntu VM) I have the following behavior:


When I execute this program:
1- I have an exception saying that 1 node is down : Expected behavior (even if we could avoid a long stack trace)
{code}
2012-11-18 08:14:55.830 WARN com.couchbase.client.vbucket.ConfigurationProviderHTTP: Connection problems with URI http://192.168.0.108:8091/pools ...skipping
java.net.ConnectException: Host is down
{code}


2- When I do the set the program is stopped/blocked until it reaches a network timeout
2012-11-18 08:20:13.462 INFO com.couchbase.client.CouchbaseConnection: Shut down Couchbase client
{code}
Error while storing : Observe Timeout - Polled Unsuccessfully for at least 40 seconds.
2012-11-18 08:20:13.466 INFO done : true
done : {OperationStatus success=false: Observe Timeout - Polled Unsuccessfully for at least 40 seconds.}
com.couchbase.client.ViewNode: Couchbase I/O reactor terminated
2012-11-18 08:20:13.467 INFO com.couchbase.client.ViewNode: Couchbase I/O reactor terminated
{code}


Note that it is only happening with PersistTo.TWO
if I use PersistTo.MASTER or PersistTo.ONE : the program is executed with no error and no stop
if I use PersistTo.THREE ( or more) : the program is executed, no stop with the expected observe message : ( Error while storing : Requested persistence to 3 node(s), but only 2 are available.
 )




 Comments   
Comment by Tug Grall (Inactive) [ 18/Nov/12 ]
Sample program
Comment by Matt Ingenthron [ 20/Nov/12 ]
I do believe that's actually expected behavior, but let's talk through it to get your opinion.

We have a couple of options in the state of unexpected failure. one is we try our hardest to get the operation requested of us done and we rely on timeouts to keep from blocking forever. The second is that we keep tabs on our connections, and if the connection is down, we fail operations immediately so as to not have the application code waiting for something that may or may not succeed.

Had you gone in and removed the second node (click 'remove' and 'rebalance'), then the client should have done something similar to when you requested three nodes. The failure you describe above is unexpected. Further, the client library doesn't really know if it's temporary or permanent.

Finally, I do want to note, and I think this is well documented, that many things with Observe protocol under them end in timeouts. This is not the only one. Generally speaking, application code should be ready to do *something* in the case of a timeout.
Comment by Matt Ingenthron [ 20/Nov/12 ]
Tug explained this further. The PersistTo.THREE check must be happening after doing some operations, which is a bit late considering this operation can never succeed. The failure should be the same with a cluster that has a down node as it is with a cluster that just doesn't have a primary and to replica locations.
Comment by Mike Wiederhold [ 21/Nov/12 ]
The way Rags wrote this code originally was to do the set and then the observe. The observe part is the part that does all of the checking so the set will actually go through an then you will get the error. Similarly there is no checking for downed nodes and I don't think we actually have the ability to do this at the moment, but I may be wrong.

On another note, one other thing I thing is wrong is returning an OperationFuture from all of the observe functions, but it isn't actually an asynchronous function.
Comment by Michael Nitschinger [ 30/Nov/12 ]
http://review.couchbase.org/#/c/22936/
Comment by Michael Nitschinger [ 03/Dec/12 ]
fixed and will be available in the beta release.




[JCBC-147] Rename getViews() to getDesignDocument() Created: 14/Nov/12  Updated: 03/Dec/12  Resolved: 03/Dec/12

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1-dp4
Fix Version/s: 1.1-beta
Security Level: Public

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

Issue Links:
Dependency
blocks JCBC-63 add APIs for creating and deleting de... Resolved

 Description   
The getViews() method should be renamed to getDesignDocument() before the API is stable. This is also in preparation for the createDesignDocument() and deleteDesignDocument() additions.

 Comments   
Comment by Michael Nitschinger [ 21/Nov/12 ]
http://review.couchbase.com/#/c/22713/
Comment by Matt Ingenthron [ 03/Dec/12 ]
This breaks API over DP, and should be release noted.
Comment by Michael Nitschinger [ 03/Dec/12 ]
fixed and merged into master, will be available in beta!




[JCBC-142] Observe Tests show that something is wrong in the observe impl Created: 08/Nov/12  Updated: 03/Dec/12  Resolved: 27/Nov/12

Status: Closed
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1-dp4
Fix Version/s: 1.1-beta
Security Level: Public

Type: Bug Priority: Blocker
Reporter: Michael Nitschinger Assignee: Mike Wiederhold
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File observe-test.php    

 Description   
The newly added observe viewtests show that sometimes the full result sets are returned and sometimes not. This strongly correlates with the number of sets done in a given timeframe so I suppose the current observe implementation has a bug somewhere.

Also, the observe test inside the CouchbaseClient fails sometime which may correlate to the same issue.

 Comments   
Comment by Michael Nitschinger [ 09/Nov/12 ]
This is the test to reproduce it: https://github.com/couchbase/couchbase-java-client/commit/df5b6a53bbd61ca8daf64d56919e79d81870355e
(you may have to increase the amount of sets to be done to make sure the disk queue takes some time to get flushed)
Comment by Michael Nitschinger [ 09/Nov/12 ]
Please reproduce with another client and assign it back to me if it appears to be a client library issue.

thanks!
Comment by Mark Nunberg [ 09/Nov/12 ]
I've tried to replicate this in PHP, but without success.

It sounds like the observe operation is failing and therefore the view is returning bad results. I'm not familiar with the Java API, but the set+persist wouldn't throw an exception if it fails - you'd need to check the future.getStatus().isSuccess() or something.

I'm pasting a very ad-hoc test that I've written for PHP (more comments will be inline with that)
Comment by Mark Nunberg [ 09/Nov/12 ]
Update:

I've re-run the tests with a two node cluster. I see similar behavior. This looks like a server bug.
Comment by Mark Nunberg [ 09/Nov/12 ]
Michael, can you modify the test code to check for observe exceptions (and in general make it function more similarly to the php code).

This way we can have confident confirmation from both clients, and file a server bug

Failed observe does not throw an exception, as per

https://github.com/couchbase/couchbase-java-client/blob/df5b6a53bbd61ca8daf64d56919e79d81870355e/src/main/java/com/couchbase/client/CouchbaseClient.java#L909

(From then same revision linked to in the description).
Comment by Mark Nunberg [ 09/Nov/12 ]
I've actually revised the tests to work the way I needed them to.. (for some reason the observe in java is slower than I had hoped for, so I ended up making my own threaded contraption to solve this...) -- might this be a separate bug?

anyway.. I've observed duplicate behavior:

Basically, many of the times, the stale test fails, returning *exactly* half of the keys in the view.

Maybe my cluster config is funky, but this is doubtful..

Anyway, we'll file a cluster bug with a 100% certainty that this is a client issue.

btw, I'd actually advocate keeping the threaded contraption there (in the commit I accidentally saved it as a single worker, might want to bump it up)..

Placing load on the server (i.e. by using multiple setter threads) seems to highlight this issue.. and I have a feeling it's a lag/race condition sort of thing.

https://github.com/mnunberg/couchbase-java-client/commit/3d788ab9d3a88c1dc20717c4dd110e3a8bb5f5bc
Comment by Mark Nunberg [ 09/Nov/12 ]
java.lang.AssertionError: expected:<500> but was:<180>
at org.junit.Assert.fail(Assert.java:91)
at org.junit.Assert.failNotEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:126)
at org.junit.Assert.assertEquals(Assert.java:470)
at org.junit.Assert.assertEquals(Assert.java:454)
at com.couchbase.client.ViewTest.testObserveWithStaleFalse(ViewTest.java:839)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Comment by Matt Ingenthron [ 13/Nov/12 ]
Note that this one is being worked by the server team, since it looks like a server issue. No action needed here at the moment.
Comment by Michael Nitschinger [ 14/Nov/12 ]
Is there a ticket we can link to?
Comment by Matt Ingenthron [ 19/Nov/12 ]
Mike had been in here earlier today and thinks he knows where the issue is, so passing assignment to him.
Comment by Michael Nitschinger [ 21/Nov/12 ]
Fixed and pushed to master, will be available in dp5!
Comment by Michael Nitschinger [ 21/Nov/12 ]
Looks like this is still not solved, from time to time the test still shows missing documents!
Comment by Michael Nitschinger [ 27/Nov/12 ]
Test case was flawed, now fixed and pushed.




[JCBC-141] Graceful Shutdown Test fails on dp4 Created: 07/Nov/12  Updated: 03/Dec/12  Resolved: 08/Nov/12

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1-dp4
Fix Version/s: 1.1-beta
Security Level: Public

Type: Bug Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The gracefulShutdown test on the CouchbaseClient fails.

More inspection needed before we hit a stable release!

 Comments   
Comment by Michael Nitschinger [ 08/Nov/12 ]
I quickly re-checked and it works on master. Instead, some of the observe tests fail for which I'll reopen a new JCBC ticket.




[JCBC-139] 'delete & persist' and' delete, persist and replicate' functionalities not supported in 1.1-dp3 SDK. Created: 07/Nov/12  Updated: 14/Nov/12  Resolved: 14/Nov/12

Status: Resolved
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.1-dp3
Fix Version/s: 1.1-beta
Security Level: Public

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


 Description   
couchbase-sdk-java-1.0 Manual has presented the usage specific to the 'delete & persist' and' delete, persist and replicate' functionalities but the SDK API's dont support this functionality due to an ongoing defect in the the couchbase server. Similar issue is there with the 'set and persist' and 'set and replicate' functionalities.
The manual needs to be updated accordingly.

 Comments   
Comment by Deepti Dawar [ 07/Nov/12 ]
The Github link for reference, depicting this change is as follows -
https://github.com/couchbase/couchbase-java-client/commit/f5603e21c7cbf94d4804e01688c1160375dae418
Comment by Michael Nitschinger [ 14/Nov/12 ]
Pulled into the main repo by the docs team, will be available in a few minutes in the official docs.




[JCBC-136] Add support for spatial view queries Created: 29/Oct/12  Updated: 03/Dec/12  Resolved: 21/Nov/12

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1-dp3, 1.1-dp4
Fix Version/s: 1.1-beta
Security Level: Public

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

Issue Links:
Dependency
blocks JCBC-146 Paginator should support reduced views. Resolved

 Description   
Add query support for spatial views.

 Comments   
Comment by Michael Nitschinger [ 06/Nov/12 ]
http://review.couchbase.org/#/c/22308/
Comment by Michael Nitschinger [ 15/Nov/12 ]
Update: http://review.couchbase.org/#/c/22563/
Comment by Michael Nitschinger [ 21/Nov/12 ]
Implemented and pushed to master, will be available in dp5.




[JCBC-133] ViewFuture timeout not passed through to multiget Created: 19/Oct/12  Updated: 06/Nov/12  Resolved: 06/Nov/12

Status: Closed
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1-dp3
Fix Version/s: 1.1-beta
Security Level: Public

Type: Bug Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
In the ViewFuture, the get() method accepts a timeout but it is not passed down to the mutligetRef call (which would also accept one). In this case, some operations may be stuck in there for longer than needed.

Here is a potential fix that came up:

com.couchbase.client.internal.ViewFuture.java
public ViewResponse get(long duration, TimeUnit unit)
throws InterruptedException, ExecutionException, TimeoutException {
....
Map<String, Object> docMap = multigetRef.get().get(); => Map<String, Object> docMap = multigetRef.get(duration, units);
Final ViewResponseWithDocs view = (ViewResponseWithDocs) objRef.get();
Collection<ViewRow> rows = new LinkedList<ViewRow>();
...

 Comments   
Comment by Michael Nitschinger [ 06/Nov/12 ]
We already use a timeout in there.




[JCBC-125] Don't cast view documents to strings Created: 03/Oct/12  Updated: 03/Dec/12  Resolved: 08/Nov/12

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1-dp4
Fix Version/s: 1.1-beta
Security Level: Public

Type: Bug Priority: Critical
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: view
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: All


 Description   
When objects are stored as non-strings in Couchbase and then loaded through a View, the SDK currently casts every document to a string. This works fine for JSON documents, but as soon as you want to store serialized objects it breaks.

Implicit casting is not needed in this place (see fix).

 Comments   
Comment by Michael Nitschinger [ 03/Oct/12 ]
Here is a quick sample on how to reproduce it, but I'm adding a correct test case to the code as well (the view used is just the default "emit key and null" view with no reduce).


import com.couchbase.client.CouchbaseClient;
import com.couchbase.client.CouchbaseConnectionFactory;
import com.couchbase.client.protocol.views.Query;
import com.couchbase.client.protocol.views.View;
import com.couchbase.client.protocol.views.ViewResponse;
import com.couchbase.client.protocol.views.ViewRow;
import java.io.IOException;
import java.net.URI;
import java.util.Arrays;
import java.util.Date;
import java.util.Iterator;


public class BinaryviewTest {

  /**
   * @param args the command line arguments
   */
  public static void main(String[] args) throws IOException {

    // Initialize Connection
    CouchbaseClient cb = new CouchbaseClient(
      new CouchbaseConnectionFactory(
        Arrays.asList(
          URI.create("http://192.168.1.105:8091/pools")
        ),
        "default",
        ""
      )
    );

    // Store binary objects
    Object ob1 = new Date();
    cb.set("date1", 0, ob1);

    Object result = cb.get("date1");
    System.out.println(result.getClass());

    Query query = new Query();
    query.setIncludeDocs(true);
    View view = cb.getView("testing", "binary");
    ViewResponse response = cb.query(view, query);

    Iterator<ViewRow> iterator = response.iterator();
    ViewRow row;
    while(iterator.hasNext()) {
      row = iterator.next();
      Object obj = row.getDocument();
      System.out.println(obj.getClass());
    }
    cb.shutdown();
  }
}

When run two times, this raises the exception as described here: http://www.couchbase.com/forums/thread/couchbase-2-view-non-json-docs

I'll update it when I have the fix and test ready.
Comment by Michael Nitschinger [ 03/Oct/12 ]
See http://review.couchbase.com/#/c/21305/
Comment by Michael Nitschinger [ 08/Nov/12 ]
pushed to master, will be available in dp5.




[JCBC-124] Cannot operate on keys with spaces in them Created: 02/Oct/12  Updated: 09/Oct/12  Resolved: 09/Oct/12

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: None
Fix Version/s: 1.1-beta
Security Level: Public

Type: Bug Priority: Major
Reporter: Aaron Miller (Inactive) Assignee: Michael Nitschinger
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The other clients allows keys with spaces in them, such as "test key", but there is no way to operate on these using the Java client.

myclient.set("test key", 0, "test value");

java.lang.IllegalArgumentException: Key contains invalid characters: ``test key''
at net.spy.memcached.util.StringUtils.validateKey(StringUtils.java:79)
at net.spy.memcached.MemcachedConnection.enqueueOperation(MemcachedConnection.java:639)
at net.spy.memcached.MemcachedClient.asyncStore(MemcachedClient.java:300)
at net.spy.memcached.MemcachedClient.set(MemcachedClient.java:733)

 Comments   
Comment by Matt Ingenthron [ 04/Oct/12 ]
At the moment, we'll need to see if allowing keys with spaces are intended to be supported. Earlier discussion with folks indicated it was not intended to be supported.
Comment by Aaron Miller (Inactive) [ 05/Oct/12 ]
Well, this is really an issue with spymemcached, as it's incorrectly applying ASCII protocol key restrictions over binary protocol.

If we have extra key restrictions in Couchbase, those should probably be handled in the Couchbase client. I believe the approach we're using in Couchbase was that you could -insert- whatever you want, since there are lots of memcached clients out there that will be used, and community libraries and such, and that UTF-8 keys were required for your item to be picked up by views.

As it stands today the libcouchbase-based clients can insert items that the java client cannot touch, which makes using the java client with other clients in the same system very likely to cause frustration if they run into this problem.
Comment by Michael Nitschinger [ 08/Oct/12 ]
http://review.couchbase.com/#/c/21323/
That's a good one Aaron, I'll test that and abandon my changeset.
Comment by Mike Wiederhold [ 08/Oct/12 ]
Aaron,

This has been an open argument on the Java SDK for some time. The reason that we don't allow spaces in the key names is so that Java users can switch between ascii and binary connections and still have their applications function correctly. I think the correct thing to do here would be to add an option in the connection factory to enable the use of keys with spaces in binary protocol.
Comment by Aaron Miller (Inactive) [ 08/Oct/12 ]
That seems silly, because as it stands right now they cannot switch from another language to Java and have it work correctly, nor do what I'm trying to do, which is attempting to interoperate with another piece of software that I did not write that uses a different language's SDK, since the other language SDKs allow spaces. Once we have a JRuby client based on this java client ready, they wouldn't even be able to switch from Ruby to JRuby.

I don't see a compelling reason for the Java client to behave differently from other clients, and if somebody is tripped up in this manner the fix would be simply to use the binary protocol. It doesn't seem worth breaking interoperability over.
Comment by Mike Wiederhold [ 09/Oct/12 ]
Duplicate of SPY-63.




[JCBC-123] ArrayOutOfBounds exception during failover Created: 02/Oct/12  Updated: 03/Dec/12  Resolved: 09/Nov/12

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 1.0.3
Fix Version/s: 1.1-beta
Security Level: Public

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

Issue Links:
Duplicate
is duplicated by JCBC-46 DefaultConfigFactory attempts to crea... Closed

 Description   
While running a sequence of getsAsync operations, the entry point/bootstrap node is failed over. The output follows


Exception in thread "SDK Handle-8" java.lang.ArrayIndexOutOfBoundsException: -1
        at java.util.ArrayList.elementData(ArrayList.java:338)
        at java.util.ArrayList.get(ArrayList.java:351)
        at com.couchbase.client.vbucket.config.DefaultConfig.getServer(DefaultConfig.java:81)
        at com.couchbase.client.vbucket.VBucketNodeLocator.getPrimary(VBucketNodeLocator.java:74)
        at com.couchbase.client.CouchbaseConnection.addOperation(CouchbaseConnection.java:144)
        at net.spy.memcached.MemcachedConnection.enqueueOperation(MemcachedConnection.java:639)
        at net.spy.memcached.MemcachedClient.asyncGets(MemcachedClient.java:888)
        at net.spy.memcached.MemcachedClient.asyncGets(MemcachedClient.java:902)
        at com.couchbase.sdkd.cbclient.GetCommandContext.doOneCommand(GetCommandContext.java:60)
        at com.couchbase.sdkd.cbclient.CommandContext.execute(CommandContext.java:266)
        at com.couchbase.sdkd.server.SdkServer.executeCommand(SdkServer.java:114)
        at com.couchbase.sdkd.server.SdkServer.handleRequest(SdkServer.java:133)
        at com.couchbase.sdkd.server.SdkServer.run(SdkServer.java:187)


 Comments   
Comment by Matt Ingenthron [ 05/Oct/12 ]
This may fall into rewriting the configuration handling. I'll discuss this more with Michael as needed.
Comment by Michael Nitschinger [ 15/Oct/12 ]
Hey Mark,

can you check if this also happens against the dp3 release? I saw that the sdkd-java builds against the stable release.

Thanks!
Comment by Michael Nitschinger [ 08/Nov/12 ]
Tracked here: http://review.couchbase.org/#/c/22352/
Comment by Michael Nitschinger [ 09/Nov/12 ]
An exception is now raised, because a vbucket master of -1 means that no server is able to respond for the given key. This is a strong indication of data loss. This could be the case because no replica was defined and a node was failed over or more nodes have been failed over than replicas defined.

Either way, the client itself has no chance of dealing with the situation and therefore populates a controlled exception up to the caller.

The fix has been pushed to master and will be available in dp5.




[JCBC-122] Unit tests are broken Created: 28/Sep/12  Updated: 03/Dec/12  Resolved: 08/Nov/12

Status: Closed
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 1.1-beta
Security Level: Public

Type: Bug Priority: Major
Reporter: Mike Wiederhold Assignee: Mike Wiederhold
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The new test admin interface that was added does not work at all for me when I try to run the unit tests. Server reports 503 errors when trying to recreate a bucket. I suspect this is because we try to do things when the bucket is not fully created yet.

 Comments   
Comment by Michael Nitschinger [ 16/Oct/12 ]
Hey Mike,

is this still relevant or how can I reproduce this?

Thanks ;)
Comment by Mike Wiederhold [ 16/Oct/12 ]
Yes this is still a valid issue, but it has to do with the fact that we don't handle bucket creation and deletion properly in the tests. Part of the problem here is also the server. Please work on your other issues and we can discuss this later.
Comment by Michael Nitschinger [ 06/Nov/12 ]
tracked here: http://review.couchbase.com/#/c/22058/
Comment by Michael Nitschinger [ 08/Nov/12 ]
Has been pushed to master, will be available in dp5.




[JCBC-118] Improve the docs for observe around the ReplicateTo flag Created: 25/Sep/12  Updated: 26/Sep/12  Resolved: 26/Sep/12

Status: Resolved
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: None
Fix Version/s: 1.1-beta
Security Level: Public

Type: Improvement Priority: Major
Reporter: Mike Wiederhold Assignee: Raghavan Srinivas (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

See the comment to my response of this question.

http://stackoverflow.com/questions/12521102/in-couchbases-observe-feature-what-is-the-difference-between-persistto-and/12521346#comment16856063_12521346


 Comments   
Comment by Raghavan Srinivas (Inactive) [ 26/Sep/12 ]
I have generated a pull request to have this fixed.




[JCBC-103] Java client 1.1-dp not returning documents when querying views Created: 20/Aug/12  Updated: 09/Oct/12  Resolved: 09/Oct/12

Status: Closed
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1dp
Fix Version/s: 1.1-beta
Security Level: Public

Type: Bug Priority: Major
Reporter: Tim Pedersen Assignee: Michael Nitschinger
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: OSX
Couchbase Server 2.0.0dp4r-730-rel
Java client 1.1-dp


 Description   
I'm using the Java 1.1-dp client to do queries against views. Setting query.setIncludeDocs(true) doesn't actually result in the query ViewResponse having documents (ViewRow.getDocument() returns null).

Digging into the code, it looks like that the Query class doesn't actually set the "include_docs" parameter, nor does DocsOperationImpl.parseResult try to extract the "doc" element from the returned JSON.

Is this deliberate? Or am I missing something? I'd really prefer not having to make a separate call to get the docs while iterating through a ViewResponse.

 Comments   
Comment by Tim Pedersen [ 20/Aug/12 ]
This issue is caused when I use CouchbaseConnectionFactoryBuilder to create clients. See JCBC-102

If I use CouchbaseConnectionFactory instead ViewRow.getDocument() returns the document correctly.
i.e:

   URI base = new URI(String.format("http://%s:8091/pools", server));
   List<URI> baseURIs = new ArrayList<URI>();
   baseURIs.add(base);
   CouchbaseConnectionFactoryBuilder cfb = new CouchbaseConnectionFactoryBuilder();
   cfb.setOpTimeout(10000);
   cfb.setOpQueueMaxBlockTime(10000);
   CouchbaseConnectionFactory cf = cfb.buildCouchbaseConnection(baseURIs, bucket, "", "");
   CouchbaseClient client = new CouchbaseClient(cf);
  //...
   View view = client.getView(myDesignDoc, myView);
   Query query = new Query();
    query.setRange(start, end);
    query.setIncludeDocs(true);
           ViewResponse viewResponse = client.query(view, query);
            for(ViewRow viewRow:viewResponse){
                String id = viewRow.getId(); // id ok
                String key = viewRow.getKey(); // key ok
                String value = viewRow.getValue(); // value ok
                String doc = (String) viewRow.getDocument(); // doc is null
            }

VERSUS:

        URI base = new URI(String.format("http://%s:8091/pools", server));
        List<URI> baseURIs = new ArrayList<URI>();
        baseURIs.add(base);
        CouchbaseConnectionFactory cf = new CouchbaseConnectionFactory(baseURIs, bucket, "");
        CouchbaseClient client = new CouchbaseClient(cf);
 //...
   View view = client.getView(myDesignDoc, myView);
   Query query = new Query();
    query.setRange(start, end);
    query.setIncludeDocs(true);
           ViewResponse viewResponse = client.query(view, query);
            for(ViewRow viewRow:viewResponse){
                String id = viewRow.getId(); // id ok
                String key = viewRow.getKey(); // key ok
                String value = viewRow.getValue(); // value ok
                String doc = (String) viewRow.getDocument(); // doc ok
            }





Comment by Michael Nitschinger [ 04/Oct/12 ]
I'm also not able to reproduce this agains the master branch and the beta release of Couchbase Server 2.0 beta.

I tested it against the beer sample, can you check if this works for you or not?

    CouchbaseConnectionFactoryBuilder cfb = new CouchbaseConnectionFactoryBuilder();
    cfb.setOpTimeout(10000);
    cfb.setOpQueueMaxBlockTime(10000);

    CouchbaseConnectionFactory cf = cfb.buildCouchbaseConnection(Arrays.asList(
      URI.create("http://&lt;HOST&gt;:8091/pools")
    ), "beer-sample", "");

    CouchbaseClient client = new CouchbaseClient(cf);

    Query query = new Query().setIncludeDocs(true);
    View view = client.getView("beer", "brewery_beers");
    ViewResponse response = client.query(view, query);
    for(ViewRow row : response) {
      System.out.println(row.getDocument());
    }

    client.shutdown();
Comment by Michael Nitschinger [ 09/Oct/12 ]
Since this ticket is older and I couldn't reproduce it with the information provided, I'll close this ticket.

If you still encounter this issue with the current release, feel free to reopen this ticket or a new one.

Thanks,
Michael




[JCBC-100] view query handling should be more reliable, have better error handling Created: 18/Aug/12  Updated: 17/Oct/12  Resolved: 09/Oct/12

Status: Closed
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1dp2, 1.1.0
Fix Version/s: 1.1-beta
Security Level: Public

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


 Description   
In sections of CouchbaseClient, like asyncQueryAndIncludeDocs(), the error handling for views and queries is currently a set of assertions. This section should be more reliable, perhaps throw a checked exception from initially referencing the view and a runtime exception from queries which find views don't exist.

 Comments   
Comment by Michael Nitschinger [ 04/Oct/12 ]
This issue is handled in changeset http://review.couchbase.com/#/c/21338/




[JCBC-99] Java 1.1 DP exception on failed auth Created: 16/Aug/12  Updated: 13/Nov/12  Resolved: 13/Nov/12

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1dp2
Fix Version/s: 1.1-beta
Security Level: Public

Type: Bug Priority: Major
Reporter: Perry Krug Assignee: Matt Ingenthron
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File couchbasetrace.txt    

 Description   
Stack trace attached. Looks like a few different failures around multi-gets, there are some incomplete binary ops and failed authentications (alongside successful authentications, so I presume the user/pass is actually correct).

 Comments   
Comment by Michael Nitschinger [ 09/Nov/12 ]
Perry, do you have code around this stack trace?

I wonder whats going on here because of so many connects and reconnects - I guess the failed bulk get has to do with it.

The problem is that - at least to me - the stack trace doesn't show much information that hints to a defect in the SDK. If you have more meat I'll be happy to look at it!
Comment by Michael Nitschinger [ 13/Nov/12 ]
Hey,

Perry told me that he has not more information regarding this ticket. To me this doesn't look like an issue in the first place, more like a weird network thing.

I'd like to close it and reopen it when a specific issue pops up, but feel free to pass it back to me when you think we need to take action on this. Thanks!
Comment by Matt Ingenthron [ 13/Nov/12 ]
Unfortunately, there's not enough info here to indicate an issue. If more info becomes available, please re-open.




[JCBC-98] Multiple exceptions thrown on Shutdown() Created: 14/Aug/12  Updated: 03/Dec/12  Resolved: 09/Nov/12

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 1.1-beta
Security Level: Public

Type: Bug Priority: Minor
Reporter: James Mauss Assignee: Michael Nitschinger
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The following exceptions are thrown when a CouchbaseClient calls shutdown()

java.io.IOException: No IO while shut down
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:201)
at com.couchbase.client.CouchbaseConnection.run(CouchbaseConnection.java:230)

This can easily be seen when logging is enabled.

 Comments   
Comment by Michael Nitschinger [ 08/Nov/12 ]
In general, this kind of exception thrown during shutdown is fine and is only logged in debug mode.

Matt, I see two options here:

- Leave it as is, the exception is only logged as debug.

- we wrap the run() loop currently with if(!reconfiguring), maybe wen can also add && !shutDown? Or does this infer with the shutdown procedure?

Thanks,
Michael
Comment by Matt Ingenthron [ 08/Nov/12 ]
I think the current behavior is correct. We want our IO thread to not do any new IO while shutting down. Someone called shutdown either immediate, or with a time value and there was more IO to be done, so we're logging that we're not doing it.
Comment by Michael Nitschinger [ 09/Nov/12 ]
I'm closing this after discussion that the current behavior is correct.

IO during shutdown is not accepted but the log message should do no harm in that case. Thats why its printed as debug and not as a warning.




[JCBC-94] Shutdown function does not shutdown ViewConnection Thread Created: 02/Aug/12  Updated: 03/Dec/12  Resolved: 08/Nov/12

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 1.1-beta
Security Level: Public

Type: Bug Priority: Major
Reporter: James Mauss Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: 1.0.3


 Description   
The patch (ViewConnection.java) in the bug http://www.couchbase.com/issues/browse/JCBC-26 fixed the dead loop issue, but it introduced another Shutdown issue.
when calling the shutdown function of CouchbaseClient, it could not shutdown the thread of the ViewConnection.

Public void run() {
While(running) {
If (!reconfiguring) {
Synchronized(threadLock)
{
Boolean hasOps = false;
While(!hasOps) { ==> While(!hasOps && running)
For (viewNode node: couchNodes) {
If (node.hasWriteOps()) {
hasOps = true;
break;
}
}
......
If (!hasOps)
{
threadLock.wait();
}
}
}
If (running) {
handleIO();
}

 Comments   
Comment by Mike Wiederhold [ 14/Sep/12 ]
Duplicate of JCBC-96.
Comment by Michael Nitschinger [ 02/Oct/12 ]
I guess there is something I need to look into - I'm going to verify that soon and report my findings!
Comment by Michael Nitschinger [ 03/Oct/12 ]
I started tracking this down today. See the progress of it here: http://review.couchbase.com/#/c/21301/

I'll update this ticket as soon as the problem is reliably detected.
Comment by Michael Nitschinger [ 08/Nov/12 ]
pushed to master, will be available in dp5.




[JCBC-92] Java error when a node is removed - need to check for pending state on a bucket Created: 01/Aug/12  Updated: 03/Dec/12  Resolved: 09/Nov/12

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1dp
Fix Version/s: 1.1-beta
Security Level: Public

Type: Bug Priority: Major
Reporter: Raghavan Srinivas (Inactive) Assignee: Raghavan Srinivas (Inactive)
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
This is related to CBSE-187.

While the test was running we removed a node from the cluster, there were failures due to operation cancelled and TimeoutException and the test didn't continue.
Then we started the test again without adding back the removed node, it just threw:
       java.lang.ArrayIndexOutOfBoundsException: -1
at java.util.ArrayList.get(Unknown Source)
at com.couchbase.client.vbucket.config.DefaultConfig.getServer(DefaultConfig.java:81)
at com.couchbase.client.vbucket.VBucketNodeLocator.getPrimary(VBucketNodeLocator.java:74)
at com.couchbase.client.CouchbaseConnection.addOperation(CouchbaseConnection.java:143)
at net.spy.memcached.MemcachedConnection.enqueueOperation(MemcachedConnection.java:639)
at net.spy.memcached.MemcachedClient.asyncStore(MemcachedClient.java:296)
at net.spy.memcached.MemcachedClient.set(MemcachedClient.java:727)
<supressed>

 Comments   
Comment by Michael Nitschinger [ 09/Nov/12 ]
This is a duplicate of JCBC-123 which has been pushed to master recently.

See the description of the ticket for more details.




[JCBC-91] NPE when using malformed URI Created: 01/Aug/12  Updated: 13/Sep/12  Resolved: 13/Sep/12

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.0.3
Fix Version/s: 1.1-beta
Security Level: Public

Type: Bug Priority: Major
Reporter: Perry Krug Assignee: Raghavan Srinivas (Inactive)
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Caused by: java.lang.NullPointerException
at com.couchbase.client.CouchbaseConnectionFactory.getVBucketConfig(CouchbaseConnectionFactory.java:154)
at com.couchbase.client.CouchbaseClient.<init>(CouchbaseClient.java:156)
at com.couchbase.client.CouchbaseClient.<init>(CouchbaseClient.java:125)
at com.couchbase.client.CouchbaseClient.<init>(CouchbaseClient.java:77)
at com.playtika.pool.membase.MembasePool.start(MembasePool.java:55)
... 48 more




Would prefer a more meaningful error or exception to indicate that the URI was incorrect

 Comments   
Comment by Raghavan Srinivas (Inactive) [ 13/Sep/12 ]
Same as JCBC-18




[JCBC-90] Views force numeric strings to be intergers Created: 31/Jul/12  Updated: 04/Oct/12  Resolved: 04/Oct/12

Status: Closed
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 1.1-beta
Security Level: Public

Type: Bug Priority: Major
Reporter: James Mauss Assignee: Matt Ingenthron
Resolution: Duplicate Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
When using a view that reads a string that starts with an integer: ie date:
2012-07-30T03:26:12+00:00

From the client you are unable to request a startkey by year as it is sent as an integer in the URL request
query.setRangeStart("2000");

This will be translated as:
startkey=2000

But the request needs to be startkey="2000" for the comparison to work against a stored string.

This also causes requests for query.setRangeStart("0000"); to fail as 0000 is not a valid number.

The client should allow the developer to pick which JSON type they want to send.



 Comments   
Comment by Tim Smith (Inactive) [ 17/Aug/12 ]
This is a duplicate of JCBC-41 .
Comment by Michael Nitschinger [ 04/Oct/12 ]
I'll close this because it is tracked through JCBC-41.




[JCBC-86] Remove getHashAlgorithm and verify correct behavior of client Created: 20/Jul/12  Updated: 03/Dec/12  Resolved: 21/Nov/12

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 1.1-beta
Security Level: Public

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


 Description   
Current CacheConfig class has a getHashAlgorithm method and it seems to define native hash. Since there don't seem to be any uses of this, it should be removed or somehow refactored out.

 Comments   
Comment by Michael Nitschinger [ 15/Nov/12 ]
Investigations show that the getHashAlgorithm() is defined by the Cache interface, but actually never used throughout the codebase.

michael@daschlbook ~/couchbase/couchbase-java-client $ grep -r 'getHashAlgorithm()' src/*
src/main/java/com/couchbase/client/vbucket/config/CacheConfig.java: public HashAlgorithm getHashAlgorithm() {
src/main/java/com/couchbase/client/vbucket/config/Config.java: HashAlgorithm getHashAlgorithm();
src/main/java/com/couchbase/client/vbucket/config/DefaultConfig.java: public HashAlgorithm getHashAlgorithm() {

Also, the CacheConfig never makes use of its defined hashAlgorithm. Therefore we, can either remove it from the interface alltogether (the getter), or just throw an unsupported method from the config?
Comment by Michael Nitschinger [ 15/Nov/12 ]
What do you think should we do in this case?
Comment by Matt Ingenthron [ 15/Nov/12 ]
I'm good either removing it or having it throw something. Your choice.
Comment by Michael Nitschinger [ 16/Nov/12 ]
http://review.couchbase.com/#/c/22586/
Comment by Michael Nitschinger [ 21/Nov/12 ]
Fixed and merged into master. Will be available in dp5!




[JCBC-84] We need more unit tests for views Created: 12/Jul/12  Updated: 08/Nov/12  Resolved: 08/Nov/12

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: None
Fix Version/s: 1.1-beta
Security Level: Public

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


 Comments   
Comment by Mike Wiederhold [ 30/Aug/12 ]
This bug may be vague, but I don't think we should close it until we actually add more view tests to our unit testing. I constantly hear from the support team for example that users are sending valid queries that are put together incorrectly by the client. It is tests like these that should be added.
Comment by Matt Ingenthron [ 10/Sep/12 ]
as part of JCBC-41, etc. I'm adding a number of different query types, including complex queries.
Comment by Michael Nitschinger [ 04/Oct/12 ]
I've been adding view tests here, are there some areas where we can improve further (or any scenarios that are not covered here):

http://review.couchbase.com/#/c/21338/
http://review.couchbase.com/#/c/21305/

Also I've been adding new ComplexKey and query unit tests here that should prove the correct functionality:

http://review.couchbase.com/#/c/21337/
Comment by Mike Wiederhold [ 05/Oct/12 ]
This is great progress on this issue. Once you have figured out where we are lacking on testing for views feel free to close this and open up some more specific issues.
Comment by Matt Ingenthron [ 08/Oct/12 ]
Would like Michael N. to open specific issues as recommended and then close this issue.
Comment by Michael Nitschinger [ 08/Nov/12 ]
I think we are in pretty good shape with view tests now, since the query object is unit tested and we have view tests in place for (hopefully) all the params and also for observe-variations in combination with stale = false.

If special issues come up we can reopen a specific issue for them as noted.




[JCBC-80] Add a unit/integration test validation of OBSERVE + view stale=false Created: 12/Jul/12  Updated: 03/Dec/12  Resolved: 09/Oct/12

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: None
Fix Version/s: 1.1-beta
Security Level: Public

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


 Description   
Ensure that when a synchronous set is used with the new low-level observe, the index is fully updated when querying with stale=false.

 Comments   
Comment by Michael Nitschinger [ 09/Oct/12 ]
http://review.couchbase.com/#/c/21444/
Comment by Michael Nitschinger [ 09/Oct/12 ]
In my tests while writing the integration test, I found that when using PersistTo.MASTER and ReplicateTo.ONE, all records were correctly returned.

But when I just use PersistTo.MASTER, only a subset is returned - I guess this should be investigated.
Comment by Michael Nitschinger [ 08/Nov/12 ]
pushed to master, will be available in dp5.




[JCBC-78] Bucket management Created: 12/Jul/12  Updated: 14/Sep/12  Resolved: 14/Sep/12

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: None
Fix Version/s: 1.1-beta
Security Level: Public

Type: Improvement Priority: Major
Reporter: Matt Ingenthron Assignee: Raghavan Srinivas (Inactive)
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Add the necessary features to create and remove buckets. Also, add the ability to call the RESTful bucket flush.

 Comments   
Comment by Mike Wiederhold [ 14/Sep/12 ]
Duplicate of JCBC-64




[JCBC-77] Design document management, including error handling Created: 12/Jul/12  Updated: 14/Sep/12  Resolved: 14/Sep/12

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: None
Fix Version/s: 1.1-beta
Security Level: Public

Type: Improvement Priority: Major
Reporter: Matt Ingenthron Assignee: Raghavan Srinivas (Inactive)
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Add the additional functionality needed to create and replace design documents. This will likely be an extension on the Bucket class.

 Comments   
Comment by Mike Wiederhold [ 14/Sep/12 ]
Duplicate of JCBC-63.




[JCBC-66] PaginateQuery returns empty results when applying key filter Created: 16/Jun/12  Updated: 03/Oct/12  Resolved: 03/Oct/12

Status: Closed
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1dp
Fix Version/s: 1.1-beta
Security Level: Public

Type: Bug Priority: Major
Reporter: vamsi Guntuku Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: 2.0-dev-preview-4-release-notes
Remaining Estimate: 1h
Time Spent: Not Specified
Original Estimate: 1h
Environment: Java Client library 1.1DP


 Description   
If the Query object has the "key" argument set then paginateQuery is returns empty results. It is is because of the below bug in copy() method in the Query class

public Query copy() {
    Query query = new Query();
    ........
     if (args.containsKey(KEY)) {
      query.setEndkeyDocID(((String)args.get(KEY)));
    }
   .......
}

If you look the above code it is setting setEndkeyDocID() instead of setKey(). Can this be fixed asap instead of we trying to override the functionality, please?
 
Remember that the view can have duplicates so it is still applicable to have filters when we use paginateQuery.

 Comments   
Comment by Michael Nitschinger [ 03/Oct/12 ]
This has already been fixed on master!

https://github.com/couchbase/couchbase-java-client/blob/master/src/main/java/com/couchbase/client/protocol/views/Query.java#L183

If you are still seeing this issue, please reopen the ticket and I'll look into it again!
Comment by Michael Nitschinger [ 03/Oct/12 ]
Already fixed in the master branch.




[JCBC-63] add APIs for creating and deleting design documents for CBS 2.0 Created: 08/Jun/12  Updated: 29/Nov/12  Resolved: 29/Nov/12

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1dp
Fix Version/s: 1.1-beta
Security Level: Public

Type: New Feature Priority: Blocker
Reporter: Dipti Borkar Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JCBC-147 Rename getViews() to getDesignDocument() Resolved

 Description   
There are have been several requests from users to have APIs to create and delete views from the Java (and other) SDKs.
This is a MUST have for some customers and needs to be a part of the Client SDK we release prior to Beta.

 Comments   
Comment by Matt Ingenthron [ 08/Jun/12 ]
I'm in agreement. One question is do we also want this API to be involved in the view materialization process. I think the answer is probably yes, but this can be complicated since it can potentially take a very long time with little feedback.
Comment by Dipti Borkar [ 08/Jun/12 ]
When you say View materialization process? what exactly do you mean? given that index building happens at query time, I don't think so.

However, there are other APIs that may be more interesting to have. explicitly triggering compaction, configuring min time duration / min # of mutations to trigger index building.
Comment by Matt Ingenthron [ 24/Jul/12 ]
What I mean by the view materialization process is that we, in the web console, have this flow where we advise people to take their "dev_aview" and run a full cluster dataset query on it before publishing it to production. This way, when it's published as "aview", the view will have been mostly materialized. It's a nice thing for updating a view.

The reason this is complicated is that it's an HTTP request that may go for a very long, long time. I can think of a way around it (poll it with a timeout until it's fast), but it's suboptimal unless we start querying view materialization progress.
Comment by Michael Nitschinger [ 26/Aug/12 ]
Matt, what if we wait for it in a separate thread and return with a future when it's done? We just need to make the user aware that it can take a long time, and if they add a view for development that they'd have to publish it separately.

Another idea would be to make the "let's do a full dataset query" optional when the view gets published since someone may want to do that later or from the web-ui.
Comment by Matt Ingenthron [ 26/Aug/12 ]
Michael: that's effectively what we do right now since it's the query against the view that takes a long time. The design document management operations do not. The view requests are not quite done asynchronously, that's true.

The main point I was raising was that the Web Console provides for functionality to execute a view before pushing it in production and workflow to take it from "dev_thing" to "thing" knowing that the view has been materialized. In the SDK, I don't think we'll try to replicate that workflow, but the same functionality is definitely available.
Comment by Michael Nitschinger [ 05/Oct/12 ]
Just to keep everyone updated, I started developing it here: http://review.couchbase.org/#/c/21380/
Comment by Michael Nitschinger [ 29/Nov/12 ]
this has finally been merged to master.




[JCBC-58] The get() function in HTTPFuture and ViewFuture contain duplicate code Created: 03/Jun/12  Updated: 03/Dec/12  Resolved: 09/Nov/12

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1dp
Fix Version/s: 1.1-beta
Security Level: Public

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


 Description   
See JCBC-44 for more info.

 Comments   
Comment by Mike Wiederhold [ 30/Aug/12 ]
Rags, why is this incomplete? This is a code refactoring task and has information for what needs to be refactored in the bug in the description. In our ViewFuture and HttpFuture classes their is duplicate code in the get function that should be removed.
Comment by Matt Ingenthron [ 08/Oct/12 ]
Rags had accidentally closed a number of these issues, including this one.

Assigning to Michael to look into for refactoring before 1.1 release.
Comment by Michael Nitschinger [ 08/Nov/12 ]
Tracked here: http://review.couchbase.org/#/c/22353/
Comment by Michael Nitschinger [ 09/Nov/12 ]
pushed to master, will be available in dp5.




[JCBC-46] DefaultConfigFactory attempts to create VBucket with master == -1 Created: 10/May/12  Updated: 08/Nov/12  Resolved: 08/Nov/12

Status: Closed
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1dp
Fix Version/s: 1.1-beta
Security Level: Public

Type: Bug Priority: Major
Reporter: Steven Cooke Assignee: Michael Nitschinger
Resolution: Duplicate Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: all java

Issue Links:
Duplicate
duplicates JCBC-123 ArrayOutOfBounds exception during fai... Resolved

 Description   
Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
        at java.util.ArrayList.get(ArrayList.java:324)
        at com.couchbase.client.vbucket.config.DefaultConfig.getServer(DefaultConfig.java:81)
        at com.couchbase.client.vbucket.VBucketNodeLocator.getPrimary(VBucketNodeLocator.java:74)
        at com.couchbase.client.CouchbaseConnection.addOperation(CouchbaseConnection.java:140)
        at net.spy.memcached.MemcachedConnection.enqueueOperation(MemcachedConnection.java:639)
        at net.spy.memcached.MemcachedClient.asyncStore(MemcachedClient.java:296)
        at net.spy.memcached.MemcachedClient.set(MemcachedClient.java:727)
        at net.spy.memcached.MemcachedClient.set(MemcachedClient.java:125)
        at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)

Possible steps to reproduce:
1) populate bucket from load file
2) delete bucket
3) create new bucket with same name
4) repopulate bucket with same keys, same order, slightly different values

The -1 value looks like it is being set when the VBucket object is created. Would it make sense to check for illegal arguments in the constructor and make the object immutable, i.e. no setMaster?


 Comments   
Comment by thanhbv [ 23/May/12 ]
Affects Version: 1.0.2
Comment by Michael Nitschinger [ 08/Nov/12 ]
I'm pretty sure these two issues strongly correlate.
Comment by Michael Nitschinger [ 08/Nov/12 ]
This issue will be tracked in JCBC-123.




[JCBC-40] paginatedQuery throws NoSuchElementException and NPE Created: 29/Apr/12  Updated: 03/Dec/12  Resolved: 27/Nov/12

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1dp
Fix Version/s: 1.1-beta
Security Level: Public

Type: Bug Priority: Blocker
Reporter: Steven Cooke Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: java


 Description   
view iteration is incomplete and throws exceptions for
groovy code:
paginator = client.paginatedQuery(view, query, n)
while (paginator.hasNext()) {
  row = paginator.next() // Exception on this line
  ...
}


java.util.NoSuchElementException
        at java.util.LinkedList$ListItr.next(LinkedList.java:698)
        at com.couchbase.client.protocol.views.Paginator.next(Paginator.java:76)
        at com.couchbase.client.protocol.views.Paginator.next(Paginator.java:35)
        at java_util_Iterator$next.call(Unknown Source)

AND

java.lang.NullPointerException
        at com.couchbase.client.protocol.views.Paginator.getNextPage(Paginator.java:93)
        at com.couchbase.client.protocol.views.Paginator.hasNext(Paginator.java:67)
        at java_util_Iterator$hasNext.call(Unknown Source)

Paginator also has a couple odd returns
1) next() can return null, but it should never return null unless lastRow is null. I don't think lastRow should ever be null.
2) getNextPage() has a return type, HttpFuture<ViewResponse>, but always returns null


 Comments   
Comment by Steven Cooke [ 15/May/12 ]
some workarounds for NPE in getNextPage():

1) Check for a null ViewResponse in getNextPage and return the ViewResponse instead of a future or null. The hasNext method can then check the value of getNextPage returning false if there is no ViewResponse.

 2) to bypass isJsonObject for numeric keys in Query.getArgs:
boolean numericKey = (key.equals(STARTKEY) && value.toString().matches("\\d+")); // still not json number but catches most common case of positive
integer keys if (key.equals(STARTKEYDOCID) || numericKey ) { return key + "=" + value;

 3) Skip parameter needs to be zero for pages after the first. In Paginator:
 public boolean hasNext() {
   if (!pageItr.hasNext() && page.size() < docsPerPage) {
     return false;
   } else if (!(rowsIterated < docsPerPage)) {
     lastRow = pageItr.next();
     query.setSkip(0);
     query.setStartkeyDocID(lastRow.getId());
     query.setRangeStart(lastRow.getKey());
     return (getNextPage(query) != null);
   }
   return true;
}
Comment by Steven Cooke [ 15/May/12 ]
Note: #2 fails for numeric keys that are expected to be strings, an issue raised in SPY-62
Comment by Raghavan Srinivas (Inactive) [ 16/Sep/12 ]
I have revamped the paginator and the code to iterate over page and within page looks something like this.

       while (result.hasNext()) {
           ViewResponse response = result.next();
           for (ViewRow row: response) {
             System.out.println("Inner loop " + row.getId());
           }
           System.out.println("<===Outer loop====>");
       }
  
Comment by Matt Ingenthron [ 18/Sep/12 ]
http://review.couchbase.org/#/c/20898/
Comment by Matt Ingenthron [ 18/Sep/12 ]
After discussion with Rags, there are some scenarios not as well tested as we'd like and there was some clarification on how this is expected to work.
Comment by Raghavan Srinivas (Inactive) [ 26/Sep/12 ]
This revolves around getKey() returning a string which is not the case always. It could return other types (such as int) and this will affect the way PaginatedQuery and other queries behave.
Comment by Matt Ingenthron [ 06/Oct/12 ]
In an email, Steven Cooke commented:

A couple other things I noticed:

The fix breaks all the original test cases as return type of next is no longer the same. If the API is intended to be non-breaking, the
 test cases and next should be reverted.

The private method
getNextPage has a return value that is never used. This looks fishy
Comment by Matt Ingenthron [ 06/Oct/12 ]
This isn't intended to be API compatible actually. Rags and I talked through it and decided that the odd returns of nulls were odd. I don't know that the API you see here is final either.

We would appreciate any additional feedback on this API or how you think it should work.

Once we hit beta, we'll keep the API stable.
Comment by Michael Nitschinger [ 14/Nov/12 ]
http://review.couchbase.org/#/c/22513/
Comment by Michael Nitschinger [ 27/Nov/12 ]
Fixed and pushed to master. Will be available in dp5/beta.




[JCBC-35] Exception during reconfiguring of client Created: 23/Apr/12  Updated: 26/Mar/13  Resolved: 26/Mar/13

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.0.2
Fix Version/s: 1.1-beta
Security Level: Public

Type: Bug Priority: Blocker
Reporter: Marcus Nylander Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: couchbase-client 1.0.2

java version "1.6.0_30"
Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode)

Linux 2.6.18-238.19.1.el5 #1 SMP Sun Jul 10 08:43:41 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux

Attachments: Text File log.txt    

 Description   
Multiple different stackstraces below also see the following right before it starts to fail:

"Node exepcted to receive data is inactive. This could be due to afailure within the cluster. Will check for updated configuration. Key without a configured node is: akey12324234"

Then it's fails a number of times and

Failed to reconfigure client, staying with previous configuration.
java.lang.IllegalArgumentException: TODO: refactor this
        at com.couchbase.client.vbucket.config.CacheConfig.getVbucketsCount(CacheConfig.java:55)
        at com.couchbase.client.vbucket.config.DefaultConfig.compareTo(DefaultConfig.java:145)
        at com.couchbase.client.vbucket.VBucketNodeLocator.updateLocator(VBucketNodeLocator.java:133)
        at com.couchbase.client.CouchbaseConnection.reconfigure(CouchbaseConnection.java:120)
        at com.couchbase.client.CouchbaseClient.reconfigure(CouchbaseClient.java:176)
        at com.couchbase.client.vbucket.ReconfigurableObserver.update(ReconfigurableObserver.java:54)
        at java.util.Observable.notifyObservers(Observable.java:142)
        at com.couchbase.client.vbucket.BucketMonitor.setBucket(BucketMonitor.java:257)
        at com.couchbase.client.vbucket.BucketMonitor.startMonitor(BucketMonitor.java:187)
        at com.couchbase.client.vbucket.ConfigurationProviderHTTP.subscribe(ConfigurationProviderHTTP.java:243)
        at com.couchbase.client.vbucket.ConfigurationProviderHTTP.finishResubscribe(ConfigurationProviderHTTP.java:215)
        at com.couchbase.client.CouchbaseConnectionFactory.checkConfigUpdate(CouchbaseConnectionFactory.java:182)
        at com.couchbase.client.CouchbaseConnection.addOperation(CouchbaseConnection.java:165)
        at net.spy.memcached.MemcachedConnection.enqueueOperation(MemcachedConnection.java:639)
        at net.spy.memcached.MemcachedClient.asyncGet(MemcachedClient.java:835)
        at net.spy.memcached.MemcachedClient.get(MemcachedClient.java:997)




 Failed to reconfigure client, staying with previous configuration.
java.lang.IllegalArgumentException: TODO: refactor this
        at com.couchbase.client.vbucket.config.CacheConfig.getVbucketsCount(CacheConfig.java:55)
        at com.couchbase.client.vbucket.config.DefaultConfig.compareTo(DefaultConfig.java:145)
        at com.couchbase.client.vbucket.VBucketNodeLocator.updateLocator(VBucketNodeLocator.java:133)
        at com.couchbase.client.CouchbaseConnection.reconfigure(CouchbaseConnection.java:120)
        at com.couchbase.client.CouchbaseClient.reconfigure(CouchbaseClient.java:176)
        at com.couchbase.client.vbucket.ReconfigurableObserver.update(ReconfigurableObserver.java:54)
        at java.util.Observable.notifyObservers(Observable.java:142)
        at com.couchbase.client.vbucket.BucketMonitor.setBucket(BucketMonitor.java:257)
        at com.couchbase.client.vbucket.BucketMonitor.replaceConfig(BucketMonitor.java:307)
        at com.couchbase.client.vbucket.BucketUpdateResponseHandler.messageReceived(BucketUpdateResponseHandler.java:81)
        at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:80)
        at com.couchbase.client.vbucket.BucketUpdateResponseHandler.handleUpstream(BucketUpdateResponseHandler.java:194)
        at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:545)
        at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:754)
        at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:302)
        at org.jboss.netty.handler.codec.replay.ReplayingDecoder.unfoldAndfireMessageReceived(ReplayingDecoder.java:513)
        at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:497)
        at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingDecoder.java:434)
        at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:80)
        at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:545)
        at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:540)
        at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:274)
        at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:261)
        at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:340)
        at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:272)
        at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:192)
        at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
        at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:46)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:662)


 Comments   
Comment by Matt Ingenthron [ 11/Oct/12 ]
This may have been fixed in configuraton changes in 1.0.3, but that should be verified.
Comment by Michael Nitschinger [ 28/Nov/12 ]
http://review.couchbase.org/#/c/22878/
Comment by Michael Nitschinger [ 29/Nov/12 ]
fixed and pushed to master, will be available in in dp5/beta.
Comment by Michael Nitschinger [ 26/Mar/13 ]
Already fixes back in time, don't know why it is open.




Generated at Mon Jul 28 20:45:47 CDT 2014 using JIRA 5.2.4#845-sha1:c9f4cc41abe72fb236945343a1f485c2c844dac9.