[JCBC-612] Disable Checkstyle in gradle build until we have a checkstyle configuration Created: 31/Oct/14  Updated: 31/Oct/14

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

Type: Improvement Priority: Minor
Reporter: Simon Baslé Assignee: Simon Baslé
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Gantt: start-start
has to be started together with JVMCBC-53 Disable checkstyle in gradle build pe... Open
Relates to
relates to JCBC-613 Choose and verify against a coding st... New

 Description   
At the moment no checkstyle configuration has been put in place, but checkstyle plugin is activated in gradle build. This causes the build to fail, most notably in Jenkins.
Disable the checkstyle plugin until a coding style has been decided upon and enforced through checkstyle (see linked issues).




[JCBC-614] Add List and Map factory methods to JsonArray and JsonObject Created: 31/Oct/14  Updated: 31/Oct/14

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

Type: Improvement 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   
A handy addition to the APIs would be to create JsonObjects and JsonArrays from Maps and Lists.

We need to make sure that the content though is supported and if not throw an exception.




[JCBC-613] Choose and verify against a coding standard with Checkstyle Created: 31/Oct/14  Updated: 31/Oct/14

Status: New
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 2.0.0, 2.0.1
Fix Version/s: 2.0.2
Security Level: Public

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

Issue Links:
Gantt: start-start
has to be started together with JVMCBC-54 Choose and verify against a coding st... Open
Relates to
relates to JCBC-612 Disable Checkstyle in gradle build un... New

 Description   
Choose a coding style and let the build check code conforms to it through Checkstyle plugin.

Proposed coding standard: Google Java Style (https://google-styleguide.googlecode.com/svn/trunk/javaguide.html), available as a Checkstyle configuration as summed up here: http://checkstyle.sourceforge.net/google_style.html




[JCBC-598] Auth failure using carrier protocol is too subtle Created: 21/Oct/14  Updated: 30/Oct/14

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.4.4
Fix Version/s: 2.0.1, 1.4.6
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.

 Comments   
Comment by Michael Nitschinger [ 30/Oct/14 ]
Well, I think we need to make sure its good in both 1.4.x and 2.0.x.

I'll put this on the list of both the next bugfix releases and see what we can do to improve that.

Dan, thanks for raising this.




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

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 2.0.0
Fix Version/s: 2.0.1
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-611] Improve readability of flags related elemets in TranscoderUtils Created: 30/Oct/14  Updated: 30/Oct/14

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

Type: Improvement Priority: Major
Reporter: Simon Baslé Assignee: Simon Baslé
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Dealing with flags, bit shift operators and legacy flag vs common flag specification is a non-trivial brain gymnastic. Improve readability of code related to that in TranscoderUtils to make the spec more visible and the different parts more explicit.




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

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: None
Fix Version/s: .future
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.
Comment by Michael Nitschinger [ 30/Oct/14 ]
Another one to consider is Azul's Zing

http://www.azulsystems.com/products/zing/whatisit




[JCBC-599] Handle CAS in remove operation Created: 22/Oct/14  Updated: 30/Oct/14  Resolved: 30/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: Sergey Avseyev Assignee: Michael Nitschinger
Resolution: Duplicate 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

 Comments   
Comment by Michael Nitschinger [ 30/Oct/14 ]
JCBC-602




[JCBC-609] Fix Maven Tags on 2.0 Client, remove "beta" from package tags. Created: 28/Oct/14  Updated: 30/Oct/14

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

Type: Task Priority: Critical
Reporter: Todd Greenstein Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Maven tags still list "beta" in 2.0 GA release.

http://mvnrepository.com/artifact/com.couchbase.client/java-client/2.0.0



 Comments   
Comment by Michael Nitschinger [ 30/Oct/14 ]
This is not possible anymore and has been an oversight. Action is taken to avoid this for subsequent releases.




[JCBC-596] Default and Maximum Lock Time needs clarifying Created: 19/Oct/14  Updated: 30/Oct/14

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.4.4, 2.0.0
Fix Version/s: 2.0.1
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: 30/Oct/14

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

 Comments   
Comment by Michael Nitschinger [ 30/Oct/14 ]
Hm, that's a good question. It makes total sense when you retrieve it from a package manager (since you have the group id in there), but I agree that in the zipfile it's different.

