[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-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-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-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-567] The client might still use HTTP configuration provider to fetch JSON config Created: 28/Sep/14  Updated: 28/Sep/14

Status: New
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 1.4.4
Fix Version/s: 1.4.5
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-566] CouchbaseConnectionFactory cannot schedule configuration update Created: 23/Sep/14  Updated: 26/Sep/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 1.4.0-dp1, 1.4.0-dp2, 1.4.0, 1.4.1, 1.4.2, 1.4.3, 1.4.4
Fix Version/s: 1.4.5
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

Attachments: Java Source File Hello.java    

 Description   
client is working with a cluster
network from client to cluster is disrupted (sudo service couchbase-server stop)
network from client to cluster is later restored (sudo service couchbase-server start)

expected behavior:
  client recovers and traffic proceeds a short time after the network is back to working
observed behavior:
  client does not recover

 Comments   
Comment by Sergey Avseyev [ 23/Sep/14 ]
http://review.couchbase.org/41585
Comment by Sergey Avseyev [ 23/Sep/14 ]
I've written that it affects versions since 1.4.0-dp1 because http://review.couchbase.org/32589 was relesed in 1.4.0-dp1 first time. I haven't verified all these releases, just 1.4.4.
Comment by Sergey Avseyev [ 26/Sep/14 ]
the real fix is here: http://review.couchbase.org/41674




[JCBC-501] Implement Support for DCP Created: 29/Jul/14  Updated: 26/Sep/14

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

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


 Description   
Implement support for 3.0+ DCP as a replacement for the TAP protocol and TAP Client.

To be a suitable replacement, this has a few additional requirements to meet current TAP features:
* It must be able to use buckets with authentication/passwords in addition to the default bucket
* It must be able to target active data only, rather than active and replica data
* We must be able to split/filter to individual nodes from the client interface. It may also be useful for this to be at the vbucket level.

The use case for the latter is that in some cases, such a job may be split across many client nodes reading data from a cluster with many nodes. By allowing the application code using this client library for DCP to split along these lines, it can manage how the job is run for maximum parallelism.




[JCBC-563] View query will lock up after first attempt Created: 18/Sep/14  Updated: 26/Sep/14

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 2.0-beta, 2.0-beta2
Fix Version/s: 2.0.1
Security Level: Public

Type: Bug Priority: Critical
Reporter: casmeiron Assignee: Sergey Avseyev
Resolution: Unresolved Votes: 0
Labels: deadlock, queryview
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: JAVA 1.8
MAC 10.9.4

Issue Links:
Dependency
depends on JVMCBC-40 View responses are stuck occasionally... Open

 Description   
If you try to run a simple query view twice at beta, you will notice that only #1 attempt will work, the second will wait indefinitely.

In beta-2, the query won't work at all, it will block right away!!

I've tested with async and sync mode in both releases.

Could you please take a look on that?
Thanks.


    @Test
    public void testAsync() throws Exception {
        CouchbaseCluster cluster = CouchbaseCluster.create(DefaultCouchbaseEnvironment.builder().build());
        Bucket bucket = cluster.openBucket("default");

        CountDownLatch latch = new CountDownLatch(10);

        for (int i = 0; i < 10; i++) {
            bucket
                    .async()
                    .query(ViewQuery.from("test", "test"))
                    .doOnNext(result -> {
                        if (!result.success()) {
                            System.err.println(result.error());
                        }
                    })
                    .flatMap(AsyncViewResult::rows)
                    .subscribe(row -> {
                        System.out.println(row.id());
                        latch.countDown();
                    });
        }

        latch.await();
    }




 Comments   
Comment by Matt Ingenthron [ 18/Sep/14 ]
Sergey: you may get to this before Michael
Comment by Michael Nitschinger [ 19/Sep/14 ]
Interesting, could you please share you view? When trying to reproduce this issue I found a different one, but it doesn't lock up immediately.

Thanks
Comment by Michael Nitschinger [ 19/Sep/14 ]
One thing, as a side note, I found in your view code is that you're counting down the latch for each row that returns, and that just once. You probably want more something like this?

                .flatMap(AsyncViewResult::rows)
                .doOnCompleted(latch::countDown)
                .subscribe(row -> System.out.println(row.id()));
Comment by Michael Nitschinger [ 19/Sep/14 ]
This appears to be a race condition if you actually do nothing with the results itself.

So if you do

while(true) {
      bucket.query(ViewQuery.from("beer", "brewery_beers")).toBlocking().single();
}

it will lock up, but if you add in a Thread.sleep(100) or do something with the results like printing it it will continue to work. Looking into it.
Comment by casmeiron [ 19/Sep/14 ]
Hi,
 The view emit all docs, exactly like the sample when you create a new view from console.
Thanks for improving my code with latch.
Comment by Michael Nitschinger [ 19/Sep/14 ]
I think the bug you were hitting is https://github.com/couchbase/couchbase-jvm-core/commit/805cb611deea9f36eb4cb6743733ff463e4b9f0c JVMCBC-39, but this uncovered another one which we're currently working on.
Comment by Michael Nitschinger [ 19/Sep/14 ]
One bug has been fixed, the other depends on JVMCBC-40. We are actively looking into fixing this for 2.0.1, for now please apply a lower timeout and retry the operation, this will help. 1.0.0 GA has an associated fix with a slightly different issue.
Comment by casmeiron [ 19/Sep/14 ]
Ok, I couldn't make it work setting the timeout for query and view. I will wait till you guys have a fix so we can try it again.
Thanks for the effort spent looking into this.
Best Regards.
Comment by casmeiron [ 26/Sep/14 ]
Hey Michael,

Do we have any fix for this issue? I can apply the patch locally if you have.
Comment by Matt Ingenthron [ 26/Sep/14 ]
Sergey is working this issue and may be able to advise. Sergey?




Generated at Wed Oct 01 17:11:27 CDT 2014 using JIRA 5.2.4#845-sha1:c9f4cc41abe72fb236945343a1f485c2c844dac9.