[JCBC-577] Couchbase Java client 1.4.4 leaks in netty IO threads Created: 08/Oct/14  Updated: 08/Oct/14

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

Type: Bug Priority: Major
Reporter: talkganga Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: performance
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: production


 Description   
I have been experiencing similar issues with 1.4.4 where netty IO threads are in WAIT state. Its frustrating that we cannot reproduce this issue in LnP but in production during heavy traffic hours we are experiencing this issue. When this issue occurs the application server will no longer be taking any traffic and just restarting app server won't help instead we had to reboot the VM to kill those dangling connections.
Here is the stack from the thread dump we took when this issue happened.

Thread Name
Couchbase View Thread for node cbnibslc02-289848/10.120.159.104:8092
State
Waiting on condition
Java Stack
at sun/nio/ch/EPollArrayWrapper.epollWait(Native Method)
at sun/nio/ch/EPollArrayWrapper.poll(EPollArrayWrapper.java:228(Compiled Code))
at sun/nio/ch/EPollSelectorImpl.doSelect(EPollSelectorImpl.java:81(Compiled Code))
at sun/nio/ch/SelectorImpl.lockAndDoSelect(SelectorImpl.java:87(Compiled Code))
at sun/nio/ch/SelectorImpl.select(SelectorImpl.java:98(Compiled Code))
at org/apache/http/impl/nio/reactor/AbstractMultiworkerIOReactor.execute(AbstractMultiworkerIOReactor.java:305)
at com/couchbase/client/http/AsyncConnectionManager.execute(AsyncConnectionManager.java:89)
at com/couchbase/client/ViewNode$1.run(ViewNode.java:89)
at java/lang/Thread.run(Thread.java:780)
Native Stack
(0x00007F0D06106052 [libj9prt26.so+0x13052])
(0x00007F0D061136CF [libj9prt26.so+0x206cf])
(0x00007F0D06105D9B [libj9prt26.so+0x12d9b])
(0x00007F0D06105E97 [libj9prt26.so+0x12e97])
(0x00007F0D061136CF [libj9prt26.so+0x206cf])
(0x00007F0D061059BB [libj9prt26.so+0x129bb])
(0x00007F0D060FF812 [libj9prt26.so+0xc812])
(0x00007F0D07252B40 [libpthread.so.0+0xfb40])
pthread_cond_wait+0xca (0x00007F0D0724EA9A [libpthread.so.0+0xba9a])
(0x00007F0D0634D0CF [libj9thr26.so+0x80cf])
(0x00007F0D064BA859 [libj9vm26.so+0x63859])
(0x00007F0D052DE6D9 [libj9jit26.so+0x5b96d9])

thanks




[JCBC-571] View query with a lot of keys in the parameter does not use POST method Created: 29/Sep/14  Updated: 29/Sep/14

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

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


 Description   
2.0 java client fails this test http://review.couchbase.org/#/c/41725/




[JCBC-567] The client might still use HTTP configuration provider to fetch JSON config Created: 28/Sep/14  Updated: 20/Oct/14

Status: New
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 1.4.4
Fix Version/s: .future
Security Level: Public

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


 Description   
Seems like the client forgets that it was using CCCP initially

For example in case of network failure, after restoring connectivity it skips CCCP and bootstraps using HTTP




[JCBC-634] Get Available Servers - Incorrect count Created: 24/Nov/14  Updated: 01/Dec/14

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

Type: Bug Priority: Major
Reporter: Saravanan M P Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: customer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
We have three nodes in the CouchBase cluster; We brought down 2 nodes and the getAvailableServers() returns 1. When we bring up one node, the count changes to 2. But, when we bring up the third node, the count still stays at 2. It should return 3!

 Comments   
Comment by Michael Nitschinger [ 01/Dec/14 ]
Thanks for reporting. Can you provide us more exact steps on how to reproduce and maybe also some logs we can look at?

Also, can you please try 1.4.5 because had fixes in the config management area?

Thanks!




[JCBC-659] Create unit tests for LegacyTranscoder Created: 16/Dec/14  Updated: 16/Dec/14

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

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


 Description   
LegacyTranscoder should have its own unit tests, including checking buffer release behavior




[JCBC-568] Client hanged at shutdown Created: 29/Sep/14  Updated: 29/Sep/14

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

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


 Description   
This issue is marked as minor because it's been observed only once and we haven't been able to reproduce it since then.
The component using couchbase failed to shut down gracefully, and, after analyzing stacktrace, following two blocked couchbase threads were noticed - their stack traces follow:

First:

"New I/O worker #14" prio=10 tid=0x00007fcdfc159000 nid=0x409 waiting for monitor entry [0x00007fcddb6f5000]
   java.lang.Thread.State: BLOCKED (on object monitor)
at com.couchbase.client.vbucket.ConfigurationProviderHTTP.getBucket(ConfigurationProviderHTTP.java:125)
- waiting to lock <0x0000000745f9d2a8> (a com.couchbase.client.vbucket.ConfigurationProviderHTTP)
at com.couchbase.client.vbucket.BucketMonitor.notifyDisconnected(BucketMonitor.java:118)
at com.couchbase.client.vbucket.BucketUpdateResponseHandler.handleUpstream(BucketUpdateResponseHandler.java:187)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:565)
at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:793)
at org.jboss.netty.handler.codec.replay.ReplayingDecoder.cleanup(ReplayingDecoder.java:573)
at org.jboss.netty.handler.codec.frame.FrameDecoder.channelDisconnected(FrameDecoder.java:366)
at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:107)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:565)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:560)
at org.jboss.netty.channel.Channels.fireChannelDisconnected(Channels.java:399)
at org.jboss.netty.channel.Channels$4.run(Channels.java:389)
at org.jboss.netty.channel.socket.ChannelRunnableWrapper.run(ChannelRunnableWrapper.java:41)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.processEventQueue(AbstractNioWorker.java:378)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:259)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:35)
at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:102)
at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662) Locked ownable synchronizers: - <0x0000000745dca468> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)


Second:

"HttpConfigurationProvider Reloader" prio=10 tid=0x00007fcde406d800 nid=0x406 waiting on condition [0x00007fcddb8f7000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x0000000745d30978> (a java.util.concurrent.CountDownLatch$Sync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:207)
at com.couchbase.client.vbucket.BucketUpdateResponseHandler.getReceivedFuture(BucketUpdateResponseHandler.java:149)
at com.couchbase.client.vbucket.BucketUpdateResponseHandler.getLastResponse(BucketUpdateResponseHandler.java:129)
at com.couchbase.client.vbucket.BucketMonitor.startMonitor(BucketMonitor.java:219)
at com.couchbase.client.vbucket.ConfigurationProviderHTTP.subscribe(ConfigurationProviderHTTP.java:339)
- locked <0x0000000745f9d2a8> (a com.couchbase.client.vbucket.ConfigurationProviderHTTP)
at com.couchbase.client.vbucket.provider.BucketConfigurationProvider.monitorBucket(BucketConfigurationProvider.java:361)
at com.couchbase.client.vbucket.provider.BucketConfigurationProvider.access$900(BucketConfigurationProvider.java:65)
at com.couchbase.client.vbucket.provider.BucketConfigurationProvider$HttpProviderRefresher.run(BucketConfigurationProvider.java:610)
at java.lang.Thread.run(Thread.java:662) Locked ownable synchronizers: - None

Hope some light can be shed on this strange behavior.
Thank you very much in advance!




[JCBC-570] set(key, exp, value, ReplicateTo.ONE, ReplicateTo.ZERO) does not seem to provide sufficient detail for robust error handling Created: 29/Sep/14  Updated: 29/Sep/14

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

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


 Description   
It looks like that call leads to asyncObserveStore(key, setOp, req, rep, "Set", false) in CouchbaseClient.

Then if an exception is thrown from the observePoll at line 1443, it is handled and an OperationStatus object is made for the caller. But there is no status code set up. So the only way for the caller to tell what happened it to interrogate the message. Having my calling code looking for specific messages does not feel robust. Can we get some kind of fixed set of codes (perhaps new StatusCode values) to look for?

{code}
1442 try {
1443 observePoll(key, future.getCas(), req, rep, delete);
1444 observeFuture.set(true, future.getStatus());
1445 } catch (ObservedException e) {
1446 observeFuture.set(false, new OperationStatus(false, e.getMessage()));
1447 } catch (ObservedTimeoutException e) {
1448 observeFuture.set(false, new OperationStatus(false, e.getMessage()));
1449 } catch (ObservedModifiedException e) {
1450 observeFuture.set(false, new OperationStatus(false, e.getMessage()));
1451 }
{code}

 Comments   
Comment by m0thra [ 29/Sep/14 ]
The reason this is causing me problems is that I want to code specific handling for "ObserveModifiedException". It is correct to assume that in this case the write succeeded?




[JCBC-499] Test SSL Feature with Java 2.0 SDK Created: 28/Jul/14  Updated: 21/Aug/14  Resolved: 21/Aug/14

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

Type: Bug Priority: Test Blocker
Reporter: Wei-Li Liu Assignee: Michael Nitschinger
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File ssl.pcapng    

 Description   
Michael, here is the SSL Feature Test I created
https://github.com/couchbase/couchbase-java-client/pull/6/files
I know there are suff should be in core, and we can move it later

There are a couple issues in this feature tests

1. view and query test hangs
2. the ssl test I created is not able to catch exceptions such as sun.security.validator.ValidatorException, javax.net.ssl.SSLHandshakeException. etc

We can’t disable SSL from the server side after starting the server. SSL certificate automatically generated and self signed, so we can’t modify expired date.

I also test 2.5 server connect with java client, which does not work with SSL.

Attached file is wireshark packet capture fro FeatureTest with SSL. If you decode it with SSL in Wireshark, you can see the data and TLS protocol.
  



 Comments   
Comment by Wei-Li Liu [ 30/Jul/14 ]
java sdk's commit on observe relies on core
https://github.com/weilliu/couchbase-java-client/commit/6f8d672ff9a600780fd5d7d47d5ba6ce52bd083d

import com.couchbase.client.core.message.binary.ObserveRequest;
import com.couchbase.client.core.message.binary.ObserveResponse;

Currently Core can't be built on master

====================================
[root@centos-64-x64 couchbase-jvm-core]# ./gradlew install
:compileJava
Note: /root/sdkd-2.0/couchbase-jvm-core/src/main/java/com/couchbase/client/core/CouchbaseCore.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
:processResources
:classes
:jar
:javadoc
java.lang.UnsupportedClassVersionError: ch/raffael/doclets/pegdown/PegdownDoclet : Unsupported major.minor version 51.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:643)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
at java.net.URLClassLoader.access$000(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:212)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
at java.lang.ClassLoader.loadClass(ClassLoader.java:323)
at java.lang.ClassLoader.loadClass(ClassLoader.java:268)
at com.sun.tools.javadoc.DocletInvoker.<init>(DocletInvoker.java:96)
at com.sun.tools.javadoc.Start.setDocletInvoker(Start.java:414)
at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:213)
at com.sun.tools.javadoc.Start.begin(Start.java:162)
at com.sun.tools.javadoc.Main.execute(Main.java:59)
at com.sun.tools.javadoc.Main.main(Main.java:49)
javadoc: error - fatal error
1 error
:javadoc FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':javadoc'.
> Javadoc generation failed.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 24.87 secs
====================================================

Comment by Wei-Li Liu [ 04/Aug/14 ]
Please disregard my above error, which is triggered by inconsistent jdk version on run time and compile time.
Comment by Don Pinto [ 11/Aug/14 ]
Wei-li, can you update this ticket?
Comment by Wei-Li Liu [ 11/Aug/14 ]
@Michael looking at your most recent commit, I don't think the catching exception issue has been fixed yet. I believe you just changed the fix version to 2.0-beta.
I also have some issues build couchbase-java-client from master after I pull both sdk and the core. I knew Deepti has the same issue earlier, but not sure if it has been resolved yet.
Comment by Matt Ingenthron [ 18/Aug/14 ]
Michael: this is blocking completion of testing, can you aim to resolve it this week.
Comment by Wei-Li Liu [ 18/Aug/14 ]
After getting some help from Deepti, I am able to get dp3 build with ./gradlew publish and ./gradlew publishToMavenLocal
Integration test has been changed in dp3, so some modifications required for SSL feature tests on my end.
Comment by Wei-Li Liu [ 20/Aug/14 ]
Report bug JCBC-520
Comment by Michael Nitschinger [ 21/Aug/14 ]
So are we tracking it in JCBC-520 and closing this?
Comment by Wei-Li Liu [ 21/Aug/14 ]
okay




[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-130] view request hangs in addOp(CouchbaseClient.java:614) during failover Created: 11/Oct/12  Updated: 24/Oct/12  Resolved: 24/Oct/12

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

Type: Bug 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

Attachments: Text File fullthreaddump-jcbc-130.txt    

 Description   
During an autofailover of the cluster, view requests may hang, rather than timeout.

Stack is:
2012-10-10 10:45:13
Full thread dump Java HotSpot(TM) Server VM (19.1-b02 mixed mode):
 
"Attach Listener" daemon prio=10 tid=0x09765c00 nid=0x3b5f waiting on condition [0x00000000]
   java.lang.Thread.State: RUNNABLE
 
"pool-8-thread-50" prio=10 tid=0x09763c00 nid=0x399d waiting on condition [0x71283000]
   java.lang.Thread.State: WAITING (parking)
     at sun.misc.Unsafe.park(Native Method)
     - parking to wait for <0xb48bc4c0> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
     at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
     at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
     at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:941)
     at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1261)
     at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:594)
     at com.couchbase.client.ViewConnection.addOp(ViewConnection.java:142)
     at com.couchbase.client.CouchbaseClient.addOp(CouchbaseClient.java:614)
    at com.couchbase.client.CouchbaseClient.asyncGetView(CouchbaseClient.java:320)
     at com.couchbase.client.CouchbaseClient.getView(CouchbaseClient.java:393)
...

 Comments   
