[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-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-351] Enhance ReplicaRead with active node Created: 27/Aug/13  Updated: 13/Sep/13  Resolved: 13/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: Improvement Priority: Critical
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-350] Race Condition in observe/replica Created: 27/Aug/13  Updated: 11/Sep/13  Resolved: 11/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: Critical
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Michael Nitschinger [ 27/Aug/13 ]
Pushed into master, awating reporter feedback for close.




[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-348] Request for "metrics gathering" feature Created: 22/Aug/13  Updated: 17/Sep/13  Resolved: 17/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: Improvement Priority: Major
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   
Similar to Cassandra's indication with speed4J, a request for a feature to be able to gather metrics from a test workload in terms of number of operations, latencies, etc.




[JCBC-347] Adjust observe intervals for better performance Created: 20/Aug/13  Updated: 27/Aug/13  Resolved: 27/Aug/13

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





[JCBC-346] Support CRAM-MD5 as a sasl mechanism Created: 15/Aug/13  Updated: 27/Aug/13  Due: 19/Aug/13  Resolved: 27/Aug/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: Major
Reporter: Mike Wiederhold Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Matt Ingenthron [ 15/Aug/13 ]
Michael: I know you're missing a bit of information here, but the goal is that the 2.2 server release be tested with this functionality. This would mean getting this together either on the 16th or monday the 23rd.
Comment by Michael Nitschinger [ 27/Aug/13 ]
JCBC ticket merged, corresponding SPY will be in 2.9.2




[JCBC-345] Enhance intelligence of client to know about all nodes of a cluster for making REST connection Created: 15/Aug/13  Updated: 17/Sep/13  Resolved: 17/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: Improvement Priority: Major
Reporter: Perry Krug Assignee: Matt Ingenthron
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
If configured with a single host (a load balancer), the client may pause for everytime it loses this connection. The same thing happens when configured with a list of hosts and the client reaches the end of the list...it pauses before going back to the top.

I don't think it's appropriate to ask for the client to constantly spin on trying to make a connection if in fact none can be made.

Another solution to this would be to have the client be aware of ALL the servers in a cluster (which it gets via the vbucket map info) and be able to try all of them, and/or know which ones are alive so that it doesn't have to wait

 Comments   
Comment by Perry Krug [ 15/Aug/13 ]
This is also needed when trying to upgrade the entire cluster as IP addresses are changing (mostly in AWS)
Comment by Perry Krug [ 27/Aug/13 ]
Matt, can this get added to 1.2 as well or is it being deferred?
Comment by Michael Nitschinger [ 27/Aug/13 ]
Perry, whats the deal here?

The reconfiguration is done with backoff (and sleep during backoff), so its not really consuming CPU time.
Comment by Perry Krug [ 27/Aug/13 ]
The deal is to enhance the client so that even if all of the bootstrap nodes become available (or are removed from the cluster) the running client still is able to communicate with the cluster and receive topology changes.

Example:
-4 node cluster with 1.1.1.1, 1.1.1.2., 1.1.1.3, 1.1.1.4.
-1.1.1.1 and 1.1.1.2 are given to the java client as bootstrap nodes
-Now, an upgrade is taking place and 1.1.1.1 and 1.1.1.2 are being swapped out for .5 and .6.
-With the current implementation, the client would not be able to receive further topology updates
-This enhancement is asking that even though .1 and .2 were used for bootstrap, .3 and .4 would be included within the internal list of the client so that when .1 and .2 go away, it can failover to .3 or .4 and continue working.

Obviously a restart of the same client would fail because it couldn't reach .1 or .2, but this is understood and not what we're trying to achieve.

Comment by Michael Nitschinger [ 27/Aug/13 ]
Okay gotcha, I'll think this through.




[JCBC-344] allow for setting bootstrap nodes via a configuration file, including dynamic updates Created: 14/Aug/13  Updated: 13/Sep/13  Resolved: 13/Sep/13

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

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

Issue Links:
Dependency
depends on JCBC-138 Java Client does not recover when onl... Resolved

 Description   
Currently, bootstrap parameters may be supplied only via arguments to the constructor. A feature should be added to allow for URLs to be used for bootstrap to be configured via a properties file or something along those lines. This should be able to be edited, and then picked up, during a given client object's lifetime.

 Comments   
Comment by Michael Nitschinger [ 04/Sep/13 ]
The second part of this feature list is to be done in issue JCBC-138.