Now the question is

- should we rename the jars in the zipfile?
- can we do that without breaking anything? I don't know if the name of the jar makes a difference at all.

If it doesn't break anything, what about prefixing in the zip files with couchbase- ?




[JCBC-610] TranscoderUtils doesn't recognize BINARY_COMPAT_FLAGS as binary Created: 30/Oct/14  Updated: 30/Oct/14  Resolved: 30/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: Simon Baslé Assignee: Simon Baslé
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The TranscoderUtils.hasBinaryFlags() method doesn't return true when testing against BINARY_COMPAT_FLAGS.

 Comments   
Comment by Simon Baslé [ 30/Oct/14 ]
https://github.com/couchbase/couchbase-java-client/commit/784a5b0870ba4f11c1130dcc48c775bac4543b2e




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

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

Type: Bug Priority: Critical
Reporter: Matt Ingenthron Assignee: Amy Kurtzman
Resolution: Fixed 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



 Comments   
Comment by Amy Kurtzman [ 30/Oct/14 ]
Fixed language tagging on the page.




[JCBC-593] Getting com.couchbase.client.vbucket.BucketUpdateResponseHandler exceptionCaught exception Created: 15/Oct/14  Updated: 29/Oct/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 1.4.0, 1.4.4
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Major
Reporter: Rukmini Nagarajaiah Assignee: Simon Baslé
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Also Im trying a standalone java code to start couchbase client. Below is the code referred from http://www.couchbase.com/develop/java/previous


This is the code
public class HelloWorld {
public static final int EXP_TIME = 20;
public static final String KEY = "spoon";
public static final String VALUE = "Hello World!";

public static void main(String args[]) {
// Set the URIs and get a client
List<URI> uris = new LinkedList<URI>();
    Boolean do_delete = false; //

    // Connect to localhost or to the appropriate URI
    uris.add(URI.create("http://127.0.0.1:8091/pools"));

    CouchbaseClient client = null;
    try {
      client = new CouchbaseClient(uris, "default", "");
    } catch (Exception e) {
      System.err.println("Error connecting to Couchbase: "
        + e.getMessage());
      System.exit(0);
    }

}
}

Im getting the below exception.. May I know reason for this. ? Im like stuck with this. Please help

Oct 14, 2014 11:06:26 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler exceptionCaught
WARNING: Exception occurred: Operation timed out

Oct 14, 2014 11:06:26 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler exceptionCaught
WARNING: sun.nio.ch.FileDispatcherImpl.read0(Native Method)
sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
sun.nio.ch.IOUtil.read(IOUtil.java:192)
sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:375)
org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:69)
org.jboss.netty.channel.socket.nio.AbstractNioWorker.processSelectedKeys(AbstractNioWorker.java:390)
org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:261)
org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:35)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
java.lang.Thread.run(Thread.java:745)


dependency

       <dependency>

<groupId>com.couchbase.client</groupId>

<artifactId>couchbase-client</artifactId>

<version>1.3.0</version>

  </dependency>

        <dependency>

        <groupId>commons-codec</groupId>

        <artifactId>commons-codec</artifactId>

        <version>1.7</version>

      </dependency>

      <dependency>

        <groupId>org.codehaus.jettison</groupId>

        <artifactId>jettison</artifactId>

        <version>1.3</version>

       

      </dependency>

           <dependency>

        <groupId>net.spy</groupId>

        <artifactId>spymemcached</artifactId>

        <version>2.11.4</version>

      </dependency>

      <dependency>

<groupId>org.jboss.netty</groupId>

<artifactId>netty</artifactId>

<version>3.2.0.Final</version>

</dependency>

 Comments   
Comment by Simon Baslé [ 29/Oct/14 ]
Hi Rukmini, sorry for the delay in responding.
This seems to be a warning that happens when there is a connection loss with the node, but the client should automatically reconnect.

