Observe Tests show that something is wrong in the observe impl

Michael Nitschinger added a comment - 09/Nov/12 12:20 PM - edited 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)

Michael Nitschinger added a comment - 09/Nov/12 12:48 PM Please reproduce with another client and assign it back to me if it appears to be a client library issue. thanks!

Mark Nunberg added a comment - 09/Nov/12 6:21 PM 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)

Mark Nunberg added a comment - 09/Nov/12 8:02 PM Update: I've re-run the tests with a two node cluster. I see similar behavior. This looks like a server bug.

Mark Nunberg added a comment - 09/Nov/12 8:29 PM 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).

Mark Nunberg added a comment - 09/Nov/12 10:50 PM - edited 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

Mark Nunberg added a comment - 09/Nov/12 10:55 PM 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)

Matt Ingenthron added a comment - 13/Nov/12 7:52 AM 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.

Michael Nitschinger added a comment - 14/Nov/12 9:41 AM Is there a ticket we can link to?

Matt Ingenthron added a comment - 19/Nov/12 11:20 PM Mike had been in here earlier today and thinks he knows where the issue is, so passing assignment to him.

Michael Nitschinger added a comment - 21/Nov/12 5:21 AM Fixed and pushed to master, will be available in dp5!

Michael Nitschinger added a comment - 21/Nov/12 7:21 AM Looks like this is still not solved, from time to time the test still shows missing documents!

Michael Nitschinger added a comment - 27/Nov/12 7:31 AM Test case was flawed, now fixed and pushed.