Comment by Michael Nitschinger [ 24/Oct/12 ]
The corresponding fix (http://review.couchbase.com/#/c/21915/) makes sure to close request connections when the operation bound to it is also closed.

This addresses the issue that the wait() in the async connection request hangs in there for a long time in case the operation is cancelled.




[JCBC-121] Connection to memcached buckets fail due to lack of CouchServers support Created: 28/Sep/12  Updated: 29/Oct/12  Resolved: 26/Oct/12

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

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


 Description   
java.lang.UnsupportedOperationException: No couch port for cache buckets
        at com.couchbase.client.vbucket.config.CacheConfig.getCouchServers(CacheConfig.java:152)
        at com.couchbase.client.CouchbaseClient.<init>(CouchbaseClient.java:232)
        at com.couchbase.cbc.App.main(App.java:75)


Perhaps there's some convoluted way to make it work by creating five thousand factories, but this can be a simple check in the ctor:

if (getVBucketConfig().getConfigType() == ConfigType.COUCHBASE) { ... } else { /* maybe warn here */ }

And then of course making sure any view execution methods return appropriate error messages.

 Comments   
Comment by Michael Nitschinger [ 09/Oct/12 ]
http://review.couchbase.org/#/c/21445/




[JCBC-64] add APIs for creating and deleting buckets for CBS 2.0 Created: 08/Jun/12  Updated: 06/Nov/12  Resolved: 06/Nov/12

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

Type: Improvement Priority: Blocker
Reporter: Dipti Borkar Assignee: Mike Wiederhold
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
While there are other ways to create buckets (via REST endpoints / UI), customers have started asking about APIs to create and delete buckets a few times now. We should add this as a part of the SDK.

 Comments   
Comment by Matt Ingenthron [ 08/Jun/12 ]
This one has security related issues, as currently there is never a reason for a client library to have/use the cluster admin password. It's certainly pretty straightforward to do so though.
Comment by Mike Wiederhold [ 09/Jun/12 ]
Would it make sense here to have a separate class that just sends rest commands? I actually have a project that does this.

https://github.com/mikewied/java-membase-rest-client
Comment by Matt Ingenthron [ 13/Jun/12 ]
I do think a separate class or a set of static methods will be needed. The problem is that CouchbaseClient builds it's connections in the constructor, and creation of a bucket needs to be done separately from management.

The only concern here is one of dependencies. We should be adding less, not more dependencies. Haven't looked at your code, but it may fit the bill if it doesn't add any deps.
Comment by Matt Ingenthron [ 14/Sep/12 ]
This is in review from Mike in dp3
Comment by Michael Nitschinger [ 06/Nov/12 ]
This has been reviewed, and pushed to master. Will be available in dp4 shortly.




[JCBC-48] StringUtils.isJsonObject does not follow JSON spec which breaks Query Created: 13/May/12  Updated: 19/Jun/13  Resolved: 04/Oct/12

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

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


 Description   
net.spy.memcached.util.StringUtils does not implement isJsonObject to spec (http://www.json.org/) which breaks queries.

* In particular, valid JSON numbers outside of the Java integer range are rejected and any String starting with "{" or "[" is permitted.

* There is a size restriction for the key that is not checked (net.spy.memcached.util.validateKey)

* There is a related issue, http://www.couchbase.com/issues/browse/JCBC-41 related to quoting string keys, but I think there is confusion with what a valid key is that should be cleared up first. If setKey takes unquoted strings, but the query string requires a JSON string it should be clear in the docs and setKey should wrap and escape unquoted strings which will avoid special handling. Quoted strings passed to setKey should be treated as JSON and internal quotes if unescaped should probably be treated as a runtime exception at query time. Unless explicitly set elsewhere, only numeric types should by assumed to be JSON numbers.


Instead of isJsonObject and Object.toString, it may make sense to create isKey/toKey methods

isJsonObject should either be fixed or removed from spymemcached library, but the 2.8.1 version should never be used.


 


 Comments   
Comment by Steven Cooke [ 13/May/12 ]
I think fixing this will also fix http://www.couchbase.com/issues/browse/JCBC-40
Comment by Matt Ingenthron [ 24/Jul/12 ]
Excellent points, thanks for raising them. We're working to get an update here soon.
Comment by Tim Smith (Inactive) [ 17/Aug/12 ]
See related JCBC-32 .
Comment by Tim Smith (Inactive) [ 17/Aug/12 ]
Here's sample code that is difficult to get right:

https://gist.github.com/3375697

The setRangeStart() method needs to be called with an oddly-escaped JSON-encoded string:

myQuery.setRangeStart("[\"Level+2\"]");

This may be more relevant to JCBC-32.

This comment is to remind that somewhere in here is an opportunity to help the developer easily create the right query string without getting confused by multiple levels of quoting.

Thanks!

Tim
Comment by Michael Nitschinger [ 04/Oct/12 ]
This will be tracked in JCBC-41!
Comment by Brad Wood [ 19/Jun/13 ]
I'm unclear on whether or not the issue is resolved. The last comment says it will be tracked with JCBC-41, but that ticket doesn't appear to really be related to this one.




[JCBC-17] support new stale=false parameter Created: 01/Mar/12  Updated: 31/May/12  Resolved: 31/May/12

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

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


 Description   
Starting with 2.0 DP4, the default for stale has changed to update_after and there is a new argument to the stale parameter, "false" which performs a view update before response. The client needs to support this new argument to the stale parameter.

 Comments   
Comment by Mike Wiederhold [ 12/May/12 ]
I just looked at the Stale class and a False parameter already exists. If this was the only thing we needed then can we close this bug as invalid?




[JCBC-16] client can OOM due to a bug in netty Created: 28/Feb/12  Updated: 05/Apr/12  Resolved: 05/Apr/12

Status: Closed
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.0.1
Fix Version/s: 1.0.2
Security Level: Public

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

Attachments: Text File TapConnectionProvider.patch    

 Description   
According to the bug reporter, the client can OOM leaking vbucket objects, and those owing (likely) to a bug in Netty.

From the bug reporter:
Using sdk 1.0.1 and couchbase (enterprise) 1.8, my application
(basically a TapClient which runs "dump" method) had OutOfMemory and
"Too many open files" issues.
By dumping memory with jmap, it seemed that jvm memory was full of
VBucket object, also there was a correlation between the number of
VBucket and each tapclient.dump call (each calls brings like 2048 new
elements).

This is surely related to some changes in
spymemcached2.8+couchbase1.0.1 as I had no issue with spymemcached
2.7.3.
It seems that those VBucket where related to CouchbaseConnection
object, which were (at least) referenced in some org.jboss.netty
classes, like org.jboss.netty.channel.AbstractChannel.
I had no time to check in the Netty community, but it seems that
replacing sdk default netty jar with the latest 3.3.1 solves the
issue, as the number of
Vbucket is no longer running up.

Anyone facing the same issue? Is it safe to use this netty version?
Eventually, if this issue is confirmed, it could be time to update the
sdk zip file downloadable by the site.

 Comments   
Comment by Walter [ 01/Mar/12 ]
It seems it maybe connected to
https://issues.jboss.org/browse/NETTY-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#issue-tabs
by the way, it also seems that TapConnectionProvider.java open a CouchbaseConnectionFactory but never shutdown it.
I'm going to add a patch of that file which at least until now, it seems to do the trick.
Comment by Walter [ 01/Mar/12 ]
this keeps the number of VBucket object under control.




[JCBC-484] Publish docs for Java July 2014 release Created: 01/Jul/14  Updated: 01/Jul/14  Resolved: 01/Jul/14

Status: Closed
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.4.3
Fix Version/s: 1.4.3
Security Level: Public

Type: Task Priority: Critical
Reporter: Amy Kurtzman Assignee: Amy Kurtzman
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: 1h
Time Spent: Not Specified
Original Estimate: 1h


 Description   
Publish updated documentation, release notes, and javadocs.




[JCBC-452] Publish docs for Java May 2014 release Created: 22/Apr/14  Updated: 09/May/14  Resolved: 09/May/14

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

Type: Task Priority: Critical
Reporter: Amy Kurtzman Assignee: Amy Kurtzman
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: 1h
Time Spent: Not Specified
Original Estimate: 1h





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

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

Type: Bug Priority: Critical
Reporter: Deepti Dawar Assignee: Deepti Dawar
Resolution: Fixed 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... Resolved

 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.

 Comments   
Comment by Michael Nitschinger [ 01/Jun/14 ]
Since the MB ticket was fixed, is this still an issue with 1.4.1 / the upcoming 1.4.2?
Comment by Deepti Dawar [ 04/Jun/14 ]
Will confirm after testing.
Comment by Deepti Dawar [ 19/Jun/14 ]
Latest tests are positive.

https://docs.google.com/a/globallogic.com/spreadsheets/d/1IKxchnrsHQgBQZVF79y55zIk5MsNeuPnZ_iIZ6ptv8s/edit#gid=1382174636

Hence, closing the issue.




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

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

Type: Bug Priority: Critical
Reporter: Deepti Dawar Assignee: Deepti Dawar
Resolution: Fixed 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.

 Comments   
Comment by Michael Nitschinger [ 01/Jun/14 ]
QE issues are closed, is this still an issue?
Comment by Deepti Dawar [ 04/Jun/14 ]
Will confirm after testing.
Comment by Deepti Dawar [ 19/Jun/14 ]
Latest test results are positive

https://docs.google.com/a/globallogic.com/spreadsheets/d/1IKxchnrsHQgBQZVF79y55zIk5MsNeuPnZ_iIZ6ptv8s/edit#gid=1382174636

Closing it.




[JCBC-321] Null Pointer in client when deleting bucket via UI Created: 24/Jun/13  Updated: 18/Nov/13  Resolved: 18/Nov/13

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

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

Issue Links:
Duplicate
duplicates JCBC-324 Avoid NPE when Host is Up, but no CB ... Resolved

 Description   
un 24 09:12:19: WARNING: Connection problems with URI http://localhost:8091/pools ...skipping
Jun 24 09:12:19: java.io.IOException: Server returned HTTP response code: 401 for URL: http://localhost:8091/pools
Jun 24 09:12:19: at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1615)
Jun 24 09:12:19: at com.couchbase.client.vbucket.ConfigurationProviderHTTP.readToString(ConfigurationProviderHTTP.java:417)
Jun 24 09:12:19: at com.couchbase.client.vbucket.ConfigurationProviderHTTP.readPools(ConfigurationProviderHTTP.java:210)
Jun 24 09:12:19: at com.couchbase.client.vbucket.ConfigurationProviderHTTP.getBucketConfiguration(ConfigurationProviderHTTP.java:147)
Jun 24 09:12:19: at com.couchbase.client.vbucket.ConfigurationProviderHTTP.subscribe(ConfigurationProviderHTTP.java:318)
Jun 24 09:12:19: at com.couchbase.client.CouchbaseConnectionFactory$Resubscriber.run(CouchbaseConnectionFactory.java:406)
Jun 24 09:12:19: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
Jun 24 09:12:19: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
Jun 24 09:12:19: at java.lang.Thread.run(Thread.java:722)
Jun 24 09:12:19: Jun 24, 2013 9:12:19 AM com.couchbase.client.CouchbaseConnectionFactory$Resubscriber run
Jun 24 09:12:19: WARNING: Resubscribe attempt failed:
Jun 24 09:12:19: java.lang.NullPointerException
Jun 24 09:12:19: at com.couchbase.client.vbucket.ConfigurationProviderHTTP.getBucketConfiguration(ConfigurationProviderHTTP.java:148)
Jun 24 09:12:19: at com.couchbase.client.vbucket.ConfigurationProviderHTTP.subscribe(ConfigurationProviderHTTP.java:318)
Jun 24 09:12:19: at com.couchbase.client.CouchbaseConnectionFactory$Resubscriber.run(CouchbaseConnectionFactory.java:406)
Jun 24 09:12:19: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
Jun 24 09:12:19: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
Jun 24 09:12:19: at java.lang.Thread.run(Thread.java:722)

 Comments   
Comment by Michael Nitschinger [ 19/Jul/13 ]
This is halfway expected, but the NPE is not. there is some other ticket tracking the same path, I'll link them as soon as I find the other.




[JCBC-308] Trouble in resubscribing to primary node via cbc, when all servers go down one by one. Created: 21/May/13  Updated: 25/Sep/13  Resolved: 25/Sep/13

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

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

Attachments: Text File cbc_server_all_nodes_failure.log    
Issue Links:
Dependency
depends on JCBC-138 Java Client does not recover when onl... Resolved
Duplicate
is duplicated by JCBC-304 Client leads to a deadlock when all t... Closed

 Description   
PFA the logs.
More specifically so, it is a concern in case of views.


 Comments   
Comment by Deepti Dawar [ 25/Sep/13 ]
Fixed as the case is similar to JCBC-138.




[JCBC-119] Allow persist argument to accept null/zero Created: 28/Sep/12  Updated: 16/Oct/12  Resolved: 08/Oct/12

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

Type: Bug 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


 Description   
This makes it easier for people to turn persistence on/off.

Either provide a .ZERO constant, or check for those arguments to be null

i.e.


                    ft = cli.set(options.key,
                            options.expiry,
                            options.value,
                            null,
                            null);

Currently this throws an NPE

 Comments   
Comment by Raghavan Srinivas (Inactive) [ 28/Sep/12 ]
How is this any different from set (key, expiry, value) which is already provided?

I think that is less confusing that set(key, expiry, value, null, null)

I agree that the NPE will need to be fixed.
Comment by Mark Nunberg [ 28/Sep/12 ]
Because it requires the user to change the method call if they want to turn off persistence... functionally it is the same, but the former is exactly my use case.

So take this simple example:

PersistTo persist = .. // get global settings from app, if not available set to .ZERO
ReplicateTo replicate = ... // get global settings from app
OperationFuture ft = null;

// ....
// Right now, the user would need to do something like:

if (persist != null) {
 ft = cli.set(key, expiry, value);
} else {
 ft = cli.set(key, expiry, value, persist, replicate);
}

I've also just realized that the API provides no means by which to do replication without persistence.. allowing the 'extended' variant (k,e,v,p,r) gives the user pretty much everything he needs
Comment by Matt Ingenthron [ 05/Oct/12 ]
There should also be a variant that takes ReplicateTo without PersistTo.
Comment by Michael Nitschinger [ 08/Oct/12 ]
See this changeset: http://review.couchbase.com/#/c/21421/




[JCBC-60] setKey() Doesn't Maintain String Value Created: 06/Jun/12  Updated: 09/Jun/12  Resolved: 09/Jun/12

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

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


 Description   
I have a view with string keys which happen to also be valid integers. In this case routing numbers that can have leading zeros. When I perform a get in using the Java API, the request forwarded to the database assumes I actually meant to send an integer type and the quotes are not sent to as apart of the database query, along with the leading zero now trimmed. If I try to force quotes into the key string, I get extra keys sent with the query.

I'm assuming the API is guessing the query type based on my input but wouldn't it be better to overload the method for specific types, specifically the primitive types?

Example:

query.setKey("011601087"); results in ?stale=false&key=011601087 but I need ?stale=false&key="011601087"

If I try:
query.setKey("\"011601087\""); results in ?stale=false&key=011601087 but I need ?stale=false&key=""011601087""

 Comments   
Comment by Patrick Gallagher [ 06/Jun/12 ]
Sorry, I meant the second example ( query.setKey("\"011601087\"");) results in ?stale=false&key=""011601087""
Comment by Steven Cooke [ 07/Jun/12 ]
This is the same issue as JCBC-41
Comment by Patrick Gallagher [ 07/Jun/12 ]
Thanks Steven.
Comment by Steven Cooke [ 07/Jun/12 ]
and also SPY-62
Comment by Mike Wiederhold [ 09/Jun/12 ]
Closing as a duplicate of SPY-41. We will get this issue resolved as soon as possible.




[JCBC-340] Tap client should only connect to active vbuckets Created: 16/Aug/12  Updated: 06/Aug/13  Resolved: 06/Aug/13

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

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

Issue Links:
Relates to
relates to JCBC-341 TapClient should tap only vbuckets on... Open
relates to JCBC-342 TAP Client streams should be reconfig... Open

 Comments   
Comment by Michael Nitschinger [ 06/Aug/13 ]
Here is the first set of changes:

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

The other changes will be tracked in subsequent tickets and linked.




[JCBC-594] code doc sections are labeled incorrectly Created: 17/Oct/14  Updated: 30/Oct/14  Resolved: 30/Oct/14

Status: Closed
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 2.0.0
Fix Version/s: 2.0.1
Security Level: Public

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


 Description   
XML docs are labeled and syntax highlighted as Java:
http://www.couchbase.com/developer/java-2.0/logging.html



 Comments   
Comment by Amy Kurtzman [ 30/Oct/14 ]
Fixed language tagging on the page.




[JCBC-569] The latest Java API points to 1.4.3 and not 1.4.4. Created: 29/Sep/14  Updated: 29/Sep/14  Resolved: 29/Sep/14

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

Type: Task Priority: Major
Reporter: Patrick Varley Assignee: Amy Kurtzman
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: http://www.couchbase.com/autodocs/couchbase-java-client-latest/index.html


 Description   
The link from the documentation menu is:

http://www.couchbase.com/autodocs/couchbase-java-client-latest/index.html

Which brings you to:

http://www.couchbase.com/autodocs/couchbase-java-client-1.4.3/index.html

When I tried to go to 1.4.4 by hand I got redirect back to the home page:

http://www.couchbase.com/autodocs/couchbase-java-client-1.4.4/index.html





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

Status: Closed
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: Unassigned
Resolution: Won't Fix 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-423] Publish docs for Java SDK April 2014 release Created: 27/Feb/14  Updated: 16/Apr/14  Resolved: 16/Apr/14

Status: Closed
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.4.0-dp2
Fix Version/s: None
Security Level: Public

Type: Task Priority: Major
Reporter: Amy Kurtzman Assignee: Amy Kurtzman
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Edit and publish developer guide and autodocs.




[JCBC-420] 2 Threads of add() operation loops show success on first op Created: 25/Feb/14  Updated: 13/Mar/14  Resolved: 13/Mar/14

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

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


 Description   
Similar to: http://www.couchbase.com/issues/browse/JCBC-419

Two threads, each with a loop of add() operations over keys, they both start with same key. In both loops the first operation succeeds according to the OperationFuture [op.get()].

I was using Java SDK 1.3.2 running against Couchbase server 2.2.0


 Comments   
Comment by scalabl3 [ 13/Mar/14 ]
moved to: https://www.couchbase.com/issues/browse/CBSE-995




Java February 2014 documentation release (JCBC-410)

[JCBC-411] Publish Java February 2014 documentation Created: 05/Feb/14  Updated: 06/Feb/14  Resolved: 06/Feb/14

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

Type: Technical task Priority: Major
Reporter: Amy Kurtzman Assignee: Amy Kurtzman
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Edit and publish the updated SDK documentation.




Java February 2014 documentation release (JCBC-410)

[JCBC-412] Upload Javadocs Created: 05/Feb/14  Updated: 06/Feb/14  Resolved: 06/Feb/14

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

Type: Technical task Priority: Major
Reporter: Amy Kurtzman Assignee: Amy Kurtzman
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Upload javadocs to autodocs




[JCBC-410] Java February 2014 documentation release Created: 05/Feb/14  Updated: 06/Feb/14  Resolved: 06/Feb/14

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

Type: Task Priority: Major
Reporter: Amy Kurtzman Assignee: Amy Kurtzman
Resolution: Done Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Sub-Tasks:
Key
Summary
Type
Status
Assignee
JCBC-411 Publish Java February 2014 documentat... Technical task Closed Amy Kurtzman  
JCBC-412 Upload Javadocs Technical task Closed Amy Kurtzman  




Documentation for Java 1.3 (JCBC-391)

[JCBC-393] Publish Java 1.3 documentation Created: 19/Dec/13  Updated: 10/Jan/14  Resolved: 10/Jan/14

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

Type: Technical task Priority: Major
Reporter: Amy Kurtzman Assignee: Amy Kurtzman
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: 2h
Time Spent: Not Specified
Original Estimate: 2h


 Description   
This task includes:
1. Edit release notes.
2. Edit other revisions to the document.
3. Add new version to nanoc.yaml file.
4. Update links on www.couchbase.com/documentation
5. Publish document on external website (docs.couchbase.com).




Documentation for Java 1.3 (JCBC-391)

[JCBC-394] Autodocs for Java 1.3 Created: 19/Dec/13  Updated: 10/Jan/14  Resolved: 10/Jan/14

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

Type: Technical task Priority: Major
Reporter: Amy Kurtzman Assignee: Amy Kurtzman
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: 1h
Time Spent: Not Specified
Original Estimate: 1h


 Description   
Michael, when you create the autodocs for Java 1.3, please attach them to this task and reassign to me. Thanks, Amy




[JCBC-391] Documentation for Java 1.3 Created: 19/Dec/13  Updated: 10/Jan/14  Resolved: 10/Jan/14

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

Type: Task Priority: Major
Reporter: Amy Kurtzman Assignee: Amy Kurtzman
Resolution: Done Votes: 0
Labels: None
Σ Remaining Estimate: 4h Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: 4h Original Estimate: Not Specified

Sub-Tasks:
Key
Summary
Type
Status
Assignee
JCBC-392 Create documentation files for Java 1.3 Technical task Closed Amy Kurtzman  
JCBC-393 Publish Java 1.3 documentation Technical task Closed Amy Kurtzman  
JCBC-394 Autodocs for Java 1.3 Technical task Closed Amy Kurtzman  

 Description   
Documentation tasks for Java 1.3 release




Documentation for Java 1.3 (JCBC-391)

[JCBC-392] Create documentation files for Java 1.3 Created: 19/Dec/13  Updated: 23/Dec/13  Resolved: 23/Dec/13

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

Type: Technical task Priority: Major
Reporter: Amy Kurtzman Assignee: Amy Kurtzman
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: 1h
Time Spent: Not Specified
Original Estimate: 1h


 Comments   
Comment by Amy Kurtzman [ 23/Dec/13 ]
The new files are available in the GitHub documentation repo in a branch named java-1.3, located at https://github.com/couchbaselabs/docs-ng/tree/java-1.3/content/couchbase-sdk-java-1.3.




[JCBC-383] Some org.springframework.data.repository.CrudRepository methods throw Exception Created: 24/Nov/13  Updated: 26/Nov/13  Resolved: 25/Nov/13

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

Type: Bug Priority: Major
Reporter: deepak vohra Assignee: Michael Nitschinger
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The following methods in the org.springframework.data.repository.CrudRepository<T,ID extends Serializable> interface throw and exception.
deleteAll()
count()
findAll()
findAll(Iterable<ID> ids)

The exception is:

Exception in thread "main" org.springframework.dao.InvalidDataAccessResourceUsageException: Could not load view

"all" for design doc "catalog"; nested exception is com.couchbase.client.protocol.views.InvalidViewException: Could

not load view "all" for design doc "catalog"
at org.springframework.data.couchbase.core.CouchbaseExceptionTranslator.translateExceptionIfPossible

(CouchbaseExceptionTranslator.java:69)
at org.springframework.data.couchbase.core.CouchbaseTemplate.execute(CouchbaseTemplate.java:236)
at org.springframework.data.couchbase.core.CouchbaseTemplate.queryView(CouchbaseTemplate.java:192)
at org.springframework.data.couchbase.repository.support.SimpleCouchbaseRepository.deleteAll

(SimpleCouchbaseRepository.java:168)
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:601)
at org.springframework.data.repository.core.support.RepositoryFactorySupport

$QueryExecutorMethodInterceptor.executeMethodOn(RepositoryFactorySupport.java:344)
at org.springframework.data.repository.core.support.RepositoryFactorySupport

$QueryExecutorMethodInterceptor.invoke(RepositoryFactorySupport.java:329)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at org.springframework.data.couchbase.repository.support.ViewPostProcessor$ViewInterceptor.invoke

(ViewPostProcessor.java:80)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke

(ExposeInvocationInterceptor.java:91)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at com.sun.proxy.$Proxy13.deleteAll(Unknown Source)
at service.CatalogService.main(CatalogService.java:77)


 Comments   
Comment by deepak vohra [ 24/Nov/13 ]
The design doc "catalog" is a variable.
Comment by Michael Nitschinger [ 25/Nov/13 ]
hi,

please in the future open spring tickets here: https://jira.springsource.org/browse/DATACOUCH

also, you need a design document with the name "catalog" and a view with the name "all". That returns a list of IDs for the subset of documents. It needs to be published to production, not in dev mode.
Comment by deepak vohra [ 25/Nov/13 ]
The default "production" is used. The requirement for a design document and a view is not mentioned in the Spring Data git page.
https://github.com/spring-projects/spring-data-couchbase

Why do the other methods not generate an exception if the design document and view are required?
Comment by deepak vohra [ 25/Nov/13 ]
May have closed the issue too early. A requirement for a view or design document is not mentioned in GIT nor on the Repositories documentation.