Did you try the complete code sample from documentation? As is, this code does in fact nothing, it just wait there with a connection open (and it appears that there's a disconnect at some point, which is logged as WARNING, but as I said this should reconnect).

Also could you confirm the version of the couchbase server you use on your machine to run the test, and that the warning arises at each run?

One other thing: you mention this affects version 1.4.0 and 1.4.4, but the pom.xml extract you give at the end depends on 1.3.0 client, does that mean you've reproduced the issue in each of these client versions?




[JCBC-608] Document version compatibility Created: 27/Oct/14  Updated: 28/Oct/14

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.4.5, 2.0.0
Fix Version/s: 2.0.1
Security Level: Public

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


 Description   
It is unclear from the existing documentation which SDK should be used when using a certain version of Couchbase. There is a feature matrix for the SDK features, but this is not a compatibility matrix. It is not clear if Couchbase Server 3.0+ is required for Couchbase Java SDK 2.0 usage, or if Couchbase Java SDK 2.0 is compatible with Couchbase Server 2.x.

Please add a compatibility matrix or some statements in the affirmative for compatibility between SDK and Server versions.




[JCBC-607] Links in tutorial missing or incorrect Created: 27/Oct/14  Updated: 28/Oct/14

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

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


 Description   
On this page:

http://docs.couchbase.com/developer/java-2.0/tutorial.html

I see these two issues:

"Download the JAR archive and run it using the command java -jar couchbaseBeersampleExample.jar." - there is no link to any JAR file.

"The framework for the tutorial can be downloaded from here." -> here is a link to www.example.org




[JCBC-606] Improve the way transcoders deal with ByteBuf on decode Created: 27/Oct/14  Updated: 27/Oct/14  Resolved: 27/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: Simon Baslé Assignee: Simon Baslé
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
In the java client, transcoders deal with ByteBuf passed by the core. It is the responsibility of the code that last uses ByteBuf to release it, which is not consistently done by some transcoders.

In order to reduce surface for leak problems, we need to facilitate correct release of buffers in transcoders decode operation, with maximum mutualization of code. This can be done by giving AbstractTranscoder the default behavior of release the buffer upon decoding and also if errors are detected.

In edge cases, ByteBuf may be needed down the road (BinaryDocument). For these cases, buffer release shouldn't be implicitly performed by the Transcoder.




[JCBC-604] Push Observe implementation to core-io library Created: 22/Oct/14  Updated: 27/Oct/14  Resolved: 27/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: Sergey Avseyev Assignee: Sergey Avseyev
Resolution: Fixed 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 ... Resolved

 Description   
To reduce code duplication and improve maintainability




[JCBC-589] Java 2.0 SDK get "Unknown" version number Created: 14/Oct/14  Updated: 24/Oct/14  Resolved: 24/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: Task Priority: Major
Reporter: Wei-Li Liu Assignee: Simon Baslé
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates to

 Description   
New API should expose sdk version info
https://github.com/couchbase/couchbase-java-client/commit/6be5a7348f6eb01bcdb475c7057a6c4d05d5a194

I am getting "unknown" for the default value of git version and couchbase-client version

=========================================================================
            Package pkg = Package.getPackage("com.couchbase.client.java");
            String version = pkg.getSpecificationVersion();
            String gitVersion = pkg.getImplementationVersion();
            PACKAGE_NAME_AND_VERSION = String.format("couchbase-java-client/%s (git: %s)",
                version == null ? "unknown" : version, gitVersion == null ? "unknown" : gitVersion);
=========================================================================


 [1.66 DEBUG] (Handle receiveMessage:158) < INFO@0.0 => {"COMPONENTS":{"USER_AGENT":"couchbase-java-client/unknown (git: unknown) (Mac OS X/10.9.4 x86_64; Java HotSpot(TM) 64-Bit Server VM 1.8.0_05-b13)","SDK_VERSION":"couchbase-java-client/unknown (git: unknown)"},"CAPS":{"VIEWS":true,"OBS":true,"DS_SHARED":true,"CANCEL":true,"CONTINUOUS":true,"TTL":true,"PREAMBLE":false}}

 Comments   
Comment by Simon Baslé [ 20/Oct/14 ]
hi wei-li,
could you please clarify how you built the sdk jar and how you used it to get the user_agent?

the gitversion is initialized by the gradle build system, and stored in the java sdk jar's manifest. usages outside of this packaged form will return unknown (as gradle won't correctly have initialized the manifest).