The constructor with properties will be tracked in this one.




[JCBC-343] Adding Listener support Created: 14/Aug/13  Updated: 01/Oct/13  Resolved: 01/Oct/13

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

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


 Comments   
Comment by thanhbv [ 21/Sep/13 ]
see the following scala code:

val op: OperationFuture[T] = ... //an OperationFuture of type T
op.addListener(new OperationCompletionListener {
  def onComplete(op2: OperationFuture[_]) {
    //I think op2 == op ???
    if(op.getStatus.isSuccess){
      //Here, how to get the value (of type T) in the successfully completed OperationFuture op?
      //I want the result of op.get: https://github.com/couchbase/spymemcached/blob/fb6e0f01cfae13a180127cd65dbec7b025cfbc8e/src/main/java/net/spy/memcached/internal/OperationFuture.java#L158
      //I think we shoud add the following check to (first line of method) OperationFuture#get:
      //if(op != null && op.getState() == OperationState.COMPLETE) return objRef.get();
    }
  }
})
Comment by thanhbv [ 21/Sep/13 ]
@see https://gist.github.com/thanh-buiviet/6649489
Comment by Matt Ingenthron [ 23/Sep/13 ]
Michael is out this week but he should look at this soon. Reopening for now though itmay be a separate request.
Comment by Michael Nitschinger [ 30/Sep/13 ]
Hey,

I'm not quite sure what you say here, can you elaborate a bit? I'm not sure if we should change the OperationFuture.get() behavior, but I'm open to everything if its a bug :)

Also, yes, the future in the onComplete callback is the same. Just so that you could pass in a specific object that doesn't need to come out of the same scope.
Comment by thanhbv [ 30/Sep/13 ]
I have a XXFuture[T] f that hold a future that when complete will produce a value v of type T if success, or produce a failure with some reason.
XXFuture can be OperationFuture, GetFuture, HttpFuture,.. (not just OperationFuture)

When I call f.addListener(some_handler) then, in some_handler (will be call when f is completed), spymemcache need provide a way for me to determine if f is success or not.
"a way" here is f.getStatus.isSuccess. OK.

When I see that f is successful, I need a way to get "the successful value" v.
"a way" here is f.get. Right?

So, I think the implementation of `get` method in OperationFuture, GetFuture,.. should check that if `this` future is already completed then the `get` method should return the completed value immediately.

I think the behavior of the get methods should as the description above.
get := if(completed){ return the completed value} else {value = do_get(); return value }


Sorry. English is not my first language :)
Comment by Michael Nitschinger [ 30/Sep/13 ]
You are right, but that's whats happening (if I understand you correctly).

If the latch is already counted down in the future, you'll get the response back immediately. So first checking for success (which implies that its completed) and then calling .get() is perfectly fine.

Does that makes sense? It's not mine either ;)
Comment by thanhbv [ 01/Oct/13 ]
The current implementation of #get, when the future is completed successfully:
+ OperationFuture#get will almost return immediately. It's OK.
+ BulkGetFuture#get is delegated to #internalGet that call some java.util.concurrent.FutureTask#get. It's OK too.
+ GetFuture#get is also OK.
...
:D after digging into all subclasses of ListenableFuture, I found that all of it is OK! So I think this issue should be (re-)set to resolved now.

thank you.




[JCBC-334] release notes for 1.2.0 Created: 24/Jul/13  Updated: 17/Sep/13  Resolved: 17/Sep/13

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

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


 Description   
Need published release notes for 1.2.0.

This would be expected around first week of September.

 Comments   
Comment by kzeller [ 24/Jul/13 ]
Important: as of 7/24 we are waiting on Ray to get ubu-1701 running. Java 1.2 files exist but are not yet publishable on the web.
Comment by Matt Ingenthron [ 29/Jul/13 ]
Update from Karen last week, the VM has been recovered. I believe we're good to go on docs.




[JCBC-333] Views are having issues in access and validations Created: 23/Jul/13  Updated: 12/Sep/13  Resolved: 12/Sep/13

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

Type: Bug Priority: Major
Reporter: Deepti Dawar Assignee: Michael Nitschinger
Resolution: Fixed 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

Attachments: Microsoft Excel java-1.1.8-release-2.1.1-763-1h_AT-2013-07-22T19-34-57.xlsx    
Sub-Tasks:
Key
Summary
Type
Status
Assignee
JCBC-358 make log file accessible Technical task Resolved Deepti Dawar  

 Description   