http://docs.spring.io/spring-data/data-jpa/docs/current/reference/html/repositories.html
Comment by deepak vohra [ 25/Nov/13 ]
Added the "catalog" design document and the "all" view and still getting the exception. The Console with the "all" view is listed.
http://i763.photobucket.com/albums/xx277/dvohra10/all_view_zps11dc43cc.jpg
http://i763.photobucket.com/albums/xx277/dvohra10/all_view1_zps1a05fdac.jpg
Comment by deepak vohra [ 25/Nov/13 ]
A reduce function was also required in the "all" view.

http://i763.photobucket.com/albums/xx277/dvohra10/all_view2_zps86018401.jpg

Thanks for your feedback. The exception is fixed if an "all" view is added with a map function and a reduce function.
 Issue may be considered Closed.
Comment by Michael Nitschinger [ 26/Nov/13 ]
HI,

yeah that's right.. sorry the docs for that are not up to date.. I'll also plan to add the requred function directly in the exception so you can copy/paste.




[JCBC-378] Upload autodocs for Java 1.2.2 Created: 13/Nov/13  Updated: 19/Nov/13  Resolved: 19/Nov/13

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

Type: Task Priority: Major
Reporter: Amy Kurtzman Assignee: Amy Kurtzman
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-370] Edit Java 1.2 guide Created: 15/Oct/13  Updated: 19/Dec/13  Resolved: 19/Dec/13

Status: Closed
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.2, 1.2.1
Fix Version/s: .future
Security Level: Public

Type: Task Priority: Major
Reporter: Amy Kurtzman Assignee: Amy Kurtzman
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Edit the current version of the Java SDK guide.

 Comments   
Comment by Michael Nitschinger [ 19/Dec/13 ]
Amy, is this still relevant? What are the open tasks here?
Comment by Amy Kurtzman [ 19/Dec/13 ]
This is done now.




[JCBC-379] If bucket details are incorrect, error message is unhelpful Created: 15/Nov/13  Updated: 18/Nov/13  Resolved: 18/Nov/13

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

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

Issue Links:
Duplicate
duplicates JCBC-324 Avoid NPE when Host is Up, but no CB ... Resolved

 Description   
If an incorrect bucket name or password is specified when connection (which is easier since bucket names are case-sensitive) the following error is thrown:
{code]
Caused by: java.lang.NullPointerException
at com.couchbase.client.vbucket.ConfigurationProviderHTTP.getBucketConfiguration(ConfigurationProviderHTTP.java:148)
at com.couchbase.client.CouchbaseConnectionFactory.getVBucketConfig(CouchbaseConnectionFactory.java:231)
at com.couchbase.client.CouchbaseClient.<init>(CouchbaseClient.java:237)
... 167 more
{code]

There should be additional checks in place to help guide the developer to fix the issue.

 Comments   
Comment by Brad Wood [ 15/Nov/13 ]
Darn, you guys don't have wiki markup enabled. You should do that, it's very handy for prettying up ticket descriptions.

Argh-- I can't edit my own ticket either to remove the {code} blocks :(
Comment by Brad Wood [ 15/Nov/13 ]
I didn't specify the affects version and since I can't edit it, I'll put it here. I'm on couchbase-client-1.1.7.jar. Hmm, I think there's a new version I should try to see if this is fixed.
Comment by Brad Wood [ 15/Nov/13 ]
Ok, just upgraded to couchbase-client-1.2.2.jar and the error message is the same, so this does affect the latest version.




[JCBC-235] Write the Java on Linux using Eclipse section of the Essentials Guide Created: 04/Feb/13  Updated: 19/Jul/13  Resolved: 19/Jul/13

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

Type: New Feature Priority: Major
Reporter: MC Brown (Inactive) Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by JCBC-243 Docs: Reference installation Resolved

 Description   
Write the Java on Linux 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 ]
Is the essentials guide still part of our docs efforts?
Comment by kzeller [ 19/Jul/13 ]
Let's just close them. Not now and now in the next 2-3 months.




[JCBC-225] ClusterManagerTest - Handle failure in testWithSomeBadAddrs Created: 30/Jan/13  Updated: 11/Mar/13  Resolved: 30/Jan/13

Status: Closed
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1.1
Fix Version/s: 1.1.2
Security Level: Public

Type: Bug Priority: Major
Reporter: Deepti Dawar Assignee: Deepti Dawar
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-176 Using BucketTool helper - error in co... Resolved

 Description   
Handle failure in testWithSomeBadAddrs.
The failure in this test is happening because the RuntimeException is not caught.


 Comments   
Comment by Deepti Dawar [ 30/Jan/13 ]
Checked in at http://review.couchbase.org/#/c/24299/
Comment by Deepti Dawar [ 11/Mar/13 ]
Merged into repository.




[JCBC-221] XDCR observe - java client Created: 28/Jan/13  Updated: 19/Dec/13  Resolved: 19/Dec/13

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

Type: Improvement Priority: Major
Reporter: Alex Ma Assignee: Michael Nitschinger
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Couchbase Server 2.0 GA with XDCR either across datacenters or AWS Regions

Issue Links:
Dependency
depends on MB-7614 XDCR: Provide Observe with XDCR Open

 Description   
Add functionality to the Java client so that request for observe can block the request until either persisted to disk, replicated to another node intra cluster or replicated to a remote cluster.

 Comments   
Comment by Dipti Borkar [ 28/Jan/13 ]
This needs additional internal discussion first.
Comment by Matt Ingenthron [ 28/Jan/13 ]
We also need some semblance of what kind of throughput and response times are reasonable. There are currently some architectural limitations that mean remote replication will take potentially quite a while. I'd be reticent to implement this without knowing if the end result is useable.
Comment by Michael Nitschinger [ 19/Dec/13 ]
This is not in scope since the client is one-bucket only.. Also, semantics change a lot over xdcr. This would be a much larger project in scope.




[JCBC-207] incorrect logic in reconnection threshold leads to never actually reconnecting Created: 09/Jan/13  Updated: 31/Jan/13  Resolved: 31/Jan/13

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

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

Issue Links:
Dependency
depends on SPY-108 ensure remote server is truly availab... Resolved

 Description   
In the CouchbaseConnectionFactory, the pastReconnThreshold() method doesn't correctly check the threshold time. It's using millis mixed with nanos.

 Comments   
Comment by Matt Ingenthron [ 09/Jan/13 ]
This is a regression of JCBC-19.
Comment by Matt Ingenthron [ 09/Jan/13 ]
It turns out this is not a regression. The way the test is being carried out is different in this case.

so, I worked out why this java failover isn't working. it's related to using kill -STOP


Here's the current behavior,
there's a per-node continuious operation timeout threshold
after a given node times out a bunch, the client will drop the connection to that node
then it'll try to reestablish it
meanwhile, there's another counter for how often we can't find an established connection to a node the config says we should be using
that second one, the algorithm is 10 failures to find the node in a 10 second window means re-bootstrap
so, the problem...
is that when we kill -STOP (instead of an actual cable pull)
you can still establish new connections to 11210
so, we drop and reestablish, send a bunch of stuff, then drop and reestablish quickly

but this algorithm that I'd tested with actual cable pulls will work with actual cable pulls, but it won't work (without big changes) in the sigstop case ingenthr
because we consider the connection "good" at the time of established, not at the time of sending data
maybe that's incorrect to do
Comment by Matt Ingenthron [ 09/Jan/13 ]
I think I've worked out an approach with Mark Nunberg's help.

We'll need to change spymemcached to verify the connection is actually good with a noop before calling it good. If it fails that, it'll go back to be reconnected. We may need backoff for this as well.
Comment by Michael Nitschinger [ 09/Jan/13 ]
Just as a note, the changesets I've pushed were tested against "freezing" a VM.




[JCBC-197] High Couchbase clients apps' CPU after upgraded from Couchbase Client 1.0.1 and spy 2.8.0 to 1.0.3 and 2.8.2. Created: 21/Dec/12  Updated: 21/Dec/12  Resolved: 21/Dec/12

Status: Closed
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.0.3
Fix Version/s: 1.0.3
Security Level: Public

Type: Bug Priority: Major
Reporter: Saran Kumar (Inactive) Assignee: Saran Kumar (Inactive)
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
 Incident #2373

Please see issue we encountered with our latest version below.

This passed QA on stage but when going on to a live environment with full production load we see the behavior below. At first this occurred on a cluster we had just rebalanced. During that rebalance we saw rise in couchbase clients apps' CPU, which did not decrease after the rebalance was (successfully) done, until we restarted said clients. We suspected that the problem below is directly related to the issues we saw during rebalance so we also tested it on a different cluster that did not go any such rebalance. Results were the same. After searching all over to see what changed we realized that one change during this version was that we upgraded from Couchbase Client 1.0.1 and spy 2.8.0 to 1.0.3 and 2.8.2. We then took that exact build swapping the 1.0.3 with the 1.0.1 jars and everything started behaving fine.

The reason we MUST have 1.0.3 on production is the following from 1.0.3's release notes (http://www.couchbase.com/docs/couchbase-sdk-java-1.0/couchbase-sdk-java-rn_1-0-3.html):

It was found that in the dependent spymemcached client library that errors encountered in optimized set operations would not be handled correctly and thus application code would receive unexpected errors during a rebalance. This has been worked around in this release by disabling optimization. This may have a negilgable drop in throughput but shorter latencies.

We believe the issues mentioned above on the clients during the rebalance are exactly this.

1. Any ideas on reason for this?
2. How would you advise to proceed.

Cheers,
Ira

Hi

1. One server is putting data to a memcached bucket. TTL is about 30 minutes.
2. Another server tries to get this data but randomly fails (at about of 50% miss rate). We are getting nulls instead of real values. We are using asyncGet and then Future.get() with timeout of 5 seconds. We did not observe that timeout was reached.
Time period between (1) and (2) is less than a minute. We debugged (1) and saw that it is being written without errors.
No exceptions or errors.
Data cluster wasn't heavy loaded, other clients (1.0.1) were working at the same time with this bucket and operated properly.

Sergey

From: Ira Holtzer




[JCBC-189] Views having odd timeout issues on some clusters Created: 18/Dec/12  Updated: 23/Jul/13  Resolved: 23/Jul/13

Status: Closed
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1.0
Fix Version/s: .future
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

Attachments: File failover-debug.args     Text File fo-dbg.log.txt     File vm-4nodes-2.ini    
Issue Links:
Dependency
depends on MB-7661 [Done, RN 2.1.0] View query on Rebala... Resolved
blocks JCBC-176 Using BucketTool helper - error in co... Resolved

 Description   
We're seeing really strange timeout issues which seem to affect only this specific cluster and only in terms of views. We've re-installed this cluster time and time again, and we've had similar configurations run successfully as well.

More details in comment..

 Comments   
Comment by Mark Nunberg [ 18/Dec/12 ]
Just try to do this with a simple java script (i.e. connect and query the view)
Comment by Deepti Dawar [ 20/Dec/12 ]
This issue persists when the view retrieval is ran from standalone java program as well.
I tried this on both the VMs - 10.3.3.203, 10.3.3.209.
Comment by Deepti Dawar [ 20/Dec/12 ]
Its working fine for server deployed on localhost.
Comment by Matt Ingenthron [ 02/Jan/13 ]
Michael: found out today that this is a large issue for SDKQE. Can you have a quick look at this in the next day? You may find the underlying issue.
Comment by Michael Nitschinger [ 03/Jan/13 ]
Please pass me the script as commented and then (or if you can't) please assign it back to me! Thanks
Comment by Michael Nitschinger [ 18/Jan/13 ]
According to the posted logs, it looks like debugging was not turned on. Can you please run this again with debugging turned on? To get the full logs to STDOUT, use this before initializing the CouchbaseClient in The App:

      // Tell spy to use the SunLogger
        Properties systemProperties = System.getProperties();
        systemProperties.put("net.spy.log.LoggerImpl", "net.spy.memcached.compat.log.SunLogger");
        System.setProperties(systemProperties);

        Logger.getLogger("com.couchbase.client").setLevel(Level.FINEST);

        //get the top Logger
        Logger topLogger = java.util.logging.Logger.getLogger("");

        // Handler for console (reuse it if it already exists)
        Handler consoleHandler = null;
        //see if there is already a console handler
        for (Handler handler : topLogger.getHandlers()) {
            if (handler instanceof ConsoleHandler) {
                //found the console handler
                consoleHandler = handler;
                break;
            }
        }

        if (consoleHandler == null) {
            //there was no console handler found, create a new one
            consoleHandler = new ConsoleHandler();
            topLogger.addHandler(consoleHandler);
        }

        //set the console handler to fine:
        consoleHandler.setLevel(java.util.logging.Level.FINEST);


Would be great if we can get all the output so we can investigate where the timeouts come from. I'm sure with a debug log it will be much easier. Thanks!
Comment by Mark Nunberg [ 23/Jan/13 ]
So this bug isn't such an "unknown" anymore, and has exposed itself in 1.1.0 as well as 1.1.1 and isn't limited to particular clusters - (it just seems that some clusters are more likely than others to trigger this bug).

However this still needs a lot of care and analysis
Comment by Michael Nitschinger [ 01/Feb/13 ]
This is "kinda" blocker.
Comment by Deepti Dawar [ 23/Jul/13 ]
JCBC-189 was primarily related to the timeouts and environmental issues. Now, after some progress in this, its figured out that these env related issues have been ironed out with the latest set up of the client and server VMs.
Also, the issue that remains now is very specific to the cluster and the client which can be tracked as part of a new JCBC issue - JCBC-333




[JCBC-187] Incorrect code in tutorial/doc Created: 15/Dec/12  Updated: 19/Dec/12  Resolved: 17/Dec/12

Status: Closed
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.1.0
Fix Version/s: 1.1.0, 1.1.1
Security Level: Public

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


 Description   
On the page found at http://www.couchbase.com/develop/java/current, in the second code block under "Working with Views", the 7th line of code is:

ViewResponse result = client.query(view, query);

Except that the view variable has never been defined, so this code won't compile.

 Comments   
Comment by Matt Ingenthron [ 17/Dec/12 ]
Ted: Thanks for reporting it.
Comment by Michael Nitschinger [ 19/Dec/12 ]
fixed.




[JCBC-174] Add all Java IDE in .gitignore file Created: 08/Dec/12  Updated: 04/Jan/13  Resolved: 04/Jan/13

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

Type: Improvement Priority: Major
Reporter: Tug Grall (Inactive) Assignee: Tug Grall (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 1h
Time Spent: Not Specified
Original Estimate: 1h


 Description   
The gitignore file contains only the information to exclude Eclipse files/folders.

We need to add other IDE such as Netbeans and IDEA




[JCBC-172] Clarify that getView returns a handle/future like object and not an actual rowset Created: 07/Dec/12  Updated: 14/Jan/13  Resolved: 14/Jan/13

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

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


 Description   
In the getting started guide, there isn't an example showing how to get a View object and how exactly it's used with cb.query(). This is mentioned in the tutorial and somewhat implied in retrospect. Would be nice to clearly show an example;

e.g.

View view = cb.getView("deignDoc", "viewQuery");
Query = new Query();
// ...
ViewResponse resp = cb.query(view, query);

etc.

 Comments   
Comment by Michael Nitschinger [ 14/Jan/13 ]
Is this not enough? http://www.couchbase.com/docs/couchbase-sdk-java-1.1/read-docs.html
Comment by Michael Nitschinger [ 14/Jan/13 ]
Is this not enough info Mark?

http://www.couchbase.com/docs/couchbase-sdk-java-1.1/read-docs.html
Comment by Mark Nunberg [ 14/Jan/13 ]
Yes, I've looked at the link and it's good enough - this was probably not there when I filed the bug




[JCBC-170] Update java documentation in the SDK. Created: 06/Dec/12  Updated: 05/Feb/13  Resolved: 31/Jan/13

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

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


 Description   
Update java documentation in the SDK.

 Comments   
Comment by Deepti Dawar [ 11/Dec/12 ]
Fixed and Checked it in gerrit.
Its under review.
Comment by Deepti Dawar [ 02/Jan/13 ]
Hi Matt, Michael,

Please review at

http://review.couchbase.org/#/c/23021/18

Regards,
Deepti
Comment by Michael Nitschinger [ 31/Jan/13 ]
closing since it has been merged.




[JCBC-322] Add new junit tests related to retrieve, store ops in cbc Created: 27/Jun/13  Updated: 10/Jul/13  Resolved: 10/Jul/13

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

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

Issue Links:
Dependency

 Comments   
Comment by Deepti Dawar [ 10/Jul/13 ]
Need to change the title of the issue.




[JCBC-305] Client does not recover with Memcached connection to the server and primary node goes down. Created: 21/May/13  Updated: 19/Jul/13  Resolved: 19/Jul/13

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

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

Attachments: Text File mem_all_nodes_input.log     Text File mem_primary_node_failure.log    
Issue Links:
Dependency
depends on JCBC-319 Force Resubscribing in CouchbaseMemca... Resolved

 Description   
2013-05-21 12:59:04.158 ERROR net.spy.memcached.protocol.ascii.StoreOperationImpl: Error: SERVER_ERROR temporary failure
 Deepti Exception 1 java.util.concurrent.ExecutionException: OperationException: SERVER: SERVER_ERROR temporary failure
2013-05-21 12:59:04.158 INFO net.spy.memcached.MemcachedConnection: Reconnection due to exception handling a memcached operation on {QA sa=/10.3.121.207:11211, #Rops=2, #Wops=0, #iq=0, topRop=Cmd: add Key: Emp0000000365cbc Flags: 0 Exp: 0 Data Length: 79, topWop=null, toWrite=0, interested=8}. This may be due to an authentication failure.
OperationException: SERVER: SERVER_ERROR temporary failure
at net.spy.memcached.protocol.BaseOperationImpl.handleError(BaseOperationImpl.java:164)
at net.spy.memcached.protocol.ascii.OperationImpl.readFromBuffer(OperationImpl.java:151)
at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:537)
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:430)
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:247)
at net.spy.memcached.MemcachedConnection.run(MemcachedConnection.java:915)
2013-05-21 12:59:04.159 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000366cbc.
2013-05-21 12:59:04.159 WARN net.spy.memcached.MemcachedConnection: Closing, and reopening {QA sa=/10.3.121.207:11211, #Rops=2, #Wops=0, #iq=0, topRop=Cmd: add Key: Emp0000000365cbc Flags: 0 Exp: 0 Data Length: 79, topWop=null, toWrite=0, interested=8}, attempt 22.
2013-05-21 12:59:04.159 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000366cbc.
2013-05-21 12:59:04.159 WARN net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl: Discarding partially completed op: Cmd: add Key: Emp0000000365cbc Flags: 0 Exp: 0 Data Length: 79
2013-05-21 12:59:04.160 WARN net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl: Discarding partially completed op: Cmd: version
2013-05-21 12:59:04.160 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000366cbc.
2013-05-21 12:59:04.160 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000366cbc.
 Deepti Exception 1 java.lang.RuntimeException: Timed out waiting for operation
2013-05-21 12:59:06.660 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000367cbc.
2013-05-21 12:59:06.661 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000367cbc.
 Deepti Exception 1 java.lang.RuntimeException: Timed out waiting for operation
2013-05-21 12:59:09.163 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000368cbc.
2013-05-21 12:59:09.164 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000368cbc.
 Deepti Exception 1 java.lang.RuntimeException: Timed out waiting for operation
2013-05-21 12:59:11.666 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000369cbc.
2013-05-21 12:59:11.667 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000369cbc.
 Deepti Exception 1 java.lang.RuntimeException: Timed out waiting for operation
2013-05-21 12:59:14.168 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000370cbc.
2013-05-21 12:59:14.169 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000370cbc.
 Deepti Exception 1 java.lang.RuntimeException: Timed out waiting for operation
2013-05-21 12:59:16.671 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000371cbc.
2013-05-21 12:59:16.672 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000371cbc.
 Deepti Exception 1 java.lang.RuntimeException: Timed out waiting for operation
2013-05-21 12:59:19.174 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000372cbc.
2013-05-21 12:59:19.175 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000372cbc.
 Deepti Exception 1 java.lang.RuntimeException: Timed out waiting for operation
2013-05-21 12:59:21.677 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000373cbc.
2013-05-21 12:59:21.678 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000373cbc.
 Deepti Exception 1 java.lang.RuntimeException: Timed out waiting for operation
2013-05-21 12:59:24.179 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000374cbc.
2013-05-21 12:59:24.180 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000374cbc.

 Comments   
Comment by Deepti Dawar [ 21/May/13 ]
In this case, server is stopped one by one on all the server nodes starting with the primary node.
Even when the first node is brought up, the client does not recover. It recovers much after all the nodes are started and are active in the cluster.
Comment by Deepti Dawar [ 21/May/13 ]
One more observation, the client is only trying to insert data to the server nodes. Even if the primary node fails, it should not wait for the recovery of this node, instead should point to the other active node of the cluster and add the data there.
Not sure of the behavior here. Matt, can you please help me in understanding what should be the correct behavior in this case.
Comment by Deepti Dawar [ 21/May/13 ]
When all nodes are given as input, then also the behavior remains the same or even worse. Now getting the ConcurrentExecutionException while cancelling the connection to the primary node when it goes down. Attatched is the log.
Comment by Michael Nitschinger [ 19/Jul/13 ]
This should be fixed as of now, because the resubscribing is now handling on memcache buckets as well.

Please note that we track pure SPY issues in the SPY jira.




[JCBC-304] Client leads to a deadlock when all the servers are unavailable Created: 21/May/13  Updated: 19/Jul/13  Resolved: 19/Jul/13

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

Type: Bug Priority: Major
Reporter: Deepti Dawar Assignee: Matt Ingenthron
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
Duplicate
duplicates JCBC-308 Trouble in resubscribing to primary n... Closed

 Description   
Stack Trace :-

"pool-17-thread-8" prio=10 tid=0x00007fdea007c800 nid=0xacac waiting on condition [0x00007fdf168e6000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for <0x00000007f8d383f0> (a java.util.concurrent.CountDownLatch$Sync)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.jav
a:994)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:
1303)
        at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
        at com.couchbase.client.vbucket.BucketUpdateResponseHandler.getReceivedFuture(BucketUpdateResponseHandler.java:147)
        at com.couchbase.client.vbucket.BucketUpdateResponseHandler.getLastResponse(BucketUpdateResponseHandler.java:127)
        at com.couchbase.client.vbucket.BucketMonitor.startMonitor(BucketMonitor.java:212)
        at com.couchbase.client.vbucket.ConfigurationProviderHTTP.subscribe(ConfigurationProviderHTTP.java:333)
        - locked <0x00000007f81cb9c0> (a com.couchbase.client.vbucket.ConfigurationProviderHTTP)
        at com.couchbase.client.CouchbaseClient.<init>(CouchbaseClient.java:247)

    

 Comments   
