http://www.couchbase.com/issues This file is an XML representation of an issue en-us 5.2.4 845 26-12-2012 http://www.couchbase.com/issues/browse/JCBC-142 Couchbase Java Client 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. <br/> <br/> Also, the observe test inside the CouchbaseClient fails sometime which may correlate to the same issue. JCBC-142

Observe Tests show that something is wrong in the observe impl

Bug Blocker Closed Fixed Public Mike Wiederhold Michael Nitschinger Thu, 8 Nov 2012 02:41:36 -0600 Mon, 3 Dec 2012 05:36:19 -0600 Tue, 27 Nov 2012 07:31:48 -0600 1.1-dp4 1.1-beta library 0 0 This is the test to reproduce it: <a href="https://github.com/couchbase/couchbase-java-client/commit/df5b6a53bbd61ca8daf64d56919e79d81870355e">https://github.com/couchbase/couchbase-java-client/commit/df5b6a53bbd61ca8daf64d56919e79d81870355e</a> <br/> (you may have to increase the amount of sets to be done to make sure the disk queue takes some time to get flushed) Please reproduce with another client and assign it back to me if it appears to be a client library issue.<br/> <br/> thanks! I&#39;ve tried to replicate this in PHP, but without success.<br/> <br/> It sounds like the observe operation is failing and therefore the view is returning bad results. I&#39;m not familiar with the Java API, but the set+persist wouldn&#39;t throw an exception if it fails - you&#39;d need to check the future.getStatus().isSuccess() or something.<br/> <br/> I&#39;m pasting a very ad-hoc test that I&#39;ve written for PHP (more comments will be inline with that) Update: <br/> <br/> I&#39;ve re-run the tests with a two node cluster. I see similar behavior. This looks like a server bug. Michael, can you modify the test code to check for observe exceptions (and in general make it function more similarly to the php code). <br/> <br/> This way we can have confident confirmation from both clients, and file a server bug <br/> <br/> Failed observe does not throw an exception, as per <br/> <br/> <a href="https://github.com/couchbase/couchbase-java-client/blob/df5b6a53bbd61ca8daf64d56919e79d81870355e/src/main/java/com/couchbase/client/CouchbaseClient.java#L909">https://github.com/couchbase/couchbase-java-client/blob/df5b6a53bbd61ca8daf64d56919e79d81870355e/src/main/java/com/couchbase/client/CouchbaseClient.java#L909</a> <br/> <br/> (From then same revision linked to in the description). I&#39;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? <br/> <br/> anyway.. I&#39;ve observed duplicate behavior: <br/> <br/> Basically, many of the times, the stale test fails, returning *exactly* half of the keys in the view. <br/> <br/> Maybe my cluster config is funky, but this is doubtful.. <br/> <br/> Anyway, we&#39;ll file a cluster bug with a 100% certainty that this is a client issue. <br/> <br/> btw, I&#39;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).. <br/> <br/> Placing load on the server (i.e. by using multiple setter threads) seems to highlight this issue.. and I have a feeling it&#39;s a lag/race condition sort of thing. <br/> <br/> <a href="https://github.com/mnunberg/couchbase-java-client/commit/3d788ab9d3a88c1dc20717c4dd110e3a8bb5f5bc">https://github.com/mnunberg/couchbase-java-client/commit/3d788ab9d3a88c1dc20717c4dd110e3a8bb5f5bc</a> java.lang.AssertionError: expected:&lt;500&gt; but was:&lt;180&gt; <br/> at org.junit.Assert.fail(Assert.java:91) <br/> at org.junit.Assert.failNotEquals(Assert.java:645) <br/> at org.junit.Assert.assertEquals(Assert.java:126) <br/> at org.junit.Assert.assertEquals(Assert.java:470) <br/> at org.junit.Assert.assertEquals(Assert.java:454) <br/> at com.couchbase.client.ViewTest.testObserveWithStaleFalse(ViewTest.java:839) <br/> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) <br/> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) <br/> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) <br/> at java.lang.reflect.Method.invoke(Method.java:616) <br/> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) <br/> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) <br/> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) <br/> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) <br/> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) <br/> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) <br/> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76) <br/> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) <br/> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) <br/> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) <br/> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) <br/> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) <br/> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) <br/> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) <br/> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) <br/> at org.junit.runners.ParentRunner.run(ParentRunner.java:236) <br/> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) <br/> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) <br/> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) <br/> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) <br/> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) <br/> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) <br/> 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. Is there a ticket we can link to? Mike had been in here earlier today and thinks he knows where the issue is, so passing assignment to him. Fixed and pushed to master, will be available in dp5! Looks like this is still not solved, from time to time the test still shows missing documents! Test case was flawed, now fixed and pushed. Rank 10131 Time In Status