the version of the sdk on Maven Central (http://search.maven.org/#browse%7C650548152) exhibits correct behavior, as a simple test with maven dependency would show. Something like :
System.out.println(DefaultCouchbaseEnvironment.PACKAGE_NAME_AND_VERSION);
Comment by Wei-Li Liu [ 20/Oct/14 ]
Both Michael and Sergey verify that because sdkd repackage jars, so the java sdk jar's manifest might be lost or not found.
I think the propsed solution is to have a new snapshots and sdkd can grab the version from there.
Comment by Michael Nitschinger [ 22/Oct/14 ]
The fix has been merged into master. Please work with Simon on the actual build script follow up and then close/report here if it works now.
Comment by Michael Nitschinger [ 22/Oct/14 ]
https://github.com/couchbase/couchbase-java-client/commit/44e5e590b14634d7ffbbddaf69dd05f19b59f08a
Comment by Wei-Li Liu [ 22/Oct/14 ]
@Simon
I do get the sdk version number after pull the master, but I can't seem to get the core version right
The code to access the version number for both env
==================================
CouchbaseEnvironment Couchenv = DefaultCouchbaseEnvironment.builder().build();
CoreEnvironment Coreenv = DefaultCoreEnvironment.create();
String sdk_version = Couchenv.userAgent();
String core_version = Coreenv.userAgent();

sdkComponents.put("Core_VERSION", core_version);
sdkComponents.put("SDK_VERSION", sdk_version);
==================================


I get the sdk version when I try to print core version( should've been 1.0.1 instead of 2.0.1)
==================================
{"COMPONENTS":{"Core_VERSION":"couchbase-java-client/2.0.1-SNAPSHOT (git: 2.0.0-23-g44e5e59) (Mac OS X/10.9.4 x86_64; Java HotSpot(TM) 64-Bit Server VM 1.8.0_05-b13)","SDK_VERSION":"couchbase-java-client/2.0.1-SNAPSHOT (git: 2.0.0-23-g44e5e59) (Mac OS X/10.9.4 x86_64; Java HotSpot(TM) 64-Bit Server VM 1.8.0_05-b13)"}
=================================

Anywhere I need to make the change?
Comment by Wei-Li Liu [ 22/Oct/14 ]
I extract the packaged jar and it contains both properties file

core.properties file version number has not been changed
======================
version information injected by the build
implementationVersion=@implVersion@
specificationVersion=@specVersion@
=====================

java.properties version number does change
===========================
#version information injected by the build
implementationVersion=2.0.0-23-g44e5e59
specificationVersion=2.0.1-SNAPSHOT
===========================

if I extract core-io jar I can see the correct version number
=========================
#version information injected by the build
implementationVersion=1.0.0-13-g410cf30
specificationVersion=1.0.1-SNAPSHOT
=========================

I did clean before I build.
build.xml to create the jar
https://gist.github.com/weilliu/24976cb18fea141643be
Comment by Simon Baslé [ 23/Oct/14 ]
as seen with wei-li, we cleaned-up sdkd build scripts

found out that depending on the method called to get version number (in sdkd's ControlServer), we get different result :
 - if calling userAgent(), both core and java sdk report that they are "couchbase-java-client/2.0.1..."
 - if calling packageNameAndVersion() instead, both core and java sdk report their versions correclty (respectively "couchbase-jvm-core/1.0.1..." and "couchbase-java-client/2.0.1..."

after investigation this is due to the fact that the USER_AGENT static variable initialized by DefaultCouchbaseEnvironment is the one of its parent, DefaultCoreEnvironment (thus making core and java share same user_agent).
Comment by Simon Baslé [ 24/Oct/14 ]
userAgent() returning same info on core classes and java sdk classes is on purpose, so that to the external world we always identify as a java sdk.

packageNameAndVersion() can be used to distinguish between core's version and sdk's version (but in production we should always know which version of the core ships with a java sdk version anyway).

Core version is always accessible on calling DefaultCoreEnvironment.PACKAGE_NAME_AND_VERSION (or the corresponding method on a DefaultCoreEnvironment instance, but this is discouraged when using java sdk as you probably already have a DefaultCouchbaseEnvironment).
Comment by Wei-Li Liu [ 24/Oct/14 ]
I have merged the fix.




Generated at Fri Oct 31 04:51:52 CDT 2014 using JIRA 5.2.4#845-sha1:c9f4cc41abe72fb236945343a1f485c2c844dac9.