Comment by Deepti Dawar [ 23/May/13 ]
The usage of CountDownLatch here in BucketMonitor may not be quite justified in the case where the user application is calling this from a multi-threaded env in a non-synchronized manner.
Here either our code needs to be intelligent enough to avoid deadlocks or the calling application needs to be aware of the same.

Looking at the customer issue which lead to this, their usage of the CouchbaseClient instance seems incorrect.

Matt, Can you please suggest ?




[JCBC-331] documentation reformatting for 1.2 manual Created: 17/Jul/13  Updated: 19/Jul/13  Resolved: 19/Jul/13

Status: Closed
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.2
Fix Version/s: 1.2
Security Level: Public

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


 Description   
We have a next generation documentation layout, and the 1.2 release is the appropriate time to try to complete it. Filing here so we can track it as a documentation item.

 Comments   
Comment by Matt Ingenthron [ 17/Jul/13 ]
Dipti: please track to the appropriate sprint for an August release, and then reassign back to Michael.
Comment by kzeller [ 17/Jul/13 ]
Please make a separate subtask for me to create the directory and also migrate my edited "next generation" files there.
Comment by Michael Nitschinger [ 18/Jul/13 ]
Sounds good.

Karen, can you quickly clarify on the actual process? I think we should by now migrate the current infos (leaving the outdated/not needed files behind) to the new layout and then I start updating the content in there. 1.2 is not radically new so there would be lots of overlap/content that stays the same.

Thanks,
Michael
Comment by kzeller [ 18/Jul/13 ]
So there is a java-sdk-NG file where I had overhauled and edited the tutorial back prior to 2.1 when we had discussed doing a more significant overhaul of the Language References, starting with Java. The rest of the sections I left un-touched. So I can copy the existing java-1.1 docs into a whole new directory labeled 1.2 but put the tutorial.xml from -NG in there.

Sound good?
Comment by Michael Nitschinger [ 18/Jul/13 ]
yeah I think we should first migrate the existing 1.1 to 1.2 first, then just change the stuff that needs change - and then move on with the -ng refactoring!
Comment by kzeller [ 19/Jul/13 ]
ok. Will close for now then. Java 1.2 files set up in GitHub. Please fetch the latest from master branch.




[JCBC-329] Add new junit tests in the view connection and query tests Created: 10/Jul/13  Updated: 19/Dec/13  Resolved: 19/Dec/13

Status: Closed
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1.8
Fix Version/s: .future
Security Level: Public

Type: Improvement Priority: Major
Reporter: Deepti Dawar Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency

 Description   
Add new junit tests in the view connection and query tests.
More negative cases for View connection tests.
Also improve view query tests as per the test plan.

 Comments   
Comment by Deepti Dawar [ 15/Jul/13 ]
http://review.couchbase.org/#/c/27386/
Comment by Deepti Dawar [ 21/Aug/13 ]
Mark, Please advice, do we have to write mock code which fails to connect to the View Node ?
Otherwise we cannot get the node failure every time we test.
Comment by Michael Nitschinger [ 19/Dec/13 ]
With 1.3 upcoming the view connection has been revamped and tests added, so this is not needed anymore. Let's open specific tickets if we need more coverage on the new one.




[JCBC-299] ClassCastException in CouchbaseClient for the memcached connection Created: 09/May/13  Updated: 10/May/13  Resolved: 10/May/13

Status: Closed
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: None
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

Attachments: Text File mem_bkt_failover_1.1.6_server1.8.1_working_fyn.log     Text File mem_bkt_failover_1.1.6_server2.0.1_working_fyn.log     Text File mem_bkt_faiover_1.1.6.log     Text File mem_bkt_readd_1.1.6.log     Text File mem_bkt_readd_1.1.6_server1.8.1_working_fyn.log     Text File mem_bkt_readd_1.1.6_server2.0.1_working_fyn.log     Text File mem_bkt_rebalance_1.1.6.log     Text File mem_bkt_rebalance_1.1.6_server1.8.1_working_fyn.log     Text File mem_bkt_rebalance_1.1.6_server2.0.1_working_fyn.log    

 Description   
For all the tests running on CouchbaseMemcachedConnection, ClassCastException occurs while casting the instance of the CouchbaseMemcachedConnection to CouchbaseConnection.

PFA the logs of run.

 Comments   
Comment by Deepti Dawar [ 10/May/13 ]
As per the latest run using cbc-1.1.6 and server-1.8.1, 2.0.1, these scenarios are all working fine.
Hence, closing the issue.




[JCBC-286] Copyedit MichaelN blog on Java SDK Internals Created: 16/Apr/13  Updated: 26/Apr/13  Resolved: 26/Apr/13

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

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


 Description   
Couchbase Java SDK Internals
============================

## Motivation
This blog post is intended to be a very detailed and informative article for those who already have used the Couchbase Java SDK and want to know how the internals work. This is not a introduction on how to use the Java SDK and we'll cover some fairly advanced topics on the way.

Normally, when talking about the SDK we mean everything that is needed to get you going (Client library, documentation, release notes,...). In this article though, the SDK refers to the Client library (code) unless stated otherwise.

As always, if you have feedback please let me/us know!

## Introduction
First and foremost, its important to understand that the SDK wraps and extends the functionality of the [spymemcached]() (called "spy") memcached library. One of the protocols used internally is the memcached protocol, and a lot of functionality can be reused. On the other hand, once you start to peel off the first layers of the SDK you will notice that some components are somewhat more complex because of the fact that spy provides more features than the SDK needs in the first place. The other part is to remeber that a lot of the components are intervoven, so you always need to get the dependency right. Most of the time, we release a new spy version at the same date with a new SDK, because new stuff has been added or fixed.

So, aside from reusing the functionality provided by spy, the SDK mainly adds two blocks of functionality: automatic cluster topology management and since 1.1 (and 2.0 server) support for Views. Aside from that it also provides admnistrative facilities like bucket and design document management.

To understand how the client operates, we'll dissect the whole process in different life cycle phases of the client. After we went through all three phases (bootstrap, operation and shutdown) you should have a clear picture of whats going on under the hood. Note that there is a separate blog post in the making about error handling, so we won't cover that here in greater detail.

## Phase 1: Bootstrap
Before we can actually start serving operations like `get()` and `set()`, we need to bootstrap the `CouchbaseClient` object. The important part that we need to accomplish here is to initially get a cluster configuration (which contains the nodes and vBucket map), but also to establish a streaming connection to receive cluster updates in (near) real-time.

We take the list of nodes passing during bootstrap and iterate over it. The first node in the list that can be contacted on port 8091 is used to walk the RESTful interface on the server. This means that going from the provided `http://host:port/pools` URI we eventually follow the links to the bucket entity. All this happens inside a `ConfigurationProvider`, which is in this case the `com.couchbase.client.vbucket.ConfigurationProviderHTTP`. If you want to poke around on the internals, look for `getBucketConfiguration` and `readPools` methods.

A (successful) walk can be illustrated like this:

  1: GET /pools
  2: look for the "default" pools
  3: GET /pools/default
  4: look for the "buckets" hash which contains the bucket list
  5: GET /pools/default/buckets
  6: parse the list of buckets and extract the one provided by the application
  7: GET /pools/default/buckets/<bucketname>

Now we are at the configuration page that we need. On this JSON response, you'll find all useful details that gets also be used inside the Client SDK (for example `streamingUri`, `nodes` and `vBucketServerMap`). The config gets parsed and stored. Before we move on, let's quickly discuss the strange `pools` part inside our REST walk:

The concept of a resource pool to group buckets was concepted for Couchbase Server, but never fully implemented. Still, the REST API is implemented that way and therefore all client SDKs have to deal with it. That said, while we could theoretically just go directly to `/pools/default/buckets` and skip the first few queries, the feature might come back at some time and that way the SDK is architected more future-proof.

Back to our bootstrap phase. Now that we have a valid cluster config which contains all the nodes (and their hostnames or ip addresses), we can establish connections to them. Aside from establishing the data connections, we also need to instantiate a streaming connection to one of them. For simplicity reasons, we just establish the streaming connection to the node from the list where we got our initial configuration.

This gets us to a valid point upfront: if you have lots of CouchbaseClient objects running on many nodes and they all get bootstrapped with the same list, they may end up connecting to the same node for the streaming connection. Therefore, to distribute the load a little better I recommend shuffling the array before it gets passed in to the CouchbaseClient object. When you only have a few CouchbaseClient objects connected to your cluster, that won't be a problem at all.

The streaming connection URI is taken from the config we got previously, and normally looks like this:

        streamingUri: "/pools/default/bucketsStreaming/default?bucket_uuid=88cae4a609eea500d8ad072fe71a7290"

If you point your browser to this address, you will also get the updates streamed in real-time. Since the streaming connection needs to be established all the time and potentially blocks a thread, this is done in the background handled by different threads. We are using the NIO framework [Netty]() for this task, which provides a very handy way of dealing with asynchronous operations. If you want to start digging into this part, keep in mind that all read operations are completely separate from write operations, so you need to deal with handlers that take care of what comes back from the server. Aside from some wiring needed for Netty, the business logic can be found in `com.couchbase.client.vbucket.BucketMonitor` and `com.couchbase.client.vbucket.BucketUpdateResponseHandler`. We also try to reestablish this streaming connection if the socket gets closed (for example if this node gets rebalanced out of the cluster).

To actually shuffle data to the cluster nodes, we need to open various sockets to them. Note that there is absolutely no connection pooling needed inside the client, because we manage all sockets proactively. Aside from the special streaming connection to one of the severs (which is opened against port 801), we need to open the following connections:

 - Memcached Socket: Port 11210
 - View Socket: Port 8092

Note that port 11211 is not used inside the client SDKs, but used to connect vanilly memcached clients that are not cluster aware. Using this inherits some overhead, so the SDK will be faster in general.

So as a rule of thumb, if you have a 10 node cluster running, one CouchbaseClient object open about 21 (2*10 + 1) client sockets. These are directly managed, so if a node gets removed or added the numbers will change accordingly.

Now that all sockets have been opened, we are ready to perform regular cluster operations. As you can see, there is a lot of overhead involved when the CouchbaseClient object gets bootstrapped. Because of this fact, we strongly discourage you from either creating a new object on every request or running a lot of CouchbaseClient objects in one application server. This only adds unnecessary overhead and load on the application server and adds on the total sockets opened against the cluster.

## Phase 2: Operations
When the SDK is bootstrapped, it allows to run operations against the attached cluster. For the purpose of this blog post, we need to distinguish between operations that get executed against a stable cluster and one that is currently experiencing some form of intability (be it planned because of adding nodes or unplanned because of a node failure). Let's tackle the regular operations first.

### Operations against a stable cluster
While not directly visible in the first place, inside the SDK we need to distinguish between memcached operations and View operations. All operations that have a uniqe key in their method signature can be treaded as memached operations. All of them eventually end up getting funneled through spy. View operations on the other hand are implemented completely inside the SDK itself.

Both View and memcached operations are asynchronous. Inside spy, there is one thread (call the I/O thread) dedicated to deal with IO operations. Note that in hight-traffic environments, its not unusual that this thread is always active. It uses the non-blocking Java NIO mechanisms to deal with traffic, and loops around "selectors" that get notified when data can either be written or read. If you profile your application and you'll see that this thread spends most of its time waiting on a `select` method, it means that it is idling there waiting to be notified for new traffic. The concepts used inside spy to deal with this are common Java NIO knowledge, so you may want to look into the NIO internals first before digging into that code path. Good starting points are the `net.spy.memcached.MemcachedConnection` and `net.spy.memcached.protocol.TCPMemcachedNodeImpl` classes. Note that inside the SDK, we override the `MemcachedConnection` to hook in our own reconfiguration logic. This class can be found inside the SDK at `com.couchbase.client.CouchbaseConnection` and for memcached-type buckets in `com.couchbase.client.CouchbaseMemcachedConnection`.

So if a memcached operations (like `get()`) gets issued, it gets passed down until it reaches the IO thread. The IO thread will then put it on a write queue towards its target node. It gets written eventually and then the IO thread adds information to a read queue so the responses can be mapped accordingly. This approach is based on futures, so when the result actually arrives, the Future is marked as completed, the result gets parsed and attached as Object.

The SDK only uses the memcached binary protocol, altough spy would also support ASCII. The binary format is much more efficient and some of the advanced operations are only implemented there.

You may wonder how the SDK knows to which node to send the operation? Since we already have the up-to-date cluster map, we can hash the key and then based on the node list and vBucketMap determine which node to access. The vBucketMap not only contains the master node of the array, but also zero to three replica nodes. Look at this (shortened) example:

        vBucketServerMap: {
        hashAlgorithm: "CRC",
        numReplicas: 1,
        serverList: [
                "192.168.56.101:11210",
                "192.168.56.102:11210"
        ],
        vBucketMap: [
        [0,1],
        [0,1],
        [0,1],
        [1,0],
        [1,0],
        [1,0]
        //.....
        },

The `serverList` contains our nodes, and the `vBucketMap` has pointers to the `serverList` array. We have 1024 vbuckets, so only some of them are shown here. You can see from looking at it that all keys that has into the first vbucket have its master node at index 0 (so the `.101` node) and its replica at index 1 (so the `.102` node). Once the cluster map changes and the vBuckets move around, we just need to update our config and know all the time where to point our operations towards.

View operations are handled differently. Since views can't be sent to a specific node (because we don't have a way to hash a key or something), we round-robin between the connected nodes. The operation gets assigned to a `com.couchbase.client.ViewNode` once it has free connections and then executed. The result is also handled through futures. To implement this functionality, the SDK uses the third party Apache HTTP Commons (NIO) library.

The whole View API hides behind port 8092 on every node and is very similar to [CouchDB](). It also contains a RESTful API, but the structure is a little bit different. For example, you can reach a design document at `/<bucketname>/_design/<designname>`. It contains the View definitions in JSON:

        {
                language: "javascript",
                views: {
                        all: {
                                map: "function (doc) { if(doc.type == "city") {emit([doc.continent, doc.country, doc.name], 1)}}",
                                reduce: "_sum"
                        }
                }
        }

You can then reach down one level further like `/<bucketname>/_design/<designname>/_view/<viewname>` to actually query it:

        {"total_rows":9,"rows":[
        {"id":"city:shanghai","key":["asia","china","shanghai"],"value":1},
        {"id":"city:tokyo","key":["asia","japan","tokyo"],"value":1},
        {"id":"city:moscow","key":["asia","russia","moscow"],"value":1},
        {"id":"city:vienna","key":["europe","austria","vienna"],"value":1},
        {"id":"city:paris","key":["europe","france","paris"],"value":1},
        {"id":"city:rome","key":["europe","italy","rome"],"value":1},
        {"id":"city:amsterdam","key":["europe","netherlands","amsterdam"],"value":1},
        {"id":"city:new_york","key":["north_america","usa","new_york"],"value":1},
        {"id":"city:san_francisco","key":["north_america","usa","san_francisco"],"value":1}
        ]
        }

Once the request is sent and a response gets back, it depends on the type of View request to determine on how the response gets parsed. It makes a difference, because reduced View queries look different than non-reduced. The SDK also includes support for spatial Views and they need to be handled differently as well.

The whole View response parsing implementation can be found inside the `com.couchbase.client.protocol.views` namespace. You'll find abstract classes and interfaces like `ViewResponse` in there, and then their special implementations like `ViewResponseNoDocs`, `ViewResponseWithDocs` or `ViewResponseReduced`. It also makes a different if `setIncludeDocs()` is used on the Query object, because the SDK also needs to load the full documents using the memcached protocol behind the scenes. This is also done while parsing the Views.

Now that you have a basic understanding on how the SDK distributes its operations under stable conditions, we need to cover an important topic: how the SDK deals with cluster topology changes.

### Operations against a unstable cluster
Note that there is a separate blog post upcoming dealing with all the scenarios that may come up when something goes wrong on either the cluster or the SDK, so this post deals more with the internals and what needs to be done inside the SDK.

As mentioned earlier, the SDK receives topology updates through the streaming connection. Leaving the special case aside where this node actually gets removed or fails, all updates will come in near real-time (because in a eventually consistent architecture, it may take some time until the cluster updates get populated to that node). The chunks that come in over the stream look exactly like the ones we've seen when reading the initial configuration. After those chunks have been parsed, we need to check if the changes really affect the SDK (since there are many more parameters than the SDK needs, it won't make sense to listen to all of them). All changes that affect the topology and/or vBucket map are considered as important. If nodes get added or removed (be it either through failure or planned), we need to open or close the sockets. This process is called "reconfiguration".