SDKD: Caused by: java.util.concurrent.ExecutionException: OperationException: SERVER: not_found Reason: missing

SDKD: WARNING: Unknown exception encountered (for operation) future warnings will be suppressed
SDKD: java.lang.RuntimeException: Failed to access the view



 Comments   
Comment by Deepti Dawar [ 23/Jul/13 ]
For all the logs and related information you can refer to the latest test results at -

https://docs.google.com/a/globallogic.com/spreadsheet/ccc?key=0AmLvaJ8oRZ-TdGxtdExRVTBMNnhDb1hac3pFV3VrMHc#gid=0
Comment by Matt Ingenthron [ 05/Aug/13 ]
Alk: In this test, we have a four node cluster and we're trying to remove two nodes from the cluster while under load. The Java client is getting a response from the cluster: The response seems to be a 404 =>
not_found Reason: missing

This isn't a new issue, but I don't think we expect to receive a 404 during node removal, do we?

If you could help us understand what to expect here and reassign it, I'd appreciate it.
Comment by Aleksey Kondratenko [ 26/Aug/13 ]
I don't have access to logs. But I think this is what happens.

When bucket rebalance out completes we stop all per-bucket services on rebalanced out nodes for this bucket. Including it's capi_set_view_manager. This is different case from where node still has bucket instance but doesn't have any active vbuckets left (in which case you'll receive redirect).

Let me note that as we've agreed in past there's 10 second delay after rebalance out of bucket and stopping of bucket services (and bucket instance in memcached). Which works fine for kv access because you send requests depending on vbucket map. But is not directly helping you for views access.

Here's what you can do:

*) never send view request to node without any active vbuckets. After all you do have vbucket map and it's reasonably easy

*) on receiving 404 just retry with other node(s)
Comment by Matt Ingenthron [ 30/Aug/13 ]
Michael: Can you please evaluate the comments from Alk here?
Comment by Michael Nitschinger [ 30/Aug/13 ]
Makes sense to me why it happens.

ad 404) I originally had the 404's in my retry with backoff logic, but I had to remove it because we can't distinguish that from a garbage view name that the user puts in. If we would retry in that case, we would end up with timeouts instead of semantically correct "view not found" messages.

ad active vbuckets) that sounds good and I think I can make that work pretty quickly for 1.2. If we pass on the vbucket locator to the view connection, we can verify that.

I'll update this ticket and we can then hand it over to QE for re-testing.




[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-330] Add TTL to cas methods Created: 14/Jul/13  Updated: 12/Sep/13  Resolved: 12/Sep/13

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

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

Issue Links:
Gantt: finish-start
has to be done after SPY-131 Expose CAS + Timeout Resolved

 Description   
Most of the cas methods do not have a TTL, we need to add this to have complete API

 Comments   
Comment by Tug Grall (Inactive) [ 14/Jul/13 ]
This is coming form the community:
http://www.couchbase.com/communities/q-and-a/java-api-cas-expiration




[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-138] Java Client does not recover when only bootstrap node provided and failovered Created: 05/Nov/12  Updated: 16/Dec/13  Resolved: 16/Dec/13

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

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

Issue Links:
Dependency
blocks JCBC-308 Trouble in resubscribing to primary n... Closed
blocks JCBC-344 allow for setting bootstrap nodes via... Resolved

 Description   
Within the current implementation, when the bootstrap node is failovered/removed (and only that one is provided in the list) it gets correctly removed from the SDK, but either a new try to get a different streaming connection fails or something else is wrong.

Even when the node is added back into the cluster no new view connection is created (most arguably because no map updates are received anymore).

This issue may also be the cause for other bugs related to failover scenarios reported.

 Comments   
Comment by Michael Nitschinger [ 19/Jul/13 ]
This is how it will work in the 1.1 series. if we decide for changes in the 1.2 branch (CCCP), then this will change as well. For now wont fix.
Comment by Michael Nitschinger [ 04/Sep/13 ]
http://review.couchbase.com/#/c/28785/




[JCBC-2] running unit tests under CI Created: 05/Jan/12  Updated: 31/Jan/13  Resolved: 31/Jan/13

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

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

Issue Links:
Duplicate
duplicates JCBC-3 running integration tests under CI Closed




Generated at Wed Oct 22 00:37:51 CDT 2014 using JIRA 5.2.4#845-sha1:c9f4cc41abe72fb236945343a1f485c2c844dac9.