[JCBC-605] document the supported JVMs Created: 23/Oct/14  Updated: 23/Oct/14

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

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


 Description   
At the moment, we compile for JDK 1.6 and later and test with a certain number of JDKs. We should determine what the team is comfortable listing as supported given this as there are some JVM environments we would have difficulty listing official support for.

Things to consider:
- OpenJDK versions
- JRockit
- IBM JVM

For instance, is JRockit on Linux supported? Is IBM JVM on Windows supported?

 Comments   
Comment by Matt Ingenthron [ 23/Oct/14 ]
todd: assigned this to you as it's something to work with engineering leads and QE. we should support what we test.




[JCBC-604] Push Observe implementation to core-io library Created: 22/Oct/14  Updated: 22/Oct/14

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

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

Issue Links:
Dependency
depends on JVMCBC-51 Pull Observe utility class from java ... Open

 Description   
To reduce code duplication and improve maintainability




[JCBC-603] Java SDK 2.0 Docs: add brief paragraph on new style bulk get Created: 22/Oct/14  Updated: 22/Oct/14

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

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


 Description   
In the 1.4.x series SDK's we had support for 'bulk get' operations as part of the API.

These bulk specific APIs are no longer necessary in the 2.0 SDK as it's very straightforward to achieve the same results in other ways.

Having said that, for customers who are familiar with our 1.4.x SDK, it's a little confusing as there is no reference to bulk get in the new docs. There is a very good example of how to do it a 'bulk get', but it took me about 15-20minutes to find it as I spent a lot of time searching through the API refs looking for bulk get, then looking in the docs for similar things.

In the section where the mechanism is described in the docs, could we just add one sentence which actually uses the words 'bulk get' or "getBulk" so that people trying to migrate from old APIs to the new will pick up the right place to look very quickly when searching?

This is the relevant page in the new docs:
http://docs.couchbase.com/developer/java-2.0/observables.html

And this is the Java 8 code example showing how it works:

// Loads 3 documents in parallel
Observable
    .just("doc1", "doc2", "doc3")
    .flatMap(bucket::get)
    .subscribe(document -> System.out.println("Got: " + document));


Perhaps we could just add a sentence in the pre-amble before example saying something like:
"Where as previously a specialist getBulk API was required, this is no long necessary as it can be seen that it's straight forward to implement as seen in the example".

I'm sure there are better ways of saying it, but hopefully it's sufficient to understand the intention.




[JCBC-602] Correctly handle CAS mismatches when remove with CAS is called. Created: 22/Oct/14  Updated: 22/Oct/14  Resolved: 22/Oct/14

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


 Comments   
Comment by Michael Nitschinger [ 22/Oct/14 ]
http://review.couchbase.org/#/c/42347/




[JCBC-601] Expose returned CAS value on remove() responses Created: 22/Oct/14  Updated: 22/Oct/14  Resolved: 22/Oct/14

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


 Comments   
Comment by Michael Nitschinger [ 22/Oct/14 ]
http://review.couchbase.org/#/c/42346/




[JCBC-600] Append/Prepend operations should return null for content in result Created: 22/Oct/14  Updated: 22/Oct/14  Resolved: 22/Oct/14

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

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


 Description   
Because we actually do not know the new value of the document, it must be completely clear for users that they should not utilize the content attribute from Response

Currently it returns new document with content from request

 Comments   
Comment by Michael Nitschinger [ 22/Oct/14 ]
http://review.couchbase.org/#/c/42348/




[JCBC-599] Handle CAS in remove operation Created: 22/Oct/14  Updated: 22/Oct/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: Sergey Avseyev Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JVMCBC-49 Check CAS from RemoveRequest Resolved
depends on JVMCBC-48 Populate CAS with RemoveResponse Resolved

 Description   
The CAS value should be exposed in operation response, and also checked in request for integrity




[JCBC-598] Auth failure using carrier protocol is too subtle Created: 21/Oct/14  Updated: 21/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: Minor
Reporter: Dan Douglas Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: connection
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File aero-ebay.log    

 Description   
We just ran into a problem with a misconfigured datasource. We traced it to a bad password, but we had to enable DEBUG logging on the client to get that indication.

Without DEBUG logging turned on, this shows up as

com.couchbase.client.vbucket.ConfigurationException: Could not fetch a valid Bucket configuration.

but once we enable DEBUG logging, we get the following in the log