Once such a reconfiguration is triggered, lots of actions need to happen in various places (spy needs to handle its sockets, view nodes need to be managed and new configuration needs to be updated). The SDK makes sure that only one reconfiguration can happen at the same time through locks so we don't have any race conditions going on.

The Netty-based `BucketUpdateResponseHandler` triggers the `CouchbaseClient#reconfigure` method, which then starts to dispatch everything. Depending on the bucket type used (i.e. memcached type buckets don't have Views and therefore no ViewNodes), configs are updated and sockets closed. Once the reconfiguration is done, it can receive new ones. During planned changes, everything should be pretty much controlled and no operations should fail. If a node is actually down and not reachable, those operations will be cancelled. Reconfiguration is tricky because the topology changes while operations are flowing through the system.

Finally, let's cover some differences between Couchbase and Memcache type buckets. All the vBucket part that you've been reading previously only applies to Couchbase buckets. Memcache buckets are pretty basic and are treated that way. Since you don't have vBuckets, all tha the Client has to do is to manage the nodes and their sockets. Also, a different hashing algorithm is used (Ketama) by default to determine the target node for each key. Also, memcache buckets don't have views, so you can't use the View API and it doesn't make much sense to keep View sockets around. So to clarify the previous statement, if you are running against a memcache bucket, for a 10 node cluster you'll only have 11 open connections.

Phase 3: Shutdown
-----------------
Once the `CouchbaseClient#shutdown()` method is called, no more operations are allowed to be added onto the `CouchbaseConnection`. Aside from that, until the timeout is reached, the client wants to make sure that all operations went through accordingly. All sockets for both memcached and View connections are shut down once there are no more operations in the queue (or they get dropped). Note tha that the `shutdown` methods on those sockets are also used when a node gets removed from the cluster during normal operations, so it's basically the same, but just for all attached nodes at the same time.

Summary
-------
After reading this blog post, you should have a much more clear picture on how the client SDK works and why its architected the way it is. We have lots of enhancements planned for future releases, mostly enhancing the direct API experience. Note that this blog post didn't cover how errors are handled inside the SDK, this will be published in a separate blog post (because there is also lots of information to cover).


 Comments   
Comment by kzeller [ 16/Apr/13 ]
Input/Clarification-Needed/Edits:

-remember => remember
-admnistrative => administrative
-we went => we go
-Note that there is a separate blog post in the making about error handling, so we won't cover that here in greater detail. => link to it from this blog, or if it does not yet exist, say it will be coming in x timeframe.
-The first node in the list that can be contacted on port 8091 is used to walk the RESTful interface on the server. => you might want to add that one you create the connection, the client can automatically handle node failure and adapt by going to another node in the cluster.
-Now we are at the configuration page that we need => at the REST endpoint we need.
-that gets also be used => that you can also use from
-concepted => designed
-but never fully implemented. Still, the REST API is implemented that way and therefore all client SDKs have to deal with it. => Product Marketing/PM probably wants us to put a positive spin on this. Suggestion => and is still in the process of being implemented, therefore the SDKs provide an abstraction layer so that you as a developer do not have to worry about it.
-the feature might come back at some time. Same point as prior. Suggestion => the API is subject to change so….
-This gets us to a valid point upfront: => This gets us to an important point to keep in mind….
-they may end up connecting to the same node for the streaming connection => describe problem that can occur here
-the updates streamed => the cluster topology updates streamed
-(which is opened against port 801) => default is 8091
-vanilly memcached clients (bad association: didn't that guy try to kill himself for lip synching?) => generic memcached clients
-that are not cluster aware. => Add "This means that these generic clients do not get updated cluster topologies."
-adds on the total sockets => adds the total sockets … resulting in a performance problem….
-it allows to run => it enables your application to run
-and one => and operations on a cluster that….
-intability => instability
-uniqe => unique
-memached -> memcached
-hight=> high-traffic
-and you'll see => you'll see
-its => it's
-you may want to look into the NIO internals first => cross reference to good third party info you can recommend on topic
-altough => although
-to which node => where
-The vBucketMap not only contains the master node of the array, but also zero to three replica nodes => change to information for master node, but also the information for zero to three….
-vbuckets => vBuckets
-## Phase 2: Operations => would break this section and the one sub-subsection into just two at the same header level: 1) Read/Writes Ops on Stable Cluster, 2) View Ops on Stable Cluster. Same approach for unstable cluster sections.
-The whole View response parsing implementation can be found inside the `com.couchbase.client.protocol.views` namespace. => cross-reference that part of your Javadoc
-or the SDK, so => SDK. So
-(because => . This is because + remove )
-(spy needs => convert into regular sentence
-and not reachable, => and cannot be reached
-All the vBucket part => replace part with information
-Memcache buckets are pretty basic and are treated that way. => ….do not have vBucket and behave like a single container for cached data…..
-Aside from that, until the timeout is reached, => Until the timeout is reached,
-tha that => that
-its architected the way it is => it is designed….
-Note that this blog post didn't cover how errors are handled inside the SDK, this will be published in a separate blog post (because there is also lots of information to cover). => Note that this blog post didn't cover how errors are handled inside the SDK; this will be published in a separate blog post because there is also lots of information to cover.




[JCBC-267] Memcached bucket still fails with all workloads Created: 12/Mar/13  Updated: 14/May/13  Resolved: 10/May/13

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

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

Attachments: Text File assertion_error_mem_bkt.log     Text File mem_bkt_base_raw_1.1.4.log     Text File mem_bkt_failover_1.1.6_server1.8.1_working_fyn.log     Text File mem_bkt_failover_1.1.6_server2.0.1_working_fyn.log     Text File mem_bkt_faiover_1.1.6.log     Text File mem_bkt_latest_run_1.1.4.log     Text File mem_bkt_readd_1.1.6.log     Text File mem_bkt_readd_1.1.6_server1.8.1_working_fyn.log     Text File mem_bkt_readd_1.1.6_server2.0.1_working_fyn.log     Text File mem_bkt_rebalance_1.1.6.log     Text File mem_bkt_rebalance_1.1.6_server1.8.1_working_fyn.log     Text File mem_bkt_rebalance_1.1.6_server2.0.1_working_fyn.log     Text File memcached_bucket_basic_json.log     Text File memcached_bucket_basic.log     Text File memcached_bucket_failover.log     Text File memcached_bucket_readd.log     Text File memcached_bucket_rebalance.log     GZip Archive test_run.tar.gz    
Issue Links:
Dependency
Duplicate
is duplicated by JCBC-271 Adding a node to an existing cluster ... Resolved

 Description   
Attaching all the tests ran against memcached buckets.

1) Basic tests - the gets fail, whereas the sets pass.

2) Failover and readd - Here there are many assertion errors with the I/O being problematic

3) Rebalance - Here there are many assertion errors with the I/O being problematic

In 2nd and 3rd cases, the probable cause may be the following -

[SDKD(WARNING) 268.72 cbsdk.sdkd.local executor.py:66] Exception in thread "Memcached IO over {MemcachedConnection to /10.3.121.212:11210 /10.3.121.208:11210}" java.lang.AssertionError: Attempting to overwrite channel
[SDKD(WARNING) 268.72 cbsdk.sdkd.local executor.py:66] at net.spy.memcached.protocol.TCPMemcachedNodeImpl.setChannel(TCPMemcachedNodeImpl.java:496)

4) Failover - Here there are failures in the rebalance phase, bt the rebound phase breaks in SDKD. Another SDKD issue is filed to take care of the same.

We also need to investigate the SDKD code. There might be something wrong there in handling the memcached buckets. But, till now the issue looks more likely to be with the java sdk.

 Comments   
Comment by Michael Nitschinger [ 18/Mar/13 ]
The AssertionError has reportedly been fixed (JCBC-271), can you please rerun the tests and see what still fails?
Comment by Deepti Dawar [ 18/Mar/13 ]
Hi Michael,

Please find the latest report.

Other than the assertion errors, I am getting few exceptions with the setting up of view time outs.
This has been tested with the latest merged code.

Hence, Its not getting fixed with the fix for JCBC-271.
Please let me know if you have some findings to state otherwise.

Regards,
Deepti
Comment by Michael Nitschinger [ 18/Mar/13 ]
Hi Deepti,

please use HEAD instead of the 1.1.3 tag, it does not represent the latest changes. The output log shows this:

[DEBUG 34.58 cbsdk.driver driver.py:48] INFO:0 @0 (OK) {'COMPONENTS': {'SPY': 'Spymemcached 2.8.12\n\nTree Version: 2.8.12\nLast Commit ID: 84ebf9ad0d0d8a64497d956f6e75bf74cd7883de\n\nCompiled by michael@daschlbook.local on Fri Mar 1 01:15:26 CET 2013', 'SDK': 'Couchbase Java Client 1.1.3\n\nTree Version: 1.1.3\nLast Commit ID: eaff6b0e67af7665301aa749722c97023e6d653b\n\nCompiled by michael@daschlbook.local on Mon Mar 4 15:17:27 CET 2013'},


84ebf9ad0d0d8a64497d956f6e75bf74cd7883de is not the correct one.

The correct one is: 053c653ebbbb5da14cb9398447acc40c1f63552d

You can see that is was compiled on my machine on 04th March.

Thanks, Michael
Comment by Deepti Dawar [ 26/Mar/13 ]
Hi Michael,

I have attached the log of run pertaining to the latest version.
It still has the errors.

 'COMPONENTS': { 'SDK': 'Couchbase Java Client 1.1.4\n\nTree Version: 1.1.4\nLast Commit ID: 0958708ab0425a8b91c3e32d7e07d577b50a92b8\n\nCompiled by michael@daschlbook.local on Wed Mar 13 09:31:34 CET 2013',
'SPY': 'Spymemcached 2.8.12\n\nTree Version: 2.8.12\nLast Commit ID: 84ebf9ad0d0d8a64497d956f6e75bf74cd7883de\n\nCompiled by michael@daschlbook.local on Fri Mar 1 01:15:26 CET 2013'}}
Comment by Michael Nitschinger [ 26/Mar/13 ]
Hi Deepti,

I'm not sure what the purpose of this run was, because it still uses the old version (as you even mentioned in your comment):

    'COMPONENTS': { 'SDK': 'Couchbase Java Client 1.1.4\n\nTree Version: 1.1.4\nLast Commit ID: 0958708ab0425a8b91c3e32d7e07d577b50a92b8\n\nCompiled by michael@daschlbook.local on Wed Mar 13 09:31:34 CET 2013',
                      'SPY': 'Spymemcached 2.8.12\n\nTree Version: 2.8.12\nLast Commit ID: 84ebf9ad0d0d8a64497d956f6e75bf74cd7883de\n\nCompiled by michael@daschlbook.local on Fri Mar 1 01:15:26 CET 2013'}}

The version used is the 1.1.4 tag, compiled by me on 13th march. The fix for this is in MASTER (and was added there on march 16th).
Comment by Deepti Dawar [ 26/Mar/13 ]
Alright Michael.

I think we are good with the fix for the scenarios of basic test and the test with failover and readd.
There are no assertion errors for these two cases now.

But in the case of failover and rebalance tests there are still errors existing.

Please find the zip file for all the runs.

I'll tell Saran to get back to customer with the latest build 1.1.4 and verify.

Thanks !
Comment by Michael Nitschinger [ 24/Apr/13 ]
Whats the status on this?
Comment by Deepti Dawar [ 25/Apr/13 ]
As already stated, the failover and the rebalance cause an issue still.

You can have a look at the logs in the attached zip file.
Comment by Deepti Dawar [ 09/May/13 ]
There is a marked improvement in these scenarios. But the tests are failing still. Please have a look at the latest attachments from the cbc version 1.1.6.
Comment by Deepti Dawar [ 10/May/13 ]
Tested with the latest version of the client i.e. 1.16.
All the scenarios are passing. Hence, closing the issue.




[JCBC-263] memcached connection fails with "Attempting to overwrite channel" Created: 11/Mar/13  Updated: 18/Nov/13  Resolved: 18/Nov/13

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

Type: Bug Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: This is a "run of the mill" memcached instance. I have not particularly been able to reproduce it though - nevertheless I am placing it in here so that it may be noted.

Server version is 2.0.0


 Description   
In this case, multiple CouchbaseClient objects are being connected. At the 14th instance, this is printed to the screen and the application hangs.

[SDKD(WARNING) 5.49 cbsdk.sdkd.remote remote.py:266] WARNING: URIs: [http://10.2.1.102:8091/pools?#]
[SDKD(WARNING) 5.51 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM com.couchbase.sdkd.cbclient.Handle makeViewTimeout
[SDKD(WARNING) 5.51 cbsdk.sdkd.remote remote.py:266] WARNING: JCBC-168: Manually setting view timeout to 75000
[SDKD(WARNING) 5.51 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM net.spy.memcached.MemcachedConnection createConnections
[SDKD(WARNING) 5.51 cbsdk.sdkd.remote remote.py:266] INFO: Added {QA sa=/10.2.1.102:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue
[SDKD(WARNING) 5.53 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM net.spy.memcached.MemcachedConnection createConnections
[SDKD(WARNING) 5.53 cbsdk.sdkd.remote remote.py:266] INFO: Added {QA sa=/10.2.1.101:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue
[SDKD(WARNING) 5.53 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM com.couchbase.client.CouchbaseClient <init>
[SDKD(WARNING) 5.53 cbsdk.sdkd.remote remote.py:266] INFO: viewmode property isn't defined. Setting viewmode to production mode
[SDKD(WARNING) 5.53 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM net.spy.memcached.MemcachedConnection handleIO
[SDKD(WARNING) 5.53 cbsdk.sdkd.remote remote.py:266] INFO: Connection state changed for sun.nio.ch.SelectionKeyImpl@6d79953c
[SDKD(WARNING) 5.53 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM net.spy.memcached.MemcachedConnection handleIO
[SDKD(WARNING) 5.53 cbsdk.sdkd.remote remote.py:266] INFO: Connection state changed for sun.nio.ch.SelectionKeyImpl@4934ce4a
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM net.spy.memcached.MemcachedConnection queueReconnect
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] WARNING: Closing, and reopening {QA sa=/10.2.1.101:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=8}, attempt 1.
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM net.spy.memcached.MemcachedConnection handleIO
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] INFO: Reconnecting due to failure to connect to {QA sa=/10.2.1.101:11210, #Rops=0, #Wops=1, #iq=0, topRop=null, topWop=Cmd: 10 Opaque: 55, toWrite=0, interested=0}
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] java.net.ConnectException: Could not send noop upon connect! This may indicate a running, but not responding memcached instance.
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:439)
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:247)
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at com.couchbase.client.CouchbaseMemcachedConnection.run(CouchbaseMemcachedConnection.java:158)
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM net.spy.memcached.MemcachedConnection queueReconnect
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] WARNING: Closing, and reopening {QA sa=/10.2.1.101:11210, #Rops=0, #Wops=1, #iq=0, topRop=null, topWop=Cmd: 10 Opaque: 55, toWrite=0, interested=0}, attempt 1.
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM net.spy.memcached.MemcachedConnection queueReconnect
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] WARNING: Closing, and reopening {QA sa=/10.2.1.101:11210, #Rops=0, #Wops=1, #iq=0, topRop=null, topWop=Cmd: 10 Opaque: 55, toWrite=0, interested=0}, attempt 3.
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM net.spy.memcached.MemcachedConnection queueReconnect
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] INFO: The channel or socket was null for {QA sa=/10.2.1.101:11210, #Rops=0, #Wops=1, #iq=0, topRop=null, topWop=Cmd: 10 Opaque: 55, toWrite=0, interested=0}
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] Exception in thread "SDK Handle-14" java.lang.NullPointerException
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at net.spy.memcached.MemcachedConnection.queueReconnect(MemcachedConnection.java:589)
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at com.couchbase.client.CouchbaseMemcachedConnection.reconfigure(CouchbaseMemcachedConnection.java:132)
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at com.couchbase.client.CouchbaseClient.reconfigure(CouchbaseClient.java:273)
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at com.couchbase.client.vbucket.ReconfigurableObserver.update(ReconfigurableObserver.java:54)
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at java.util.Observable.notifyObservers(Observable.java:159)
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at com.couchbase.client.vbucket.BucketMonitor.setBucket(BucketMonitor.java:258)
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at com.couchbase.client.vbucket.BucketMonitor.startMonitor(BucketMonitor.java:188)
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.subscribe(ConfigurationProviderHTTP.java:288)
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at com.couchbase.client.CouchbaseClient.<init>(CouchbaseClient.java:246)
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at com.couchbase.sdkd.SdkdConfig.getClient(SdkdConfig.java:99)
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at com.couchbase.sdkd.cbclient.Handle.<init>(Handle.java:159)
[SDKD(WARNING) 5.59 cbsdk.sdkd.remote remote.py:266] at com.couchbase.sdkd.server.SdkServer.executeCommand(SdkServer.java:104)
[SDKD(WARNING) 5.59 cbsdk.sdkd.remote remote.py:266] at com.couchbase.sdkd.server.SdkServer.handleRequest(SdkServer.java:189)
[SDKD(WARNING) 5.59 cbsdk.sdkd.remote remote.py:266] at com.couchbase.sdkd.server.SdkServer.run(SdkServer.java:245)
[SDKD(WARNING) 5.59 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM net.spy.memcached.auth.AuthThread$1 receivedStatus
[SDKD(WARNING) 5.59 cbsdk.sdkd.remote remote.py:266] INFO: Authenticated to /10.2.1.102:11210
[SDKD(WARNING) 13.55 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:28 PM net.spy.memcached.MemcachedConnection attemptReconnects
[SDKD(WARNING) 13.55 cbsdk.sdkd.remote remote.py:266] INFO: Reconnecting {QA sa=/10.2.1.101:11210, #Rops=0, #Wops=1, #iq=0, topRop=null, topWop=Cmd: 10 Opaque: 55, toWrite=0, interested=0}
[SDKD(WARNING) 13.55 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:28 PM net.spy.memcached.MemcachedConnection handleIO
[SDKD(WARNING) 13.55 cbsdk.sdkd.remote remote.py:266] INFO: Connection state changed for sun.nio.ch.SelectionKeyImpl@79884a40
[SDKD(WARNING) 13.56 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:28 PM net.spy.memcached.auth.AuthThread$1 receivedStatus
[SDKD(WARNING) 13.56 cbsdk.sdkd.remote remote.py:266] INFO: Authenticated to /10.2.1.101:11210
[SDKD(WARNING) 21.55 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:36 PM net.spy.memcached.MemcachedConnection attemptReconnects
[SDKD(WARNING) 21.55 cbsdk.sdkd.remote remote.py:266] INFO: Reconnecting {QA sa=/10.2.1.101:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0}
[SDKD(WARNING) 21.55 cbsdk.sdkd.remote remote.py:266] Exception in thread "Memcached IO over {MemcachedConnection to /10.2.1.102:11210 /10.2.1.101:11210}" java.lang.AssertionError: Attempting to overwrite channel
[SDKD(WARNING) 21.55 cbsdk.sdkd.remote remote.py:266] at net.spy.memcached.protocol.TCPMemcachedNodeImpl.setChannel(TCPMemcachedNodeImpl.java:496)
[SDKD(WARNING) 21.55 cbsdk.sdkd.remote remote.py:266] at net.spy.memcached.protocol.TCPMemcachedNodeImpl.registerChannel(TCPMemcachedNodeImpl.java:484)
[SDKD(WARNING) 21.55 cbsdk.sdkd.remote remote.py:266] at net.spy.memcached.MemcachedConnection.attemptReconnects(MemcachedConnection.java:680)
[SDKD(WARNING) 21.55 cbsdk.sdkd.remote remote.py:266] at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:262)
[SDKD(WARNING) 21.55 cbsdk.sdkd.remote remote.py:266] at com.couchbase.client.CouchbaseMemcachedConnection.run(CouchbaseMemcachedConnection.java:158)


 Comments   
Comment by Michael Nitschinger [ 19/Jul/13 ]
Hey Mark,

i just stumbled across this ticket. Did you try to connect with a CouchbaseClient against a vanilla memcached instance? That wont work obviously.
Comment by Michael Nitschinger [ 18/Nov/13 ]
Never seen this again, closing for now.




[JCBC-260] Upload the 1.1.3 release notes on Website Created: 07/Mar/13  Updated: 07/Mar/13  Resolved: 07/Mar/13

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

Type: Task Priority: Major
Reporter: Tug Grall (Inactive) Assignee: Unassigned
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Release note are not up to date on www.couchbase.com/develop

 Comments   
Comment by kzeller [ 07/Mar/13 ]
Uploaded just not processed by production server
Comment by kzeller [ 07/Mar/13 ]
Uploaded just not processed by production server




[JCBC-257] NPE encountered in the DefaultConnectionFactory as per CBSE-404 Created: 04/Mar/13  Updated: 11/Mar/13  Resolved: 05/Mar/13

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

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


 Description   
NPE encountered in the DefaultConnectionFactory as per customer explanation in CBSE-404.
This JCBC targets to fix the code related to this problem.

 Comments   
Comment by Michael Nitschinger [ 04/Mar/13 ]
Hi Deepti,

can you update me quickly what's going on there and what the proposed fix from your side is? Thanks.
Comment by Deepti Dawar [ 04/Mar/13 ]
CouchbaseConnectionFactoryBuilder has a method buildCouchbaseConnection which when called before setting the values for DefaultHashAlgorithm and FailureMode, gives a null pointer in the toString method of DefaultConnectionFactory.

There are two ways of fixing this :

1) Null check is added in toString of DefaultConnectionFactory
2) Default values of DefaultHashAlgorithm and FailureMode are provided as constants in CouchbaseConnectionFactoryBuilder.

I am fixing it the first way.

You can have a look at :
http://review.couchbase.org/24968
Comment by Michael Nitschinger [ 05/Mar/13 ]
Has been merged into master.




[JCBC-256] New failures registered after the new change set added Created: 28/Feb/13  Updated: 14/May/13  Resolved: 14/May/13

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

Type: Task 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

Attachments: PNG File errors_latest_run.png     PNG File failures_latest_run.png    

 Description   
The pass rate with the latest change set is only 92%
A lot of array index out of bounds exceptions are there.
Please check.

 Comments   
Comment by Matt Ingenthron [ 28/Feb/13 ]
Can you please include some more detail? This doesn't have which exceptions, which tests, anything on the environment, etc.
Comment by Deepti Dawar [ 28/Feb/13 ]
The snapshot has some details you are looking for. If its not clear please do let me know.
Comment by Michael Nitschinger [ 28/Feb/13 ]
can you please upload the full test results?

Looks to me that spy isnt the correct version (master, not 2.11!). Also, can you give me the hashes of the latest git commits and or the java -jar output you're using?

thanks!
Comment by Michael Nitschinger [ 28/Feb/13 ]
No, sorry about the latest comment.. after cleaning my cache I see the same.
Comment by Michael Nitschinger [ 28/Feb/13 ]
Okay I see what's going on, this -1 issue will be easy to fix. Expect a changeset soon.
Comment by Deepti Dawar [ 14/May/13 ]
As per the latest results, this error has been fixed. The other issues are being addressed. Hence, closing out this issue.

http://sdkbuilds.couchbase.com/job/java-snapshot-build/lastCompletedBuild/testReport/




[JCBC-252] Rebound phase encounter assertion errors with memcached connection Created: 25/Feb/13  Updated: 12/Mar/13  Resolved: 12/Mar/13

Status: Closed
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: None
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

Attachments: Text File assertion_errors_still_reproducible.txt     Text File scenario_passing.log    

 Description   
Failover one node and add it back while the couchbase server is getting started.
The workload that is applied is the GetSetWorkload.
Many assertion errors are appearing in the rebound phase related to state of MemcachedConnection.



 Comments   
Comment by Mark Nunberg [ 25/Feb/13 ]
The log says this is using the 1.1.1 SDK. The current version is 1.1.2
Comment by Deepti Dawar [ 12/Mar/13 ]
Finding with the latest version attached.

The scenario passes fine with this version.

Hence, closing the issue.




[JCBC-249] Observe tests enhancement Created: 18/Feb/13  Updated: 11/Mar/13  Resolved: 05/Mar/13

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

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

Issue Links:
Dependency

 Description   
Few observe tests need to be added as per the latest test plan.

 Comments   
Comment by Deepti Dawar [ 21/Feb/13 ]
http://review.couchbase.org/#/c/24767/
Comment by Deepti Dawar [ 11/Mar/13 ]
Merged into the repository. Hence, closing the issue.




[JCBC-149] Learn how to build/execute Java SDKD against multiple versions of the client library, whether from Maven, source, etc. (carryover) Created: 19/Nov/12  Updated: 24/Jan/13  Resolved: 19/Nov/12

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

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


 Description   
Learn how to build/execute Java SDKD against multiple versions of the client library, whether from Maven, source, etc. (carryover)

 Comments   
Comment by Deepti Dawar [ 19/Nov/12 ]
Finished the task and sent the output jar file for review.




[JCBC-140] Code breaks when Connection URI is improper Created: 07/Nov/12  Updated: 24/Jan/13  Resolved: 15/Jan/13

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

Type: Improvement Priority: Major
Reporter: Deepti Dawar Assignee: Deepti Dawar
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: 1939 - <manifest><remote name="couchbase" fetch="git://github.com/couchbase/"/><remote name="membase" fetch="git://github.com/membase/"/><remote name="apache" fetch="git://github.com/apache/"/><remote name="erlang" fetch="git://github.com/erlang/"/><default remote="couchbase" revision="master"/><project name="tlm" path="tlm" revision="12abea946eafd7411273d18a10ae1f84390db3d4"><copyfile src="Makefile.top" dest="Makefile"/></project><project name="bucket_engine" path="bucket_engine" revision="70b3624abc697b7d18bf3d57f331b7674544e1e7"/><project name="ep-engine" path="ep-engine" revision="68e3f7c57ae40c42dcb94e4d282bbd1648f9adc0"/><project name="libconflate" path="libconflate" revision="2cc8eff8e77d497d9f03a30fafaecb85280535d6"/><project name="libmemcached" path="libmemcached" revision="ca739a890349ac36dc79447e37da7caa9ae819f5" remote="membase"/><project name="libvbucket" path="libvbucket" revision="00d3763593c116e8e5d97aa0b646c42885727398"/><project name="membase-cli" path="membase-cli" revision="7fe4121e7e83952a4cb032e25a2cb9fca1709354" remote="membase"/><project name="memcached" path="memcached" revision="7ea975a93a0231393502af4ca98976eee8a83386" remote="membase"/><project name="moxi" path="moxi" revision="52a5fa887bfff0bf719c4ee5f29634dd8707500e"/><project name="ns_server" path="ns_server" revision="315aa6af297d7139c505e2fa9aa31dd429615a7d"/><project name="portsigar" path="portsigar" revision="1bc865e1622fb93a3fe0d1a4cdf18eb97ed9d600"/><project name="sigar" path="sigar" revision="63a3cd1b316d2d4aa6dd31ce8fc66101b983e0b0"/><project name="couchbase-examples" path="couchbase-examples" revision="544688dc56420faaf6f25946dd4b3ef3f7c15286"/><project name="couchbase-python-client" path="couchbase-python-client" revision="006c1aa8b76f6bce11109af8a309133b57079c4c"/><project name="couchdb" path="couchdb" revision="b68b5f40e0911db7de651b457e6a79a5937ff810"/><project name="couchdbx-app" path="couchdbx-app" revision="1130fa3c1f117527b761497cfa0c15a1e9968808"/><project name="couchstore" path="couchstore" revision="b5937c4479bf05dcc67264efe19abaf52870a127"/><project name="geocouch" path="geocouch" revision="849d5443689b1924f097548af864c539bffcc929"/><project name="mccouch" path="mccouch" revision="88701cc326bc3dde4ed072bb8441be83adcfb2a5"/><project name="testrunner" path="testrunner" revision="c4e82c929b3c7f2328f234fc9d79b38868268455"/><project name="otp" path="otp" revision="b6dc1a844eab061d0a7153d46e7e68296f15a504" remote="erlang"/><project name="icu4c" path="icu4c" revision="26359393672c378f41f2103a8699c4357c894be7" remote="couchbase"/><project name="snappy" path="snappy" revision="5681dde156e9d07adbeeab79666c9a9d7a10ec95" remote="couchbase"/><project name="v8" path="v8" revision="447decb75060a106131ab4de934bcc374648e7f2" remote="couchbase"/><project name="gperftools" path="gperftools" revision="8f60ba949fb8576c530ef4be148bff97106ddc59" remote="couchbase"/><project name="pysqlite" path="pysqlite" revision="0ff6e32ea05037fddef1eb41a648f2a2141009ea" remote="couchbase"/></manifest>

Attachments: Java Source File ConfigurationParserJSON.java     File couchbase_SDK_connect_exception.odt    

 Description   
The code breaks abruptly when connection URI is not given in a proper format in the SDK client for connecting the to required Couchbase server.
For instance, when I am specifying the URI as "http:/10.3.2.57:8091/index.html" instead of "http:/10.3.2.57:8091/pools", exception appears,
whereas a proper error message should be returned saying that 'Connection could not be established to the requested server location'.
Please find attached the log file for the exception trace.

 Comments   
Comment by Michael Nitschinger [ 08/Nov/12 ]
Deepti,

I think the logs already provide a helpful error message with the stack trace that shows what it tried to parse.

In the case you provided, the logs would say 2012-11-08 10:29:09.254 WARN com.couchbase.client.vbucket.ConfigurationProviderHTTP: Provided URI http://192.168.1.105:8091/index.html has an unparsable response...skipping

and then print a stack trace of what was tried to parse (in this case hughe chunks of HTML).

Also, if you pass in more URIs it would try to get the next one to establish a successful connection.

I think we could catch it and add a different error message, but then it wont be clear to the user what happened.

If you think we really should change something here, please reopen the issue and then we can discuss it together at a broader audience!

Thanks,
Michael
Comment by Deepti Dawar [ 08/Nov/12 ]
Dear Michael,

As discussed with you, I think the exception here should be caught in a very generic manner that gives the user some information like this - "Connection could not be established - Either the URI provided is incorrect or the host is unavailable". As the user is not concerned about what is happening beyond the scene and not in the least about what is getting parsed in order for the connection to be established. He is just concerned about the system URL he wants to connect to and the network. Either of these two if unavailable with cause an issue in connection, only that needs to be highlighted back to the user in form of a warning message. It should not abruptly break the code. Hence, I am reopening this defect for further investigation.

Regards,
Deepti
Comment by Deepti Dawar [ 26/Dec/12 ]
File changed.
Please approve for check in.
Comment by Deepti Dawar [ 02/Jan/13 ]
Hi Michael,

Please review at

http://review.couchbase.org/#/c/23648/2

Regards,
Deepti
Comment by Mark Nunberg [ 02/Jan/13 ]
I think this should be converted to some kind of connection or execution exception, providing more detailed information.
Comment by Deepti Dawar [ 08/Jan/13 ]
Mark, can we have any exceptions like DisplayableException which could be shown to the end user ?

Can you please give details about the connection or execution exceptions.
Comment by Mark Nunberg [ 08/Jan/13 ]
What is displayed to the user is a sub-component of logging and not of the exception itself. An exception is not an exception unless it represents an exceptional condition; it is up to the code catching the exception to convert this to something the user can understand.

I am not sure if the Couchbase Java client has classes for "connection" exceptions which indicate a difficulty in communication between client and server, but if there isn't such a class then it should be created.

Theroetically

class CouchbaseConnectionException extends Exception {
    ....
}

Typically it seems most of the Couchbase exceptions in the Java client are RuntimeExceptions or ExecutionExceptions (i.e. generic "unchecked" exceptions).

Matt and Michale might have more knowledge of the various classes contained therein and their suitability of use.
Comment by Deepti Dawar [ 09/Jan/13 ]
I agree. There should be in-house exception classes meant to facilitate this purpose.
A user working with couchbase sdk, should have the feasibility of using those exception classes for understanding various scenarios and then acting accordingly.

Please let us know if there are any exception classes for communicating the connection exception to the user in which we can embed a custom message stating what happened.
Comment by Deepti Dawar [ 15/Jan/13 ]
Please review at

http://review.couchbase.org/#/c/23648/
Comment by Deepti Dawar [ 15/Jan/13 ]
Changes checked in for review in gerrit.




[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-132] Exception: 'Failed to access the view' when rebalancing Created: 16/Oct/12  Updated: 24/Oct/12  Resolved: 24/Oct/12

Status: Closed
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1-dp3
Fix Version/s: 1.1-dp4
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: 2.0 Beta, 1.1 DP3

Issue Links:
Dependency

 Description   
View fails when rebalancing from 3 to 1 node and back up.

During the whole process, access a view.
3 server in one cluster.

- Manual failover one node, and then rebalance. It is fine.
- Then manual failover another one, and then rebalance, and at this time in the system there is only one node,
- Add 2 nodes back into the cluster and rebalance.

- Sometimes it will throw the "Failed to access the view" exception, and sometimes the CouchbaseClient.getView() call will return NULL.

This issue is also seen when adding nodes to a cluster.

 Comments   
Comment by Matt Ingenthron [ 16/Oct/12 ]
Passing to Michael to reproduce and investigate.
Comment by Michael Nitschinger [ 24/Oct/12 ]
The changeset http://review.couchbase.com/#/c/21338/ now doesn't return null when the view is found but instead raises an appropriate exception.




[JCBC-129] Improve Documentation on persistTo, replicateTo Created: 08/Oct/12  Updated: 11/Oct/12  Resolved: 09/Oct/12

Status: Closed
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.1-dp3
Fix Version/s: 1.1-dp4
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


 Description   
Add better documentation (both in the developers guide and in the API docs) how the replication params work - especially for the case where persistTo is ZERO and replicateTo is ONE.

 Comments   
Comment by Michael Nitschinger [ 08/Oct/12 ]
See this changeset: http://review.couchbase.org/#/c/21417/
Comment by Michael Nitschinger [ 11/Oct/12 ]
Fixed in master and will be available in dp4




[JCBC-128] Add commands with only ReplicateTo Created: 08/Oct/12  Updated: 11/Oct/12  Resolved: 11/Oct/12

Status: Closed
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1-dp3
Fix Version/s: 1.1-dp4
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


 Description   
Commands like set should allow also the possibility of only define ReplicateTo, without PersistTo.

 Comments   
Comment by Michael Nitschinger [ 08/Oct/12 ]
Note that currently PersistTo.ZERO is not supported, so this needs to be added as well (only MASTER, ONE, TWO, THREE and FOUR are supported).
Comment by Michael Nitschinger [ 08/Oct/12 ]
See these two changesets:

http://review.couchbase.com/#/c/21416/
http://review.couchbase.com/#/c/21415/
Comment by Michael Nitschinger [ 11/Oct/12 ]
Fixed in master and will be available in dp4




[JCBC-126] SDK doesn't encode spaces properly on View query Created: 05/Oct/12  Updated: 11/Oct/12  Resolved: 11/Oct/12

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

Type: Bug 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


 Description   
From the forums:

Using 2.0b and the Java API 1.1 preview, there appears to be a bug when doing a query with a key that has internal whitespace:
INFO CouchbaseClient - lookin for:/default/_design/accounts/_view/acc_by_username?limit=1000&skip=0&key="aaron davidson"
ERROR java.lang.RuntimeException: Failed to access the view
at com.couchbase.client.CouchbaseClient.query(CouchbaseClient.java:591)
...
If I manually replace the query string "aaron davidson" with "aaron%20davidson" the query works and no exception is thrown. The API should probably handle this case when constructing the RESTful URL.

 Comments   
Comment by Michael Nitschinger [ 11/Oct/12 ]
http://review.couchbase.org/#/c/21423/
Comment by Michael Nitschinger [ 11/Oct/12 ]
Fixed in master and will be available in dp4




[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-112] Updated getting started to match beer sample DB Created: 12/Sep/12  Updated: 18/Sep/12  Resolved: 18/Sep/12

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

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


 Description   
The getting started both in the docs repo and on the web page should be updated to match the beer sample DB.




[JCBC-193] Allow CAS with delete Created: 24/Aug/11  Updated: 19/Dec/12  Resolved: 19/Dec/12

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

Type: Improvement Priority: Major
Reporter: Perry Krug Assignee: Matt Ingenthron
Resolution: Duplicate Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SPY-128 Support CAS for delete operation Resolved

 Description   
Customer request to allow CAS with delete option to ensure that an item has not changed since the last time it was read

 Comments   
Comment by Mike Wiederhold [ 24/Aug/11 ]
Do you mean you want a single operation that does deletes and operation only if it hasn't changed. In other words you want CAD (check and delete)?
Comment by Marcus Longmuir [ 25/Aug/11 ]
The discussion which brought about this issue is found here:
http://www.couchbase.org/forums/thread/set-or-return-current-value

CAD is exactly what I meant and would probably be the most appropriate function name.
Comment by Mike Wiederhold [ 22/Sep/11 ]
I think that to implement this correctly we would need to refactor a bunch of code. The reason is that you can actually use cas values with every command and as a result it wouldn't make sense to create duplicate functions for every command (delete included). I am going to move it to the 3.0 release as a result.
Comment by Michael Nitschinger [ 19/Dec/12 ]
Does it make sense to implement cas delete?




[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-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-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-73] incorporate docs on logging from the wiki into formal docs Created: 09/Jul/12  Updated: 30/Jul/12  Resolved: 30/Jul/12

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

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


 Description   
What's currently on the wiki should be re-incorporated into formal docs. See:

http://www.couchbase.com/docs/couchbase-sdk-java-1.0/configuring-logging.html
http://www.couchbase.com/wiki/display/couchbase/Couchbase+Java+Client+Library


 Comments   
Comment by Matt Ingenthron [ 09/Jul/12 ]
MC, please assign accordingly, even if that's back to myself to get someone else to do it.
Comment by MC Brown (Inactive) [ 09/Jul/12 ]
Is this something that can be added verbatim into the docs, or that requires some expansion? If a simple C&P it'll only take me a few seconds to import and publish.
Comment by Matt Ingenthron [ 30/Jul/12 ]
This has been fixed by Karen.




[JCBC-53] incorrect connection type being served by ConnectionFactory Created: 21/May/12  Updated: 30/Jul/12  Resolved: 30/Jul/12

Status: Closed
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 1.0, 1.0.1, 1.0.2
Fix Version/s: 1.0.3
Security Level: Public

Type: Bug Priority: Major
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   
It's been found that the incorrect connection type is being served up for memcached bucket types. The CouchbaseConnection is being created by the ConnectionFactory not the MemcachedConnection.

As a result, when the cluster is in a condition where the node responsible for a given operation is down, the alternate node would be correctly requested but upon the node map being rebuilt, no operations are sent back to that node and the connection is therefore never reestablished.

Example Steps:
1. Start the loadgen which will store keys in the cluster in "default" memcached bucket. The loadgen iterates through the keys to verify it is able to retrieve them.

2. After a min, in UI console, "failover" one node and then rebalance

3. After a min, in UI console, add the node back to the cluster using "Add server" and click on rebalance again.

4. Verify the keys are getting stored on all nodes in cluster

It's at step 4 things currently fail.

 Comments   
Comment by Matt Ingenthron [ 30/Jul/12 ]
http://review.couchbase.org/16337




[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-32] Issue with range query Created: 11/Apr/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-dp4
Security Level: Public

Type: Bug 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


 Description   
I am running couchbase server version 2.0.0 community edition (build-722) and the latest java couchbase client, couchbase-client-1.1-dp.jar

I realize all this is developer preview however, this seems pretty basic stuff for dp4. Can you help?

I have some simple test documents that look as follows

{
        "account_id": "-2",
        "value": "2.00000000",
        "created_at": "2012-04-06 03:55:22",
}

and a simple view called counts in the transactions document defined as follows

function (doc) {
  emit([doc.account_id, doc.created_at], parseFloat(doc.value));
}

with a _stats reduce function

I can correctly run queries using complex keys using the couchbase design view in the management interface, or issue requests from my browser / curl as follows

http://127.0.0.1:8092/default/_design/dev_transactions/_view/counts?group_level=2&startkey=["-1","2012-04-06 01:28:30"]&endkey=["-1","2012-04-07 01:49:26"]&group=true&reduce=true&stale=false

and get the correct response

{"rows":[
{"key":["-1","2012-04-06 03:55:21"],"value":{"sum":2,"count":1,"min":2,"max":2,"sumsqr":4}},
{"key":["-1","2012-04-06 03:55:22"],"value":{"sum":3,"count":1,"min":3,"max":3,"sumsqr":9}},
{"key":["-1","2012-04-06 03:55:33"],"value":{"sum":5,"count":2,"min":2,"max":3,"sumsqr":13}}
]
}
However when I try to do a range query from java I get a null result. If I leave off the range keys, everything works as would be expected.

A null result looks to me as if the server did not respond. But, using the debugger I can tell that the url is correctly created. Any thoughts?

            CouchbaseClient couchbase = new CouchbaseClient(couchbaseURIs, "default", "");
            Query query = new Query();
        query.setRange("[\"-1\",\"2012-04-06 01:28:30\"]", "[\"-1\",\"2012-04-06 01:49:26\"]");
        query.setGroup(true, 2);
        query.setStale(Stale.FALSE);
        query.setReduce(true);
        query.setIncludeDocs(false);

        View view = couchbase.getView("transactions", "counts");
        if (view != null) {
                       ViewResponse result = couchbase.query(view, query);
                   ViewRow row;

                    Iterator<ViewRow> itr = result.iterator();

                    while(itr.hasNext()) {
                            row = itr.next();
                            System.out.println("Key: " + row.getKey()+ " : " + row.getValue());
                    }
            }
               }


 Comments   
Comment by Tim Smith (Inactive) [ 17/Aug/12 ]
See related JCBC-41 and JCBC-48

Comment by Matt Ingenthron [ 05/Oct/12 ]
Please verify this use case is handled with the new changes and addition of ComplexKey.
Comment by Michael Nitschinger [ 08/Oct/12 ]
I guess this should be fixed with the recent additions, here is an example on how to do it:

        ComplexKey rangeStart = ComplexKey.of("-1", "2012-04-06 01:28:30");
        ComplexKey rangeEnd = ComplexKey.of("-1", "2012-04-07 01:49:26");
        Query query = new Query()
                .setRange(rangeStart, rangeEnd)
                .setGroup(true)
                .setGroupLevel(2)
                .setStale(Stale.FALSE)
                .setReduce(true)
                .setIncludeDocs(false);

You can call the toString() method on the query and this prints the following query string: ?group_level=2&startkey=["-1","2012-04-06 01:28:30"]&endkey=["-1","2012-04-07 01:49:26"]&group=true&reduce=true&stale=false

Which should be pretty much what we need in this case.

Comment by Mike Wiederhold [ 08/Oct/12 ]
Michael,

If this issue is resolved then please close this bug as fixed and include the bug id for the Complex Key fix in the comments.
Comment by Michael Nitschinger [ 09/Oct/12 ]
I'll close this one now - pleasw reopen it if the problem still exists.

@Mike: we didn't have a jcbc ticket for the complexkey changes, but here is the github commit as a reference:
https://github.com/couchbase/couchbase-java-client/commit/2178868be2bd3212d19e02943da26c72762509d3
Comment by Michael Nitschinger [ 09/Oct/12 ]
Fixed/Implemented with the ComplexKey changes.




[JCBC-26] 160% cpu load when connecting to dp4 through java client. Created: 23/Mar/12  Updated: 03/Jun/12  Resolved: 03/Jun/12

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

Type: Bug Priority: Major
Reporter: Alex Ma Assignee: Raghavan Srinivas (Inactive)
Resolution: Duplicate Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: client and server are running on the same machine

On mac os 10.7.3,
java version "1.6.0_29"
Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-11D50b)
Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode)
DP java client: http://www.couchbase.com/develop/java/next


   <repository>
<id>couchbase</id>
<name>couchbase repo</name>
<url>http://files.couchbase.com/maven2&lt;/url>
<layout>default</layout>
</repository>

<dependency>
<groupId>spy</groupId>
<artifactId>spymemcached</artifactId>
<version>2.8.1</version>
</dependency>
<dependency>
<groupId>couchbase</groupId>
<artifactId>couchbase-client</artifactId>
<version>1.1-dp</version>
</dependency>
<dependency>
<groupId>org.jboss.netty</groupId>
<artifactId>netty</artifactId>
<version>3.2.0.Final</version>
</dependency>
<dependency>
<groupId>org.codehaus.jettison</groupId>
<artifactId>jettison</artifactId>
<version>1.1</version>
</dependency>
<dependency>
<groupId>commons-codec</groupId>
<artifactId>commons-codec</artifactId>
<version>1.5</version>
</dependency>

Attachments: Java Source File ViewConnection.java     Text File ViewNode-HighCPU.patch    

 Description   
presales customer is connecting 1.1dp java client to dp4 and seeing 160% cpu load.

With the older client jars against dp3 they were seeing 100-120% cpu load.

This cpu load is right after application start with no load at all, after connecting to couchbase.


from customer:
"This issue specifically in DP3: http://www.couchbase.com/forums/thread/high-cpu-load-even-when-java-database-client-idle We've been seeing this both on mac and ubuntu."


 Comments   
Comment by Alex Ma [ 26/Mar/12 ]
Hi Rags,

Just wondering if there was any update on this ticket?

thanks

-Alex
Comment by Velasticus [ 07/Apr/12 ]
I can confirm this happens in my java app as well. The problem is in the ViewConnection/ViewNode thread that sits in a tight loop when there is nothing to process. This patch adds a timeout to the poll method which reduces CPU down to almost zero.
Comment by Alan Wood [ 04/May/12 ]
Added a new version of "View Connection" to combat the 100% cpu issue.

This version of "View Connection" will block when nothing is happening. It also doesn't block shutdown. Seems to work both when the view connection is "idle" and when it is returning view work. The previous patch had issues with shutdown and possibly with nodes not having work blocking other nodes.
Comment by Mike Wiederhold [ 03/Jun/12 ]
Duplicate of JCBC-20. I have a change in review that fixes this issue. I will get it through review next week.




[JCBC-19] client can fail to reconnect to the cluster if the place it's currently connected fails Created: 16/Mar/12  Updated: 05/Apr/12  Resolved: 05/Apr/12

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

Type: Bug Priority: Major
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   
Couchbase client 1.0.1, verified with autofailover.




[JCBC-3] running integration tests under CI Created: 12/Jan/12  Updated: 11/Mar/13  Resolved: 11/Feb/13

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

Type: Task Priority: Major
Reporter: Matt Ingenthron Assignee: Deepti Dawar
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File test_errors.png     PNG File test_failures.png     PNG File test_results.png    
Issue Links:
Duplicate
is duplicated by JCBC-2 running unit tests under CI Resolved

 Comments   
Comment by Michael Nitschinger [ 31/Jan/13 ]
Since we mix unit and integration tests in the test suite, I consider this one ticket (therefore duplicating JCBC-2).
Comment by Michael Nitschinger [ 31/Jan/13 ]
Assigning to Deepti because she's been working on this currently.
Comment by Deepti Dawar [ 11/Feb/13 ]
http://review.couchbase.org/#/c/24299/




[JCBC-41] incorrect conversion from string to number in json attribute Created: 03/May/12  Updated: 19/Nov/12  Resolved: 09/Oct/12

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

Type: New Feature Priority: Major
Reporter: Alex Ma Assignee: Michael Nitschinger
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Java 1.1 client
CB dp4


 Description   
zendesk ticket from customer below - is there existing functionality for this and it is simply not documented?


The method Query.setKey( String ) converts strings consisting of digits into numbers instead of keeping the format a string. This can be seen by inspecting the Query object after running setKey( "300" ) (or any other all digit string). The internal association is ?key=300. For example, setKey( "Hey" ) yields ?key="Hey".

The issue here is that we have data stored in JSON documents where the data portion is treated as a string, but it is all digits. So, a query for setKey( "300" ) fails to match fields that contain "300", because the query is ultimately if ( 300 == "300" ).

There should be two versions of setKey(), one for strings and one for number types.

I was unable to find any documentation regarding this particular case, so I assumed it is not an expected issue.







The problem is inside of the Query class. In getArg(), the check for isJsonObject() returns true for stringified numbers, and the resulting key/value does not contain quotes. The result now is

?key=300

We want the output of the query object to be

?key="300"

-or-

?key=300

based on the input type (String or number). As of now, it makes that determination for us, which is incorrect.

which is impossible given the current implementation.

 Comments   
Comment by Tim Smith (Inactive) [ 17/Aug/12 ]
See duplicate JCBC-90 for other examples.

See JCBC-48 for related issues regarding JSON object handling.
Comment by Raghavan Srinivas (Inactive) [ 13/Sep/12 ]
This seems to work well for float.

For example,

query.setKey("6.6");

will find the keys with the string as 6.6.

However a

query.setKey("0")

will not find the keys with String "0".
Comment by Michael Nitschinger [ 04/Oct/12 ]
This issue is addressed here: http://review.couchbase.com/#/c/21337/
Comment by Michael Nitschinger [ 11/Oct/12 ]
Fixed in master and will be available in dp4.
Comment by Chris Tashjian [ 19/Nov/12 ]
This does not work for longs...

        Query q1 = new Query();
        long time1 = 0;
        long time2 = 99999999;
        long time3 = 99999999999l;

        q1.setRangeStart(ComplexKey.of(time1));
        q1.setRangeEnd(ComplexKey.of(time2));
        q1.toString() --> ?startkey=0&endkey=99999999

        q1.setRangeStart(ComplexKey.of(time1));
        q1.setRangeEnd(ComplexKey.of(time3));
        q1.toString()) --> ?startkey=0&endkey=%2299999999999%22

It's throwing quotes around the long value.
Comment by Steven Cooke [ 19/Nov/12 ]
see JCBC-48: net.spy.memcached.util.StringUtils does not implement isJsonObject to spec (http://www.json.org/) which breaks queries.

ComplexKey.toJson outputs the values as a string which just you back to the problem in the original post. ComplexKey essentially does nothing with respect to the original problem.

imagine this next sentence in all caps -->> StringUtils.isJson is broken and should not be used

The original poster's solution of adding an explicit method to handle numeric keys as numbers will work.




[JCBC-38] CouchbaseConnectionFactoryBuilder should have a ctor without a username, using bucketname as username Created: 29/Apr/12  Updated: 29/Jul/12  Resolved: 04/Jun/12

Status: Closed
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.0, 1.0.1, 1.0.2
Fix Version/s: 1.0.3
Security Level: Public

Type: Bug Priority: Major
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   
Since we don't yet have separation of username and password, there should be a ctor that treats bucketname as username.

 Comments   
Comment by Matt Ingenthron [ 03/Jun/12 ]
Have already fixed this.
Comment by Mike Wiederhold [ 03/Jun/12 ]
I didn't see a commit in gerrit or on github. It's an easy fix so it's not a big deal, but I have a commit on gerrit here:

http://review.couchbase.org/#change,16702

If you have one in your local branch we can use that one too. If something has already been committed then please point me to the commit so we can close this bug and abandon my change.
Comment by Matt Ingenthron [ 29/Jul/12 ]
http://review.couchbase.org/15435




[JCBC-29] Incorrect Hash is being used for Memcached buckets which causes uneven key distribution and not being able to interoperate with Moxi Created: 04/Apr/12  Updated: 23/May/12  Resolved: 05/Apr/12

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

Type: Bug Priority: Major
Reporter: Raghavan Srinivas (Inactive) Assignee: Raghavan Srinivas (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: A 2-node (or higher) cluster with Memcached buckets


 Description   
When a 2-node (or higher) cluster is setup with Memcached buckets, the key distribution is uneven since the Ketama Hash is not being used as a result of incorrect refactoring when the "smart" couchbase-client was created. These cause interoperation issues with moxi (and other client libraries) as well.

 Comments   
Comment by Matt Ingenthron [ 23/May/12 ]
Fixed in 1.0.2




[JCBC-14] Add a README to the project Created: 07/Feb/12  Updated: 30/Jul/12  Resolved: 30/Jul/12

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

Type: Improvement Priority: Major
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   
It should be modeled after the spymemcached project.

 Comments   
Comment by Matt Ingenthron [ 30/Jul/12 ]
I did this one for Rags.




[JCBC-631] Edit updated document basics topic Created: 18/Nov/14  Updated: 19/Nov/14  Resolved: 19/Nov/14

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

Type: Task Priority: Major
Reporter: Amy Kurtzman Assignee: Amy Kurtzman
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates to
relates to JCBC-535 Add documentation on different docume... Resolved

 Description   
https://github.com/couchbase/docs/pull/28




[JCBC-650] 1.4.6 SDK shows errors on check and set Created: 09/Dec/14  Updated: 17/Dec/14  Resolved: 17/Dec/14

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

Type: Bug Priority: Major
Reporter: Wei-Li Liu Assignee: Michael Nitschinger
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Wei-Li Liu [ 15/Dec/14 ]
The test result was against 3.0.2 server
Comment by Wei-Li Liu [ 17/Dec/14 ]
I am closing the ticket as the failures is caused by applications not sdk.




[JCBC-363] Add intro to Java SDK guides Created: 24/Sep/13  Updated: 15/Oct/13  Resolved: 01/Oct/13

Status: Closed
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.0, 1.1.0, 1.2
Fix Version/s: 1.0, 1.1.0, 1.2
Security Level: Public

Type: Task Priority: Minor
Reporter: Amy Kurtzman Assignee: Gwen Leong (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The SDK guides currently begin with the Getting Started section. They need an introduction and meaningful web page title so customers know what guide they are reading.

For each version of the SDK guide, please:

1. Add a short introduction (# Introduction) before the Getting Started section. Sample intro:
    This guide provides information for developers who want to use the Couchbase <language> SDK to
    build applications that use Couchbase Server.

2. In the corresponding index.erb file, change the title to one that follows this naming pattern:
    Couchbase <language> SDK <version> Guide


 Comments   
Comment by Gwen Leong (Inactive) [ 01/Oct/13 ]
Added to all versions.
http://docs.couchbase.com/couchbase-sdk-java-1.2/




[JCBC-244] Sample Application : fix the welcome file and gitignore Created: 12/Feb/13  Updated: 27/May/13  Resolved: 27/May/13

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

Type: Task Priority: Minor
Reporter: Tug Grall (Inactive) Assignee: Tug Grall (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
1- the Welcome auto redirect in Jetty does not work correctly.
2- Update the gitignore to handle IDE and OS

 Comments   
Comment by Michael Nitschinger [ 26/Mar/13 ]
Hey tug, is this still ongoing?
Comment by Michael Nitschinger [ 15/Apr/13 ]
Tug, did you fix this recently?
Comment by Michael Nitschinger [ 27/May/13 ]
thanks tug!




[JCBC-182] Identify the CouchbaseCache and CouchbaseCacheManager classes in the Java Couchbase client.jar Created: 13/Dec/12  Updated: 13/Dec/12  Resolved: 13/Dec/12

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

Type: Task Priority: Minor
Reporter: Muthu Kumar Assignee: Muthu Kumar
Resolution: Won't Fix Votes: 0
Labels: Couchbase, Spring
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Hi - As a part of this ticket http://support.couchbase.com/tickets/2294 and also in general, we would like to understand how Couchbase Java Client works with Spring

a) Where are we w.r.t Spring and Couchbase ?
b) Caching with spring
c) Full integration for spring data


Please help us with pointers as we could see http://techstickynotes.blogspot.in/2012/04/spring-cache-couchbase-nosql-db.html not being part of any of our documentation, however we could see the two classes being used in one our docs http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-cache-apis.html



 Comments   
Comment by Hari Subramaniam (Inactive) [ 13/Dec/12 ]
to be re-submitted as an internal Couchbase Engineering ticket




[JCBC-82] Updated screencast for /develop pages Created: 12/Jul/12  Updated: 13/Nov/12  Resolved: 13/Nov/12

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

Type: Improvement Priority: Minor
Reporter: Matt Ingenthron Assignee: MC Brown (Inactive)
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Create an updated screencast to ship with the new 2.0 developer SDKs

 Comments   
Comment by Michael Nitschinger [ 13/Nov/12 ]
Do I remember it correctly that we settled on not doing getting started screencasts?

If so, please mark as invalid!
Comment by MC Brown (Inactive) [ 13/Nov/12 ]
Current plans are not to update the screencasts.




[JCBC-12] buildCouchbaseConnection (URIlist, bucket, user, password) user seems superflous Created: 04/Feb/12  Updated: 03/Jun/12  Resolved: 03/Jun/12

Status: Closed
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.0.1
Fix Version/s: 1.0.3
Security Level: Public

Type: Bug Priority: Minor
Reporter: Raghavan Srinivas (Inactive) Assignee: Raghavan Srinivas (Inactive)
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The user is not being used but required to call some of the couchbase-client methods

 Comments   
Comment by Mike Wiederhold [ 03/Jun/12 ]
JCBC-38 adds a constructor that doesn't require this parameter. In the future we may use this field so it doesn't make sense to remove this constructor at this time.




[JCBC-651] Improve Json support by adding add/put methods that take collections Created: 10/Dec/14  Updated: 11/Dec/14  Resolved: 11/Dec/14

Status: Closed
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 2.0.2
Fix Version/s: 2.0.3, 2.1.0
Security Level: Public

Type: Improvement Priority: Minor
Reporter: Simon Baslé Assignee: Simon Baslé
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates to
relates to JCBC-655 Backport fixes done in the meantime f... Open

 Description   
As we've made improvements for Json support by offering factory methods for JsonObject and JsonArray taking Maps and Lists respectively, we can further improve this side of things by directly offering put() and get() methods taking the same kind of parameters (and storing the value as sub-JsonObject or sub-JsonArray).

 Comments   
Comment by Simon Baslé [ 11/Dec/14 ]
done on master (2.1), see commit https://github.com/couchbase/couchbase-java-client/commit/8b29f69c8e7a8e968ffc2fa566d257e3f253d510




[JCBC-481] Integration Tests hang up after 85% progress Created: 25/Jun/14  Updated: 15/Sep/14  Resolved: 15/Sep/14

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

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

Issue Links:
Dependency

 Description   
[root@pomelo-11017 couchbase-java-client]# ./gradlew integrationTest
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:compileIntegrationJava UP-TO-DATE
:processIntegrationResources UP-TO-DATE
:integrationClasses UP-TO-DATE
> Building 85% > :integrationTest

 Comments   
Comment by Wei-Li Liu [ 18/Aug/14 ]
The process hangs at 85% due to view query test.
Just runs 2.0.0-dp3 integration test against the new beta2 build, and all the tests completes.
Comment by Deepti Dawar [ 21/Aug/14 ]
Following error appears with latest DP3 -

[root@pomelo-11017 couchbase-java-client]# ./gradlew integrationTest
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:compileIntegrationJava
warning: [options] bootstrap class path not set in conjunction with -source 1.6
1 warning
:processIntegrationResources
:integrationClasses
:integrationTest

com.couchbase.client.java.BinaryTest > classMethod FAILED
    com.couchbase.client.core.config.ConfigurationException
        Caused by: java.lang.IllegalStateException
            Caused by: rx.exceptions.OnErrorThrowable$OnNextValue

com.couchbase.client.java.BinaryTest > classMethod FAILED
    java.util.NoSuchElementException

com.couchbase.client.java.DesignDocumentTest > classMethod FAILED
    com.couchbase.client.core.config.ConfigurationException
        Caused by: java.lang.IllegalStateException
            Caused by: rx.exceptions.OnErrorThrowable$OnNextValue

com.couchbase.client.java.DesignDocumentTest > classMethod FAILED
    java.util.NoSuchElementException

4 tests completed, 4 failed
:integrationTest FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':integrationTest'.
> There were failing tests. See the report at: file:///root/couchbase/couchbase-java-client/build/reports/tests/index.html

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 22.09 secs
Comment by Michael Nitschinger [ 21/Aug/14 ]
Does it also happen on master?
Comment by Wei-Li Liu [ 21/Aug/14 ]
I test it on master and only see JCBC-479




[JCBC-479] ComparisonFailure in running unit tests for 2.0 client Created: 24/Jun/14  Updated: 21/Aug/14  Resolved: 21/Aug/14

Status: Resolved
Project: Couchbase Java Client
Component/s: Infrastructure
Affects Version/s: 2.0.0
Fix Version/s: 2.0-beta
Security Level: Public

Type: Bug Priority: Test Blocker
Reporter: Deepti Dawar 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   
1 warning
:processTestResources UP-TO-DATE
:testClasses
:test

com.couchbase.client.java.document.json.JsonObjectTest > shouldExportMix FAILED
    org.junit.ComparisonFailure at JsonObjectTest.java:27

com.couchbase.client.java.query.ViewQueryTest > shouldHandleEndKey FAILED
    org.junit.ComparisonFailure at ViewQueryTest.java:178

77 tests completed, 2 failed
:test FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':test'.
> There were failing tests. See the report at: file:///root/couchbase/sdkd-2.0/couchbase-java-client/build/reports/tests/index.html

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED


 Comments   
Comment by Wei-Li Liu [ 15/Jul/14 ]
I am getting different failure running unit test

===================================================================================
1 warning
:processTestResources UP-TO-DATE
:testClasses
:test

com.couchbase.client.java.convert.JacksonJsonConverterTest > shouldEncodeSimpleJsonObject FAILED
    org.junit.ComparisonFailure at JacksonJsonConverterTest.java:70

com.couchbase.client.java.convert.JacksonJsonConverterTest > shouldEncodeMixedNestedJsonValues FAILED
    org.junit.ComparisonFailure at JacksonJsonConverterTest.java:177

77 tests completed, 2 failed
:test FAILED

FAILURE: Build failed with an exception.
Comment by Wei-Li Liu [ 15/Jul/14 ]
Failure running integration tests


============================================================================
wei-lis-mbp:couchbase-java-client wei-li$ ./gradlew integrationTest
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:compileIntegrationJava UP-TO-DATE
:processIntegrationResources UP-TO-DATE
:integrationClasses UP-TO-DATE
:integrationTest

com.couchbase.client.java.BinaryTest > classMethod FAILED
    com.couchbase.client.core.config.ConfigurationException
        Caused by: java.lang.IllegalStateException
            Caused by: rx.exceptions.OnErrorThrowable$OnNextValue

com.couchbase.client.java.BinaryTest > classMethod FAILED
    java.util.NoSuchElementException

com.couchbase.client.java.QueryTest > classMethod FAILED
    com.couchbase.client.core.config.ConfigurationException
        Caused by: java.lang.IllegalStateException
            Caused by: rx.exceptions.OnErrorThrowable$OnNextValue

com.couchbase.client.java.QueryTest > classMethod FAILED
    java.util.NoSuchElementException

com.couchbase.client.java.ViewTest > classMethod FAILED
    com.couchbase.client.core.config.ConfigurationException
        Caused by: java.lang.IllegalStateException
            Caused by: rx.exceptions.OnErrorThrowable$OnNextValue

com.couchbase.client.java.ViewTest > classMethod FAILED
    java.util.NoSuchElementException

6 tests completed, 6 failed
:integrationTest FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':integrationTest'.
> There were failing tests. See the report at: file:///Users/wei-li/repo/couchbase/sdkd-2.0/couchbase-java-client/build/reports/tests/index.html

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED
Comment by Wei-Li Liu [ 15/Jul/14 ]
Disregard the above integration test failure. It requires to create "default" bucket and set no password to run.
Comment by Wei-Li Liu [ 18/Aug/14 ]
Running 2.0-dp3 feature test against 1118 server, and all of the unit test and integration tests passed. I am resolving this ticket.
Comment by Deepti Dawar [ 19/Aug/14 ]
Hi Michael, Please close this when you push the fix for it.

Thanks !
Comment by Michael Nitschinger [ 19/Aug/14 ]
Should be fixed in master, please reopen if not.
Comment by Wei-Li Liu [ 20/Aug/14 ]
I run int test on master today and there is 1 failure on shouldUpsertLegacyObjectDocument

com.couchbase.client.java.BinaryTest STANDARD_ERROR
    log4j:WARN No appenders could be found for logger (com.couchbase.client.core.logging.CouchbaseLoggerFactory).
    log4j:WARN Please initialize the log4j system properly.
    log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.

com.couchbase.client.java.BinaryTest > shouldUpsertLegacyObjectDocument FAILED
    java.lang.NullPointerException
        at com.couchbase.client.java.BinaryTest.shouldUpsertLegacyObjectDocument(BinaryTest.java:295)
Gradle Worker 1 finished executing tests.

28 tests completed, 1 failed
Comment by Michael Nitschinger [ 21/Aug/14 ]
Hm there might be an issue with the new legacy document, a different test is failing for me.

Is there any other info in the logs what's going on?
Comment by Deepti Dawar [ 21/Aug/14 ]
The unit tests now run fine.
Tried with the latest of DP3.
Comment by Wei-Li Liu [ 21/Aug/14 ]
stacktrace for legacy document test

11:40:54.879 [DEBUG] [TestEventLogger] com.couchbase.client.java.BinaryTest > shouldUpsertLegacyObjectDocument STARTED
11:40:54.918 [DEBUG] [TestEventLogger]
11:40:54.918 [DEBUG] [TestEventLogger] com.couchbase.client.java.BinaryTest > shouldUpsertLegacyObjectDocument FAILED
11:40:54.918 [DEBUG] [TestEventLogger] java.lang.NullPointerException
11:40:54.918 [DEBUG] [TestEventLogger] at com.couchbase.client.java.BinaryTest.shouldUpsertLegacyObjectDocument(BinaryTest.java:295)
11:40:54.919 [DEBUG] [TestEventLogger] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
11:40:54.919 [DEBUG] [TestEventLogger] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
11:40:54.919 [DEBUG] [TestEventLogger] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
11:40:54.919 [DEBUG] [TestEventLogger] at java.lang.reflect.Method.invoke(Method.java:483)
11:40:54.919 [DEBUG] [TestEventLogger] at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
11:40:54.919 [DEBUG] [TestEventLogger] at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
11:40:54.919 [DEBUG] [TestEventLogger] at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
11:40:54.919 [DEBUG] [TestEventLogger] at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
11:40:54.919 [DEBUG] [TestEventLogger] at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
11:40:54.920 [DEBUG] [TestEventLogger] at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
11:40:54.920 [DEBUG] [TestEventLogger] at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
11:40:54.920 [DEBUG] [TestEventLogger] at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
11:40:54.920 [DEBUG] [TestEventLogger] at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
11:40:54.920 [DEBUG] [TestEventLogger] at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
11:40:54.920 [DEBUG] [TestEventLogger] at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
11:40:54.920 [DEBUG] [TestEventLogger] at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
11:40:54.920 [DEBUG] [TestEventLogger] at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
11:40:54.920 [DEBUG] [TestEventLogger] at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
11:40:54.921 [DEBUG] [TestEventLogger] at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
11:40:54.921 [DEBUG] [TestEventLogger] at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:86)
11:40:54.921 [DEBUG] [TestEventLogger] at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:49)
11:40:54.921 [DEBUG] [TestEventLogger] at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:69)
11:40:54.921 [DEBUG] [TestEventLogger] at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
11:40:54.921 [DEBUG] [TestEventLogger] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
11:40:54.921 [DEBUG] [TestEventLogger] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
11:40:54.921 [DEBUG] [TestEventLogger] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
11:40:54.922 [DEBUG] [TestEventLogger] at java.lang.reflect.Method.invoke(Method.java:483)
11:40:54.922 [DEBUG] [TestEventLogger] at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
11:40:54.922 [DEBUG] [TestEventLogger] at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
11:40:54.922 [DEBUG] [TestEventLogger] at org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
11:40:54.922 [DEBUG] [TestEventLogger] at org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
11:40:54.922 [DEBUG] [TestEventLogger] at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
11:40:54.922 [DEBUG] [TestEventLogger] at org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:105)
11:40:54.922 [DEBUG] [TestEventLogger] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
11:40:54.922 [DEBUG] [TestEventLogger] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
11:40:54.922 [DEBUG] [TestEventLogger] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
11:40:54.923 [DEBUG] [TestEventLogger] at java.lang.reflect.Method.invoke(Method.java:483)
11:40:54.923 [DEBUG] [TestEventLogger] at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
11:40:54.923 [DEBUG] [TestEventLogger] at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
11:40:54.923 [DEBUG] [TestEventLogger] at org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:355)
11:40:54.923 [DEBUG] [TestEventLogger] at org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:64)
11:40:54.923 [DEBUG] [TestEventLogger] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
11:40:54.923 [DEBUG] [TestEventLogger] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
11:40:54.923 [DEBUG] [TestEventLogger] at java.lang.Thread.run(Thread.java:745)
11:40:54.925 [DEBUG] [TestEventLogger]
11:40:54.925 [DEBUG] [TestEventLogger] com.couchbase.client.java.BinaryTest > shouldInsertAndGet STARTED
11:40:54.925 [DEBUG] [TestEventLogger]
11:40:54.925 [DEBUG] [TestEventLogger] com.couchbase.client.java.BinaryTest > shouldInsertAndGet PASSED
11:40:57.110 [QUIET] [system.out] 11:40:57.110 [
11:40:57.110 [DEBUG] [TestEventLogger]
11:40:57.110 [QUIET] [system.out] DEBUG] [org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor] Executing test class com.couchbase.client.java.DesignDocumentTest
Comment by Wei-Li Liu [ 21/Aug/14 ]
This exception is caused by integration test, which is somewhat a duplicate of JCBC-481.
unit test works fine for me too.