2014-10-21 18:32:49,760 DEBUG [Memcached IO over {CouchbaseConfigConnection to oauthcbdb05.db.stratus.ebay.com/10.66.100.13:11210}] Reconnection due to exception handling a memcached operation on {QA sa=oauthcbdb05.db.stratus.ebay.com/10.66.100.13:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=1}. This may be due to an authentication failure.
net.spy.memcached.ops.OperationException: Auth failure
at net.spy.memcached.protocol.BaseOperationImpl.handleError(BaseOperationImpl.java:192) ~[spymemcached-2.11.4.jar:2.11.4]
at net.spy.memcached.protocol.binary.OperationImpl.finishedPayload(OperationImpl.java:204) ~[spymemcached-2.11.4.jar:2.11.4]
at net.spy.memcached.protocol.binary.SASLBaseOperationImpl.finishedPayload(SASLBaseOperationImpl.java:98) ~[spymemcached-2.11.4.jar:2.11.4]
at net.spy.memcached.protocol.binary.OperationImpl.readPayloadFromBuffer(OperationImpl.java:196) ~[spymemcached-2.11.4.jar:2.11.4]
at net.spy.memcached.protocol.binary.OperationImpl.readFromBuffer(OperationImpl.java:139) ~[spymemcached-2.11.4.jar:2.11.4]
at net.spy.memcached.MemcachedConnection.readBufferAndLogMetrics(MemcachedConnection.java:861) [spymemcached-2.11.4.jar:2.11.4]
at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:840) [spymemcached-2.11.4.jar:2.11.4]
at net.spy.memcached.MemcachedConnection.handleReadsAndWrites(MemcachedConnection.java:720) [spymemcached-2.11.4.jar:2.11.4]
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:683) [spymemcached-2.11.4.jar:2.11.4]
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:436) [spymemcached-2.11.4.jar:2.11.4]
at com.couchbase.client.CouchbaseConnection.run(CouchbaseConnection.java:325) [couchbase-client-1.4.4-JCBC-566-3.jar:1.4.4-JCBC-566-3]

Bad passwords used to get and exception referencing a 401 status code when the map was read via HTTP.

Now using the carrier protocol, there isn't a good way to tell the difference between a bad password and the bucket not existing.

I know it sounds trivial, but tracking down the difference in our production environment just ate up a few hours of engineer time -- time that would have been saved if the exception message indicated that it had been caused by an Auth Failure.... the spymemcached exception did, but somewhere along the way that got swallowed and all we got was "Could not fetch a valid Bucket configuration."

I've attached the log with DEBUG turned on.




[JCBC-597] Refactor view mapping for better testability. Created: 21/Oct/14  Updated: 22/Oct/14  Resolved: 22/Oct/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0.1
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-596] Default and Maximum Lock Time needs clarifying Created: 19/Oct/14  Updated: 21/Oct/14

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

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

Issue Links:
Relates to
relates to MB-12379 Default and Maximum lock time describ... Open

 Description   
The maximum lock in 2.5.1 and 3.0.0 is 30 secs, the default is 15 seconds. Any attempt to set a lock higher than the maximum results in the default being used. The Java Developer Guide and API docs need updating to reflect this behaviour.



 Comments   
Comment by Michael Nitschinger [ 20/Oct/14 ]
Since you filed this for java, can you refer which page you want updating? The page you linked here states:

Note:
You can only write lock a document for a maximum of 30 seconds.

and
30 seconds are over and the server unlocks it for you.

and what do you mean by default lock time? There is no such thing in the SDK, the developer always needs to provide a lock time.
Comment by Chris Malarky [ 20/Oct/14 ]
There are two values in the server - ep_getl_max_timeout and ep_getl_default_timeout - not sure if they are configurable yet. If you don't specify a value, or specifiy greater than the max, then the default is used (which is 15 seconds).
Comment by Michael Nitschinger [ 20/Oct/14 ]
I'm not sure when the default ever applies - the binary protocol requires you to transmit the expiration time explicitly - so a default expiration time - other than 0 so do not expire - doesn't make much sense in an SDK context
Comment by Chris Malarky [ 20/Oct/14 ]
The default (15 seconds) does apply if you set an invalid lock time (less than zero, greater than 30).
Comment by Michael Nitschinger [ 20/Oct/14 ]
Ha! good to know that this exists, didn't know that. I was already thinking about disallowing an invalid time at all, but then if someone changes the 30 sec limit on the server it falls short.
Comment by Chris Malarky [ 20/Oct/14 ]
Exactly. Still not found for sure if these are configurable. If they are then you need to query the two values to check what they are.




[JCBC-595] names of jars is weird Created: 17/Oct/14  Updated: 17/Oct/14

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

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


 Description   
core-io-1.0.0 and java-client-2.0.0?

Shouldn't those have couchbase in them?

When they come from the zipfile, it could be really confusing.




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

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

Type: Bug Priority: Critical
Reporter: Matt Ingenthron Assignee: Michael Nitschinger
Resolution: Unresolved 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






Generated at Fri Oct 24 02:44:17 CDT 2014 using JIRA 5.2.4#845-sha1:c9f4cc41abe72fb236945343a1f485c2c844dac9.