[JCBC-551] Implement blocking API around async one Created: 11/Sep/14  Updated: 15/Sep/14  Resolved: 15/Sep/14

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

Type: Task 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





[JCBC-525] Add support for full JSON compat docs & common flags Created: 22/Aug/14  Updated: 16/Sep/14  Resolved: 15/Sep/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-beta2
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





[JCBC-470] Implement Carrier-based configuration management Created: 10/Jun/14  Updated: 07/Jul/14  Resolved: 07/Jul/14

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

Type: New Feature 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





[JCBC-469] Implement HTTP-based configuration management Created: 10/Jun/14  Updated: 07/Jul/14  Resolved: 07/Jul/14

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

Type: New Feature 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





[JCBC-468] Implement EBNF-based N1QL DSL Created: 10/Jun/14  Updated: 07/Jul/14  Resolved: 07/Jul/14

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

Type: New Feature 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





[JCBC-450] 1.4.0 is not published on maven central Created: 17/Apr/14  Updated: 21/Apr/14  Resolved: 18/Apr/14

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

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


 Description   
Just reported by support, 1.4.0 doesn't seem to be on maven central.

 Comments   
Comment by Michael Nitschinger [ 18/Apr/14 ]
It shows up:

http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22com.couchbase.client%22%20AND%20a%3A%22couchbase-client%22

and the artifacts can be downloaded.
Comment by Michael Nitschinger [ 18/Apr/14 ]
Dont think this is a bug, maybe the person needs to update his maven index in the IDE from time to time so it gets picked up properly by autocomplete.
Comment by Matt Ingenthron [ 21/Apr/14 ]
We determined that the issue is the lexical sort of the artifacts. In the future, we'll need to be more careful about how we publish DPs. I think the -SNAPSHOT approach understood by maven needs to be implemented. This should be fixed with a 1.4.1 shortly.




[JCBC-399] ViewFuture Listeners get completed twice Created: 11/Jan/14  Updated: 14/Jan/14  Resolved: 14/Jan/14

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

Type: Bug 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


 Description   
This is a regression from 1.3.0.

See https://github.com/ReactiveCouchbase/ReactiveCouchbase-core/issues/3 for more details

 Comments   
Comment by Michael Nitschinger [ 13/Jan/14 ]
http://review.couchbase.com/#/c/32305/




[JCBC-360] Prepare for move to maven central Created: 10/Sep/13  Updated: 17/Sep/13  Resolved: 17/Sep/13

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

Type: Task 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





[JCBC-349] Calling flush() on CouchbaseClient throws a ClassCastException Created: 26/Aug/13  Updated: 04/Sep/13  Resolved: 04/Sep/13

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1.9
Fix Version/s: 1.2
Security Level: Public

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


 Description   
When calling flush() on CouchbaseClient a ClassCastException is thrown:

java.lang.ClassCastException: com.couchbase.client.CouchbaseMemcachedConnection cannot be cast to com.couchbase.client.CouchbaseConnection
at com.couchbase.client.CouchbaseClient.flush(CouchbaseClient.java:2421) ~[couchbase-client-1.1.9.jar:1.1.9]
at com.couchbase.client.CouchbaseClient.flush(CouchbaseClient.java:2410) ~[couchbase-client-1.1.9.jar:1.1.9]

The problem seems to be in CouchbaseClient:2421, maybe related to JCBC-323?

 Comments   
Comment by Michael Nitschinger [ 26/Aug/13 ]
Jup looks like a bug! Expect a fix for the next release.
Comment by Michael Nitschinger [ 27/Aug/13 ]
http://review.couchbase.org/#/c/28599/




[JCBC-339] Couchbase java client ignores provided username and always use bucket as username during HTTP authorization step Created: 31/Jul/13  Updated: 31/Jul/13  Resolved: 31/Jul/13

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

Type: Bug Priority: Blocker
Reporter: Sergey Bushik Assignee: Michael Nitschinger
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Server: CentOS 2.6.32 x86_64, Client: MacOS Darwin 12.4.0, Java 1.6


 Description   
new CouchbaseClient(servers, "default", "username", "password") doesn't honor provided username and always use bucket as username during HTTP authorization step.

Outgoing request is:
FINE: www.MessageHeader@658f73867'>sun.net.www.MessageHeader@658f73867 pairs: {GET /pools HTTP/1.1: null}{Accept: application/json}{user-agent: Couchbase Java Client}{X-memcachekv-Store-Client-Specification-Version: 1.0}{Authorization: Basic ZGVmYXVsdDpwYXNzd29yZA==}{Host: 192.168.1.79:8091}{Connection: keep-alive}
Text value of Authorization header corresponds to "Basic default:password", while it should be "Basic username:password"

Therefore 401 unauthorized response received:
www.MessageHeader@92f1bf07'>sun.net.www.MessageHeader@92f1bf07 pairs: {null: HTTP/1.1 401 Unauthorized}{WWW-Authenticate: Basic realm="Couchbase Server Admin / REST"}{Server: Couchbase Server 2.1.0-718-rel-enterprise}{Pragma: no-cache}{Date: Wed, 31 Jul 2013 13:10:21 GMT}{Content-Length: 0}{Cache-Control: no-cache}

The actual bug hides at line #131 of method com.couchbase.client.CouchbaseConnectionFactoryBuilder.buildCouchbaseConnection(final List<URI> baseList, final String bucketName, final String usr, final String pwd), wher usr parameter is not used anyhow and just ignored

Or see it at:
https://github.com/couchbase/couchbase-java-client/blob/master/src/main/java/com/couchbase/client/CouchbaseConnectionFactoryBuilder.java#L131

 Comments   
Comment by Michael Nitschinger [ 31/Jul/13 ]
Hi Sergey,

that's intended and not an issue. This is because the "user" is currently not being used, you always need to use the bucket name as the user and the password.

The only occasion where you dont get around with bucket level credentials is by adding/removing buckets, with the ClusterManager, and there you need to provide the admin creds.

Makes sense?
Comment by Sergey Bushik [ 31/Jul/13 ]
Technically, I see extended signature which accepts bucket, username & password parameters. Even though the credentials are valid, it throws out error, which says nothing about username parameter usage, but...

java.io.IOException: Server returned HTTP response code: 401 for URL: http://192.168.1.79:8091/pools
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1436)
at com.couchbase.client.vbucket.ConfigurationProviderHTTP.readToString(ConfigurationProviderHTTP.java:424)
at com.couchbase.client.vbucket.ConfigurationProviderHTTP.readPools(ConfigurationProviderHTTP.java:210)
at com.couchbase.client.vbucket.ConfigurationProviderHTTP.getBucketConfiguration(ConfigurationProviderHTTP.java:147)
at com.couchbase.client.CouchbaseConnectionFactory.getVBucketConfig(CouchbaseConnectionFactory.java:229)
at com.couchbase.client.CouchbaseClient.<init>(CouchbaseClient.java:241)
Exception in thread "main" com.couchbase.client.vbucket.ConfigurationException: Configuration for bucket "default" was not found in server list ([http://192.168.1.79:8091/pools]).

That's confusing. By the way, I debugged and found that it's possible to authenticate using bucket/username/password over HTTP (modified ConfigurationProviderHTTP).




[JCBC-245] Docs: Javadoc states that a java.lang.String is required for the value in a write operation, whereas online docs state object Created: 12/Feb/13  Updated: 27/Feb/13  Resolved: 27/Feb/13

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1.2
Fix Version/s: 1.1.3
Security Level: Public

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


 Description   
Java docs here: http://www.couchbase.com/autodocs/couchbase-java-client-1.1.2/

All set/replace/add/cas operations state something like:
cas(java.lang.String key, long cas, java.lang.String value, PersistTo req)

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

State that it's an "Object value"

Looking deeper, it appears that the memcached methods inherited from spy use java.lang.object which leads to user confusion when trying to compare the two.

 Comments   
Comment by Perry Krug [ 12/Feb/13 ]
Adding a library component since the Java docs show what the required type is, and if we are limiting to strings, we are preventing people from using these methods with non-string objects without writing their own transcoder which seems a little arduous in the simpler cases.
Comment by Michael Nitschinger [ 19/Feb/13 ]
That's purely a lib bug, since those should also require Object instead of String.




[JCBC-242] The flush() operations always fails with "401 Unathorized" message Created: 08/Feb/13  Updated: 08/Feb/13  Resolved: 08/Feb/13

Status: Resolved