CouchbaseMagic.java
|
Duplicate |
|||
| duplicates | JCBC-173 | flush will not work owing to MB-7381 | Open |
Impediment
[JCBC-278] ConnectionFactoryBuilder has wrong default settings Created: 02/Apr/13 Updated: 03/Apr/13 Resolved: 03/Apr/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.4 |
| Fix Version/s: | 1.1.5 |
| 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 | ||
| Description |
|
The Builder uses wrong failure mode and default hash, they differ from instantiating the factory directly. This causes inconsistencies and also EPT node failures not to be detected properly.
|
| Comments |
| Comment by Frank Weigel [ 03/Apr/13 ] |
| WIll changing hash affect customers upgrading? (i.e. not finding old data) |
[JCBC-261] Warmup Backoff breaks Memcache Buckets Created: 11/Mar/13 Updated: 12/Mar/13 Resolved: 12/Mar/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.3 |
| Fix Version/s: | 1.1.4 |
| Security Level: | Public |
| Type: | Bug | 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 | ||
| Description |
|
A recent change regarding warmup backoff breaks compat with memcache type buckets.
|
[JCBC-251] Observe ignores replica on index 0 Created: 24/Feb/13 Updated: 27/Feb/13 Resolved: 27/Feb/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.0, 1.1.1, 1.1.2 |
| Fix Version/s: | 1.1.3 |
| 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 | ||
| Description |
|
A replica on index 0 is not added to the broadcast observe list and therefore leads to timeouts when persistence constraints are provided.
|
[JCBC-245] Docs: Javadoc states that a java.lang.String is required for the value in a write operation, whereas online docs state object Created: 12/Feb/13 Updated: 27/Feb/13 Resolved: 27/Feb/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.2 |
| Fix Version/s: | 1.1.3 |
| Security Level: | Public |
| Type: | Bug | Priority: | Blocker |
| 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 |
|
Java docs here: http://www.couchbase.com/autodocs/couchbase-java-client-1.1.2/
All set/replace/add/cas operations state something like: cas(java.lang.String key, long cas, java.lang.String value, PersistTo req) Whereas the docs here: http://www.couchbase.com/docs/couchbase-sdk-java-1.1/api-reference-summary.html State that it's an "Object value" Looking deeper, it appears that the memcached methods inherited from spy use java.lang.object which leads to user confusion when trying to compare the two. |
| Comments |
| Comment by Perry Krug [ 12/Feb/13 ] |
| Adding a library component since the Java docs show what the required type is, and if we are limiting to strings, we are preventing people from using these methods with non-string objects without writing their own transcoder which seems a little arduous in the simpler cases. |
| Comment by Michael Nitschinger [ 19/Feb/13 ] |
| That's purely a lib bug, since those should also require Object instead of String. |
[JCBC-242] The flush() operations always fails with "401 Unathorized" message Created: 08/Feb/13 Updated: 08/Feb/13 Resolved: 08/Feb/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.2 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Balint Ureczky | Assignee: | Michael Nitschinger |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | 1m | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | 1m | ||
| Environment: |
uname -a
Linux Mint 3.2.0-35-generic #55-Ubuntu SMP Wed Dec 5 17:42:16 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux java -version java version "1.7.0_11" Java(TM) SE Runtime Environment (build 1.7.0_11-b21) Java HotSpot(TM) 64-Bit Server VM (build 23.6-b04, mixed mode) Java couchbase client library 1.1.2 taken from: http://files.couchbase.com/maven2/couchbase/couchbase-client/1.1.2/couchbase-client-1.1.2.jar |
||
| Attachments: |
CouchbaseMagic.java
|
||||||||
| Issue Links: |
|
||||||||
| Flagged: |
Impediment
|
||||||||
| Description |
|
The flush operations seems to require some kind of authorization, however the client library does not provide a way to do it.
The documentation is does not mention anything about this. Is there a magical way I can call flush? I attached the source code which reproduces the problem. |
| Comments |
| Comment by Michael Nitschinger [ 08/Feb/13 ] |
|
Note that this is a known limitation because of the CouchbaseServer
See the linked issue for more information! |
| Comment by Michael Nitschinger [ 08/Feb/13 ] |
| Note that this is marked to be fixed in 2.0.1 which is the next bugfix release of couchbase server. Once upgraded, it should "magically" work! |
[JCBC-219] Fix reconnect logic when server closes the socket. Created: 24/Jan/13 Updated: 29/Jan/13 Resolved: 29/Jan/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.0, 1.1.1 |
| Fix Version/s: | 1.1.2 |
| Security Level: | Public |
| Type: | Bug | 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 | ||
| Description |
|
When the server disconnects on us during a valid remove/failover rebalance, it is the case that the CouchbaseClient stays connected and doesnt try to disconnect and retry. This leaves the client in a dangerous state where no updates are fetched and therefore the map is incorrect.
|
| Comments |
| Comment by Michael Nitschinger [ 25/Jan/13 ] |
| http://review.couchbase.org/#/c/24182/ |
[JCBC-168] CouchClient.getView always throws an exception Created: 05/Dec/12 Updated: 11/Dec/12 Resolved: 11/Dec/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | 1.1-beta |
| Fix Version/s: | 1.1.0 |
| Security Level: | Public |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Chris Tashjian | Assignee: | Matt Ingenthron |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
It would seem that client.getView(String designdocName, String viewName) has stopped working in 1.1-beta. It now throws:
java.lang.RuntimeException: Timed out waiting for operation at com.couchbase.client.internal.HttpFuture.get(HttpFuture.java:66) at com.couchbase.client.CouchbaseClient.getView(CouchbaseClient.java:492) This was working fine in 1.1-dp4. |
| Comments |
| Comment by Michael Nitschinger [ 06/Dec/12 ] |
|
Hi Chris,
thanks for filing this. There has been a change that makes the ViewTimeout tunable, which I think may be the problem here. All my tests go through without problems, so I think you're using the FactoryBuilder right? Can you please give me your bootstrap code and all the timeouts you are using? Also, please check your boot logs if it says something about a low view timeout. Thanks! |
| Comment by Chris Tashjian [ 06/Dec/12 ] |
|
We're using the default ViewTimeout...
CouchbaseConnectionFactoryBuilder builder = new CouchbaseConnectionFactoryBuilder(); builder.setAuthDescriptor(new AuthDescriptor(new String[]{"PLAIN"}, new PlainCallbackHandler(bucketName, password))); builder.setOpTimeout(opTimeout); if (failureMode != null) { builder.setFailureMode(FailureMode.valueOf(failureMode)); } CouchbaseClient client = createClient(builder, uris); |
| Comment by Chris Tashjian [ 06/Dec/12 ] |
|
Ok, I think I was able to get this to work by adding "builder.setViewTimeout(5000);".
At one point I had it set to 3000 and got a timeout exception... however, if you don't explicitly call setViewTimeout, it seems that you get the less informative RuntimeException that I originally filed this for. It might be helpful if the constructor for CouchbaseConnectionFactoryBuilder set some kind of default timeout. |
| Comment by Matt Ingenthron [ 11/Dec/12 ] |
| http://review.couchbase.org/#/c/23189/ |
| Comment by Michael Nitschinger [ 11/Dec/12 ] |
| fixed and pushed to master! |
[JCBC-162] re-enable delete observe against 2.0 server Created: 03/Dec/12 Updated: 03/Dec/12 Resolved: 03/Dec/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | 1.1-dp3, 1.1-dp4 |
| Fix Version/s: | 1.1-beta |
| Security Level: | Public |
| Type: | New Feature | Priority: | Blocker |
| Reporter: | Matt Ingenthron | Assignee: | Matt Ingenthron |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
At one point, the observe delete had been disabled on the master branch owing to changes in approach and needing to get a change merged for delete. Once this is complete, we need to revert the change.
See the review for the remove here: http://review.couchbase.org/20918 |
| Comments |
| Comment by Michael Nitschinger [ 03/Dec/12 ] |
| implemented and pushed to master, will be available in beta. |
[JCBC-160] merge in changes from the release10 branch for 1.1beta Created: 03/Dec/12 Updated: 03/Dec/12 Resolved: 03/Dec/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | 1.1-dp4 |
| Fix Version/s: | 1.1-beta |
| Security Level: | Public |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Matt Ingenthron | Assignee: | Matt Ingenthron |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
In particular, the fix for |
| Comments |
| Comment by Michael Nitschinger [ 03/Dec/12 ] |
| merged, will be available in the beta release. |
[JCBC-158] add a debug=true option to view query options Created: 29/Nov/12 Updated: 03/Dec/12 Resolved: 03/Dec/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | 1.1-dp4 |
| Fix Version/s: | 1.1-beta |
| Security Level: | Public |
| Type: | New Feature | 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 |
|
To be able to diagnose issues that may come up with views, please add a debug=true query parameter. Optionally, we could add a cbclient.properties parameter to be able to turn on view debugging (for all view requests or just some that match a regex?) without code changes (though, with restarts).
|
| Comments |
| Comment by Michael Nitschinger [ 30/Nov/12 ] |
| http://review.couchbase.org/#/c/22923 |
| Comment by Michael Nitschinger [ 03/Dec/12 ] |
| pushed to master, will be available in the beta relase. |
[JCBC-154] merge in changes from the release11c branch Created: 26/Nov/12 Updated: 03/Dec/12 Resolved: 03/Dec/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | None |
| Fix Version/s: | 1.1-beta |
| Security Level: | Public |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Matt Ingenthron | Assignee: | Matt Ingenthron |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
When reviewing some changes on the "c" branch, I happened to notice there may be one change that hasn't been submodule merged
Upon further inspection, it looks like a few other changes haven't been merged either. We'll need to merge this branch back in. |
| Comments |
| Comment by Michael Nitschinger [ 29/Nov/12 ] |
| You already did the work, so assigning it to you. |
| Comment by Matt Ingenthron [ 03/Dec/12 ] |
| http://review.couchbase.org/#/c/22973/ |
| Comment by Michael Nitschinger [ 03/Dec/12 ] |
| merged into master, available in beta. |
[JCBC-153] Raise view timeout from 60s to 75s Created: 21/Nov/12 Updated: 03/Dec/12 Resolved: 27/Nov/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1-dp4 |
| Fix Version/s: | 1.1-beta |
| Security Level: | Public |
| Type: | Improvement | 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 |
|
Since the server side view timeout is 60s, we should raise the client side a bit higher. 75s seems like the right number. It should be tuneable though.
|
| Comments |
| Comment by Michael Nitschinger [ 22/Nov/12 ] |
| http://review.couchbase.org/#/c/22755/ |
| Comment by Michael Nitschinger [ 27/Nov/12 ] |
| Pushed to master, will be available in dp5/beta. |
[JCBC-150] "Failed to access the view" error when querying a view with reduce Created: 19/Nov/12 Updated: 27/Nov/12 Resolved: 27/Nov/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1-dp4 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Chris Tashjian | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Attempting to make a call to CouchbaseClient.query(view, query) with a view that has a reduce (even just "_count") results in the following exception when results are returned:
java.lang.RuntimeException: Failed to access the view at com.couchbase.client.CouchbaseClient.query(CouchbaseClient.java:634) Worth noting: - If the query returns no results (ViewResponse.size() returns 0), you do not get the exception... - If the reduce method is removed from the view, everything works fine. However, using query.setReduce(false) does not work. |
| Comments |
| Comment by Michael Nitschinger [ 20/Nov/12 ] |
|
Hi Chris,
thanks for the report. I'll investigate and let you know! Thanks, Michael |
| Comment by Michael Nitschinger [ 21/Nov/12 ] |
|
Please make sure to use setReduce(true) and .setReduce(false) explicitely on a view with a reduce function right now.
The following code works with setReduce(true) and false, but will throw the exception you mentioned when setReduce is not used at all: query = new Query(); //query.setReduce(false); view = client.getView(DESIGN_DOC_W_REDUCE, VIEW_NAME_W_REDUCE); reduce = client.query(view, query); itr = reduce.iterator(); while(itr.hasNext()) { ViewRow row = itr.next(); System.out.println(row.getKey()); } |
| Comment by Michael Nitschinger [ 21/Nov/12 ] |
|
After more investigation, this is really a shortcoming and should be handled in this changeset:
http://review.couchbase.org/#/c/22710/ It makes sure that reduce = true when nothing is set and the view contains a reduce function. The exception was misleading because it covered a JSON parsing bug underneath. |
| Comment by Michael Nitschinger [ 27/Nov/12 ] |
| fixed and pushed to master; will be available in dp5/beta. |
[JCBC-147] Rename getViews() to getDesignDocument() Created: 14/Nov/12 Updated: 03/Dec/12 Resolved: 03/Dec/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1-dp4 |
| Fix Version/s: | 1.1-beta |
| Security Level: | Public |
| Type: | Improvement | 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 | ||
| Issue Links: |
|
||||||||
| Flagged: |
Release Note
|
||||||||
| Description |
|
The getViews() method should be renamed to getDesignDocument() before the API is stable. This is also in preparation for the createDesignDocument() and deleteDesignDocument() additions.
|
| Comments |
| Comment by Michael Nitschinger [ 21/Nov/12 ] |
| http://review.couchbase.com/#/c/22713/ |
| Comment by Matt Ingenthron [ 03/Dec/12 ] |
| This breaks API over DP, and should be release noted. |
| Comment by Michael Nitschinger [ 03/Dec/12 ] |
| fixed and merged into master, will be available in beta! |
[JCBC-144] flush command needs to use RESTful flush for Couchbase Buckets Created: 11/Nov/12 Updated: 11/Dec/12 Resolved: 11/Dec/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | None |
| Fix Version/s: | 1.1.0 |
| Security Level: | Public |
| Type: | New Feature | Priority: | Blocker |
| Reporter: | Matt Ingenthron | Assignee: | Matt Ingenthron |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Flagged: |
Release Note
|
| Description |
|
The current flush command needs to be connected to the RESTful flush.
|
| Comments |
| Comment by Michael Nitschinger [ 12/Nov/12 ] |
|
To my findings there are two ways to implement this feature:
- Reuse the BucketManager for this, since it already provides basic capabilities for flushing (but needs some extension). - Reimplement the whole thing. I would go with extending the BucketManager for this, since it would also keep the CouchbaseClient itself lean. There is one thing that we need to decide upon: we can't just override the flush() method, because the returned value is different (we can't return an operation future with the current implementation). If we want to, we could "fake" it into one (but I doubt it makes sense). Therefore I propose a new method (flushBucket) which should be used with the couchbase client and we need to document that the old flush methods only work against memcached servers. |
| Comment by Michael Nitschinger [ 12/Nov/12 ] |
| Tracked here: http://review.couchbase.com/#/c/22445/ |
| Comment by Matt Ingenthron [ 03/Dec/12 ] |
| Pushing out to release 1.1.0, as it's secondary functionality. |
| Comment by Matt Ingenthron [ 07/Dec/12 ] |
| http://review.couchbase.org/#/c/22445/ |
[JCBC-110] observe method does not correctly check persistence or replication status on replica node/vbuckets Created: 12/Sep/12 Updated: 16/Sep/12 Resolved: 16/Sep/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | 1.1dp2 |
| Fix Version/s: | 1.1-dp3 |
| Security Level: | Public |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Matt Ingenthron | Assignee: | Mike Wiederhold |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
When performing some additional testing, Abhinav noticed some unusual behavior in interacting with clients. After checking with Mike a bit, they noticed that observe protocol were not going to replica node/vbuckets during the poll interval loop.
|
| Comments |
| Comment by Matt Ingenthron [ 12/Sep/12 ] |
| Assigning to Mike to update/replace the description. |
| Comment by Mike Wiederhold [ 16/Sep/12 ] |
|
http://review.couchbase.org/#/c/20847/ http://review.couchbase.org/#/c/20848/ http://review.couchbase.org/#/c/20849/ http://review.couchbase.org/#/c/20850/ http://review.couchbase.org/#/c/20851/ http://review.couchbase.org/#/c/20852/ |
[JCBC-70] Client fails to reconnect to server of non-default memcached bucket after failover and add back Created: 28/Jun/12 Updated: 30/Jan/13 Resolved: 30/Jan/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.0.3 |
| Fix Version/s: | 1.1.2 |
| Security Level: | Public |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Perry Krug | Assignee: | Michael Nitschinger |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | customer | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
sc_1_plabq11.dev.sabre.com.out.gz
|
||||||||||||||||
| Issue Links: |
|
||||||||||||||||
| Description |
|
In earlier tests with reconnecting to a node on failover we used default memcached bucket. But when we tested the same scenario with a non-default bucket, we noticed the client did not reconnect (due to a null pointer exception internally). I have attached the SDK logs for this scenario where we used "IndexByLniataData" memcached bucket. The problem presents when adding the node back after a failover.
11:34:43,411 DEBUG [Memcached IO over {MemcachedConnection to /10.14.5.119:11210}] [CouchbaseMemcachedConnection] Selecting with delay of 3038ms Exception in thread "Thread-3" java.lang.NullPointerException at net.spy.memcached.auth.AuthThread.buildOperation(AuthThread.java:117) at net.spy.memcached.auth.AuthThread.run(AuthThread.java:86) Logs/stack trace attached. |
| Comments |
| Comment by Matt Ingenthron [ 22/Aug/12 ] |
|
I've spent a bit of time analyzing this issue, and it's not clear what the cause is. It is correct though that this would cause the auth thread to die, and as such authentication to the node would never complete.
There is a safeguard already in that the continuous timeout threshold will kick in and then the connection will be rebuilt. I don't know if this issue comes up all of the time, but assuming it's a rare event we'd see 1000 operations timeout (by default) followed by the connection being rebuilt. We'd have to add some diagnostic information to the client and reliably reproduce this to identify the issue. I think the scenario is: 1) set up a cluster of say 3 nodes 2) configure a client, have it work with an authenticated memcached bucket on the cluster 3) faillover a node by clicking on "failover" in the console 4) add the node back by clicking on "add back" Is this correct? |
| Comment by Perry Krug [ 23/Aug/12 ] |
| That appears correct. The customer has been able to reliably reproduce this, but since so much time has passed I would be hesitant in going back to them if not necessary... |
| Comment by Matt Ingenthron [ 09/Jan/13 ] |
| There is an open changeset for this. Please determine if it is correct, needs to go in. |
| Comment by Michael Nitschinger [ 30/Jan/13 ] |
| Duplicate of Spy-111 |
[JCBC-63] add APIs for creating and deleting design documents for CBS 2.0 Created: 08/Jun/12 Updated: 29/Nov/12 Resolved: 29/Nov/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1dp |
| Fix Version/s: | 1.1-beta |
| Security Level: | Public |
| Type: | New Feature | Priority: | Blocker |
| Reporter: | Dipti Borkar | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
There are have been several requests from users to have APIs to create and delete views from the Java (and other) SDKs.
This is a MUST have for some customers and needs to be a part of the Client SDK we release prior to Beta. |
| Comments |
| Comment by Matt Ingenthron [ 08/Jun/12 ] |
| I'm in agreement. One question is do we also want this API to be involved in the view materialization process. I think the answer is probably yes, but this can be complicated since it can potentially take a very long time with little feedback. |
| Comment by Dipti Borkar [ 08/Jun/12 ] |
|
When you say View materialization process? what exactly do you mean? given that index building happens at query time, I don't think so.
However, there are other APIs that may be more interesting to have. explicitly triggering compaction, configuring min time duration / min # of mutations to trigger index building. |
| Comment by Matt Ingenthron [ 24/Jul/12 ] |
|
What I mean by the view materialization process is that we, in the web console, have this flow where we advise people to take their "dev_aview" and run a full cluster dataset query on it before publishing it to production. This way, when it's published as "aview", the view will have been mostly materialized. It's a nice thing for updating a view.
The reason this is complicated is that it's an HTTP request that may go for a very long, long time. I can think of a way around it (poll it with a timeout until it's fast), but it's suboptimal unless we start querying view materialization progress. |
| Comment by Michael Nitschinger [ 26/Aug/12 ] |
|
Matt, what if we wait for it in a separate thread and return with a future when it's done? We just need to make the user aware that it can take a long time, and if they add a view for development that they'd have to publish it separately.
Another idea would be to make the "let's do a full dataset query" optional when the view gets published since someone may want to do that later or from the web-ui. |
| Comment by Matt Ingenthron [ 26/Aug/12 ] |
|
Michael: that's effectively what we do right now since it's the query against the view that takes a long time. The design document management operations do not. The view requests are not quite done asynchronously, that's true.
The main point I was raising was that the Web Console provides for functionality to execute a view before pushing it in production and workflow to take it from "dev_thing" to "thing" knowing that the view has been materialized. In the SDK, I don't think we'll try to replicate that workflow, but the same functionality is definitely available. |
| Comment by Michael Nitschinger [ 05/Oct/12 ] |
| Just to keep everyone updated, I started developing it here: http://review.couchbase.org/#/c/21380/ |
| Comment by Michael Nitschinger [ 29/Nov/12 ] |
| this has finally been merged to master. |
[JCBC-47] Query.copy does not copy includeDocs property Created: 12/May/12 Updated: 01/Jun/12 Resolved: 01/Jun/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1dp |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Steven Cooke | Assignee: | Mike Wiederhold |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: | all java | ||
| Description |
|
Query.java line 200 in function copy():
setIncludeDocs(willIncludeDocs()); Should be query.setIncludeDocs(willIncludeDocs()); Paginated queries depend on copy() so paginatedQuery requiring the document fail with: java.lang.UnsupportedOperationException: This view result doesn't contain documents |
| Comments |
| Comment by Steven Cooke [ 12/May/12 ] |
|
Perhaps a better solution:
/** * All values in args map must be immutable */ private Query(Query src) { args = new HashMap<String, Object>(src.args); includedocs = src.willIncludeDocs(); } public Query copy() { return new Query(this); } |
[JCBC-40] paginatedQuery throws NoSuchElementException and NPE Created: 29/Apr/12 Updated: 03/Dec/12 Resolved: 27/Nov/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1dp |
| Fix Version/s: | 1.1-beta |
| Security Level: | Public |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Steven Cooke | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: | java | ||
| Description |
|
view iteration is incomplete and throws exceptions for
groovy code: paginator = client.paginatedQuery(view, query, n) while (paginator.hasNext()) { row = paginator.next() // Exception on this line ... } java.util.NoSuchElementException at java.util.LinkedList$ListItr.next(LinkedList.java:698) at com.couchbase.client.protocol.views.Paginator.next(Paginator.java:76) at com.couchbase.client.protocol.views.Paginator.next(Paginator.java:35) at java_util_Iterator$next.call(Unknown Source) AND java.lang.NullPointerException at com.couchbase.client.protocol.views.Paginator.getNextPage(Paginator.java:93) at com.couchbase.client.protocol.views.Paginator.hasNext(Paginator.java:67) at java_util_Iterator$hasNext.call(Unknown Source) Paginator also has a couple odd returns 1) next() can return null, but it should never return null unless lastRow is null. I don't think lastRow should ever be null. 2) getNextPage() has a return type, HttpFuture<ViewResponse>, but always returns null |
| Comments |
| Comment by Steven Cooke [ 15/May/12 ] |
|
some workarounds for NPE in getNextPage():
1) Check for a null ViewResponse in getNextPage and return the ViewResponse instead of a future or null. The hasNext method can then check the value of getNextPage returning false if there is no ViewResponse. 2) to bypass isJsonObject for numeric keys in Query.getArgs: boolean numericKey = (key.equals(STARTKEY) && value.toString().matches("\\d+")); // still not json number but catches most common case of positive integer keys if (key.equals(STARTKEYDOCID) || numericKey ) { return key + "=" + value; 3) Skip parameter needs to be zero for pages after the first. In Paginator: public boolean hasNext() { if (!pageItr.hasNext() && page.size() < docsPerPage) { return false; } else if (!(rowsIterated < docsPerPage)) { lastRow = pageItr.next(); query.setSkip(0); query.setStartkeyDocID(lastRow.getId()); query.setRangeStart(lastRow.getKey()); return (getNextPage(query) != null); } return true; } |
| Comment by Steven Cooke [ 15/May/12 ] |
| Note: #2 fails for numeric keys that are expected to be strings, an issue raised in SPY-62 |
| Comment by Raghavan Srinivas [ 16/Sep/12 ] |
|
I have revamped the paginator and the code to iterate over page and within page looks something like this.
while (result.hasNext()) { ViewResponse response = result.next(); for (ViewRow row: response) { System.out.println("Inner loop " + row.getId()); } System.out.println("<===Outer loop====>"); } |
| Comment by Matt Ingenthron [ 18/Sep/12 ] |
| http://review.couchbase.org/#/c/20898/ |
| Comment by Matt Ingenthron [ 18/Sep/12 ] |
| After discussion with Rags, there are some scenarios not as well tested as we'd like and there was some clarification on how this is expected to work. |
| Comment by Raghavan Srinivas [ 26/Sep/12 ] |
| This revolves around getKey() returning a string which is not the case always. It could return other types (such as int) and this will affect the way PaginatedQuery and other queries behave. |
| Comment by Matt Ingenthron [ 06/Oct/12 ] |
|
In an email, Steven Cooke commented:
A couple other things I noticed: The fix breaks all the original test cases as return type of next is no longer the same. If the API is intended to be non-breaking, the test cases and next should be reverted. The private method getNextPage has a return value that is never used. This looks fishy |
| Comment by Matt Ingenthron [ 06/Oct/12 ] |
|
This isn't intended to be API compatible actually. Rags and I talked through it and decided that the odd returns of nulls were odd. I don't know that the API you see here is final either.
We would appreciate any additional feedback on this API or how you think it should work. Once we hit beta, we'll keep the API stable. |
| Comment by Michael Nitschinger [ 14/Nov/12 ] |
| http://review.couchbase.org/#/c/22513/ |
| Comment by Michael Nitschinger [ 27/Nov/12 ] |
| Fixed and pushed to master. Will be available in dp5/beta. |
[JCBC-35] Exception during reconfiguring of client Created: 23/Apr/12 Updated: 26/Mar/13 Resolved: 26/Mar/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.0.2 |
| Fix Version/s: | 1.1-beta |
| Security Level: | Public |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Marcus Nylander | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
couchbase-client 1.0.2
java version "1.6.0_30" Java(TM) SE Runtime Environment (build 1.6.0_30-b12) Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode) Linux 2.6.18-238.19.1.el5 #1 SMP Sun Jul 10 08:43:41 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux |
||
| Attachments: |
log.txt
|
| Description |
|
Multiple different stackstraces below also see the following right before it starts to fail:
"Node exepcted to receive data is inactive. This could be due to afailure within the cluster. Will check for updated configuration. Key without a configured node is: akey12324234" Then it's fails a number of times and Failed to reconfigure client, staying with previous configuration. java.lang.IllegalArgumentException: TODO: refactor this at com.couchbase.client.vbucket.config.CacheConfig.getVbucketsCount(CacheConfig.java:55) at com.couchbase.client.vbucket.config.DefaultConfig.compareTo(DefaultConfig.java:145) at com.couchbase.client.vbucket.VBucketNodeLocator.updateLocator(VBucketNodeLocator.java:133) at com.couchbase.client.CouchbaseConnection.reconfigure(CouchbaseConnection.java:120) at com.couchbase.client.CouchbaseClient.reconfigure(CouchbaseClient.java:176) at com.couchbase.client.vbucket.ReconfigurableObserver.update(ReconfigurableObserver.java:54) at java.util.Observable.notifyObservers(Observable.java:142) at com.couchbase.client.vbucket.BucketMonitor.setBucket(BucketMonitor.java:257) at com.couchbase.client.vbucket.BucketMonitor.startMonitor(BucketMonitor.java:187) at com.couchbase.client.vbucket.ConfigurationProviderHTTP.subscribe(ConfigurationProviderHTTP.java:243) at com.couchbase.client.vbucket.ConfigurationProviderHTTP.finishResubscribe(ConfigurationProviderHTTP.java:215) at com.couchbase.client.CouchbaseConnectionFactory.checkConfigUpdate(CouchbaseConnectionFactory.java:182) at com.couchbase.client.CouchbaseConnection.addOperation(CouchbaseConnection.java:165) at net.spy.memcached.MemcachedConnection.enqueueOperation(MemcachedConnection.java:639) at net.spy.memcached.MemcachedClient.asyncGet(MemcachedClient.java:835) at net.spy.memcached.MemcachedClient.get(MemcachedClient.java:997) Failed to reconfigure client, staying with previous configuration. java.lang.IllegalArgumentException: TODO: refactor this at com.couchbase.client.vbucket.config.CacheConfig.getVbucketsCount(CacheConfig.java:55) at com.couchbase.client.vbucket.config.DefaultConfig.compareTo(DefaultConfig.java:145) at com.couchbase.client.vbucket.VBucketNodeLocator.updateLocator(VBucketNodeLocator.java:133) at com.couchbase.client.CouchbaseConnection.reconfigure(CouchbaseConnection.java:120) at com.couchbase.client.CouchbaseClient.reconfigure(CouchbaseClient.java:176) at com.couchbase.client.vbucket.ReconfigurableObserver.update(ReconfigurableObserver.java:54) at java.util.Observable.notifyObservers(Observable.java:142) at com.couchbase.client.vbucket.BucketMonitor.setBucket(BucketMonitor.java:257) at com.couchbase.client.vbucket.BucketMonitor.replaceConfig(BucketMonitor.java:307) at com.couchbase.client.vbucket.BucketUpdateResponseHandler.messageReceived(BucketUpdateResponseHandler.java:81) at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:80) at com.couchbase.client.vbucket.BucketUpdateResponseHandler.handleUpstream(BucketUpdateResponseHandler.java:194) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:545) at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:754) at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:302) at org.jboss.netty.handler.codec.replay.ReplayingDecoder.unfoldAndfireMessageReceived(ReplayingDecoder.java:513) at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:497) at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingDecoder.java:434) at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:80) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:545) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:540) at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:274) at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:261) at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:340) at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:272) at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:192) at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:46) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) |
| Comments |
| Comment by Matt Ingenthron [ 11/Oct/12 ] |
| This may have been fixed in configuraton changes in 1.0.3, but that should be verified. |
| Comment by Michael Nitschinger [ 28/Nov/12 ] |
| http://review.couchbase.org/#/c/22878/ |
| Comment by Michael Nitschinger [ 29/Nov/12 ] |
| fixed and pushed to master, will be available in in dp5/beta. |
| Comment by Michael Nitschinger [ 26/Mar/13 ] |
| Already fixes back in time, don't know why it is open. |
[JCBC-27] race condition during startup Created: 23/Mar/12 Updated: 04/Mar/13 Resolved: 04/Mar/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.0, 1.0.1, 1.1dp, 1.1.0 |
| Fix Version/s: | 1.1.3 |
| Security Level: | Public |
| Type: | Bug | 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 | ||
| Flagged: |
Release Note
|
| Description |
|
During startup, if there is no authentication (and thus no authentication latch) we can reply with errors before we get the configuration back and settled in with the node locator. This should be more reliable.
|
| Comments |
| Comment by Matt Ingenthron [ 23/Mar/12 ] |
| See http://www.couchbase.com/forums/thread/fast-computer-race-condition-java-client |
| Comment by Matt Ingenthron [ 29/Aug/12 ] |
| I think part of the solution on this is to poll the configuration until it transitions from warmup to healthy. |
| Comment by Matt Ingenthron [ 08/Oct/12 ] |
| The idea is that there is a section of the code that walks the URIs, finds the bucket, then after finding it sets up the stream for the configuration. When it first finds the bucket, if it's in a "warmup" state, (easy to simulate by restarting a server) it will show that it is and will not have a vbucket map. At that point, we should loop without setting up the stream *or* we should set up the stream and let anything handling reconfigure handle the transition from warmup to warmed up. |
| Comment by Michael Nitschinger [ 30/Nov/12 ] |
| http://review.couchbase.com/#/c/22933/1 |
| Comment by Matt Ingenthron [ 03/Dec/12 ] |
| Still working out the flow here. Based on our current understanding, this can be deferred to 1.1.0 or even post since it's an enhancement for reliable operation in a secondary or tertiary circumstance. Should be release noted though. |
| Comment by Matt Ingenthron [ 27/Feb/13 ] |
| Determined that the proposed approach is a good change, but better change is needed. That's tracked under JCBC-255. |
[JCBC-21] Move the view code into CouchbaseClient Created: 23/Jan/12 Updated: 21/Mar/12 Resolved: 21/Mar/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.1.0 |
| Security Level: | Public |
| Type: | Task | Priority: | Blocker |
| Reporter: | Mike Wiederhold | Assignee: | Mike Wiederhold |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
[JCBC-20] CouchbaseClient instances consume all CPU resources Created: 10/Nov/11 Updated: 29/Jun/12 Resolved: 29/Jun/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.1dp2 |
| Security Level: | Public |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Kurtis | Assignee: | Mike Wiederhold |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: | Win7, centOS 5.4, tomcat 6.x, java 1.6.x | ||
| Attachments: |
CouchbaseTest.zip
resource_usage.png
ViewConnection.java
|
| Description |
|
When creating one or more CouchbaseClient instances, each one appears to consume 100% of the available CPU resources per core, at least on machines I've tested.
Test case (eclipse project and ant build) included. Also included a snapshot of my system graph on my dev machine while running the included test. |
| Comments |
| Comment by Kurtis [ 10/Nov/11 ] |
|
Also relevant are, this issue at google code:
http://code.google.com/p/spymemcached/issues/detail?id=218 And this thread in the Couchbase forums: http://www.couchbase.org/forums/thread/using-couchbaseclient-connect |
| Comment by Matt Ingenthron [ 10/Nov/11 ] |
|
I've reproduced this issue.
After investigating it a bit, I've found that simplifying the test to use either MemcachedClient or MembaseClient doesn't demonstrate the same issue. Under both of those, CPU usage is modest. Further, more profiling seemed to show time on MacOS off in kqueue poll from the CouchbaseNode's run() method. I suspect there's a thread safety issue here causing badness. Asking Mike to review for any possible thread safety issues when there are multiple CouchbaseClients running. |
| Comment by Mike Wiederhold [ 30/Nov/11 ] |
| Were currently moving a few things around in the client. No user facing API changes, but still moving this around. I'll make sure to get this fixed as soon as possible though. |
| Comment by Alan Wood [ 04/May/12 ] |
|
I've put a possible fix as an attachment to this issue. It works for us, and doesn't block shutdown, other nodes, etc. The file was also submitted here (as an alternative to the ViewNode patch placed there earlier): http://www.couchbase.com/issues/browse/JCBC-26 |
| Comment by Steven Cooke [ 15/May/12 ] |
|
Is this still open? ViewConnection and CouchbaseConnection are both threads with tight run loops. The quick fix is to sleep(50) or so. Not sure what the real solution should be, but it seems any threaded connection to the server to get server state can be handled by a singleton.
e.g. public void run() { while(true) {} } vs public void run() { while (true) { sleep(50); // utility function to hide try/catch } } First will hose the CPU, second will not |
[JCBC-241] Paginator object doesn't move onto next "page" correctly Created: 07/Feb/13 Updated: 08/May/13 Resolved: 08/May/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.2 |
| Fix Version/s: | 1.1.6 |
| Security Level: | Public |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Perry Krug | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
paginator-java.diff
|
||||
| Issue Links: |
|
||||
| Description |
|
Customer found his own issue:
I had a look at the source code for the java driver and found the error there. It is in: com.couchbase.client.protocol.views.Paginator.getNextPage() Right after calculating the number of "remaining" keys, it sets the limit of the query to the remaining number of keys and re-runs the query. What is missing here is: q.setSkip(totalDocs); To actually start from the entry after the last entry on the current page. I have tried this and it works. But there is more code in this method and it is not very easy to follow so important to make sure that this fits. I am enclosing a diff. |
| Comments |
| Comment by Perry Krug [ 07/Feb/13 ] |
|
Update, but the bug still stands as described. It seems that my fix is not the correct one. The bug seem to be that although the Paginator specifies setStartkeyDocID, the query doesn't start from this key. I have debugged the Paginator class – and when resolving the next page it instructs the query to start from a specific doc id, e.g: Query: ?limit=50&startkey=144&skip=0&stale=false&startkey_docid=144 But as a result of this query I get: Got key: 1 Got key: 10 Got key: 100 Got key: 101 Got key: 102 Got key: 103 … Got key: 141 Got key: 142 Got key: 143 Every time. So the bug is in the Query context somewhere. Also – a note of inefficiency in the Paginator class: why perform two queries every time? One for the content of the "page" and one to find the row for the next page? Would be better to query for page + 1 and keep the last separate from the ViewResponse. So, what I can conclude is that when the Paginator bug is resolved it should work fine for us. The additional query for the last row could be an issue though, since it uses setSkip(). So could this be treated as a bug as well? |
[JCBC-272] removing non-bootstrap node with memcached bucket okay, but adding the same node results in failures Created: 13/Mar/13 Updated: 15/Mar/13 Resolved: 15/Mar/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.1.5 |
| Security Level: | Public |
| Type: | Bug | Priority: | Critical |
| Reporter: | Matt Ingenthron | Assignee: | Michael Nitschinger |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: | Client 1.1.2 with required spymemcached 2.8.11. Server 2.0.0 with a single authenticated memcached bucket. Assertions enabled. | ||
| Issue Links: |
|
||||||||
| Description |
|
From the attached log, one will see first the removal of a node (click remove -> click rebalance), and things are generally okay.
Following that, you'll see the node added (via the config wizard, joining to node 192.168.1.200), and one configuration received, but nothing actually used yet. Following that, you'll see the node rebalanced in with a set of assertion errors and then workload ceases. Notably: 2013-03-13 19:29:03.924 INFO com.couchbase.client.CouchbaseMemcachedConnection: Reconnecting {QA sa=/192.168.1.201:11210, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: 0 Opaque: 139891 Key: pool-25-thread-1:48454, topWop=null, toWrite=0, interested=1} Exception in thread "Memcached IO over {MemcachedConnection to /192.168.1.200:11210 /192.168.1.202:11210 /192.168.1.201:11210}" java.lang.AssertionError: Attempting to overwrite channel |
| Comments |
| Comment by Deepti Dawar [ 14/Mar/13 ] |
|
In this scenario, I am encountering something like this : [INFO 33.11 cbsdk.scenario failover.py:198] Sleeping for 60 seconds after failover [SDKD(WARNING) 33.12 cbsdk.sdkd.local executor.py:66] Mar 14, 2013 2:17:37 AM net.spy.memcached.MemcachedConnection handleIO [SDKD(WARNING) 33.12 cbsdk.sdkd.local executor.py:66] INFO: Reconnecting due to exception on {QA sa=/10.3.2.57:11210, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: 0 Opaque: 5552 Key: SimpleKey__REP_149, topWop=null, toWrite=0, interested=1} [SDKD(WARNING) 33.12 cbsdk.sdkd.local executor.py:66] java.io.IOException: Disconnected unexpected, will reconnect. [SDKD(WARNING) 33.12 cbsdk.sdkd.local executor.py:66] at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:526) [SDKD(WARNING) 33.12 cbsdk.sdkd.local executor.py:66] at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:454) [SDKD(WARNING) 33.12 cbsdk.sdkd.local executor.py:66] at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:247) [SDKD(WARNING) 33.12 cbsdk.sdkd.local executor.py:66] at com.couchbase.client.CouchbaseMemcachedConnection.run(CouchbaseMemcachedConnection.java:158) [SDKD(WARNING) 33.12 cbsdk.sdkd.local executor.py:66] Mar 14, 2013 2:17:37 AM net.spy.memcached.MemcachedConnection queueReconnect [SDKD(WARNING) 33.12 cbsdk.sdkd.local executor.py:66] WARNING: Closing, and reopening {QA sa=/10.3.2.57:11210, #Rops=1, #Wops=0, #iq=1, topRop=Cmd: 0 Opaque: 5552 Key: SimpleKey__REP_149, topWop=null, toWrite=0, interested=1}, attempt 0. [SDKD(WARNING) 33.12 cbsdk.sdkd.local executor.py:66] Mar 14, 2013 2:17:37 AM net.spy.memcached.protocol.TCPMemcachedNodeImpl setupResend [SDKD(WARNING) 33.13 cbsdk.sdkd.local executor.py:66] WARNING: Discarding partially completed op: Cmd: 0 Opaque: 5552 Key: SimpleKey__REP_149 [SDKD(WARNING) 33.13 cbsdk.sdkd.local executor.py:66] Mar 14, 2013 2:17:37 AM com.couchbase.sdkd.cbclient.CommandResult warnAbout [SDKD(WARNING) 33.13 cbsdk.sdkd.local executor.py:66] WARNING: Unknown exception encountered (for operation) future warnings will be suppressed [SDKD(WARNING) 33.13 cbsdk.sdkd.local executor.py:66] java.lang.RuntimeException: Cancelled [SDKD(WARNING) 33.13 cbsdk.sdkd.local executor.py:66] at net.spy.memcached.internal.OperationFuture.get(OperationFuture.java:169) [SDKD(WARNING) 33.13 cbsdk.sdkd.local executor.py:66] at net.spy.memcached.internal.OperationFuture.get(OperationFuture.java:132) [SDKD(WARNING) 33.13 cbsdk.sdkd.local executor.py:66] at com.couchbase.sdkd.cbclient.PendingCommand.onReady(PendingCommand.java:55) [SDKD(WARNING) 33.13 cbsdk.sdkd.local executor.py:66] at com.couchbase.sdkd.cbclient.OperationCollector.submitSync(OperationCollector.java:114) [SDKD(WARNING) 33.13 cbsdk.sdkd.local executor.py:66] at com.couchbase.sdkd.cbclient.OperationCollector.submit(OperationCollector.java:131) [SDKD(WARNING) 33.13 cbsdk.sdkd.local executor.py:66] at com.couchbase.sdkd.cbclient.GetCommandContext.doOneCommand(GetCommandContext.java:64) [SDKD(WARNING) 33.13 cbsdk.sdkd.local executor.py:66] at com.couchbase.sdkd.cbclient.CommandContext.execIter(CommandContext.java:276) [SDKD(WARNING) 33.13 cbsdk.sdkd.local executor.py:66] at com.couchbase.sdkd.cbclient.CommandContext.execute(CommandContext.java:311) [SDKD(WARNING) 33.13 cbsdk.sdkd.local executor.py:66] at com.couchbase.sdkd.server.SdkServer.executeCommand(SdkServer.java:135) [SDKD(WARNING) 33.13 cbsdk.sdkd.local executor.py:66] at com.couchbase.sdkd.server.SdkServer.handleRequest(SdkServer.java:156) [SDKD(WARNING) 33.13 cbsdk.sdkd.local executor.py:66] at com.couchbase.sdkd.server.SdkServer.run(SdkServer.java:212) [SDKD(WARNING) 33.16 cbsdk.sdkd.local executor.py:66] Mar 14, 2013 2:17:37 AM com.couchbase.client.CouchbaseMemcachedConnection reconfigure [SDKD(WARNING) 33.17 cbsdk.sdkd.local executor.py:66] INFO: Scheduling Node /10.3.2.57:11210for shutdown. |
[JCBC-271] Adding a node to an existing cluster causes issues with a running memcached bucket Created: 13/Mar/13 Updated: 16/Mar/13 Resolved: 16/Mar/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.2 |
| Fix Version/s: | 1.1.5 |
| Security Level: | Public |
| Type: | Bug | Priority: | Critical |
| Reporter: | Matt Ingenthron | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: | 3 node cluster of 2.0, one memcached bucket authenticated, Couchbase Java Client 1.1.2 with required spymemcached 2.8.11 | ||
| Attachments: |
CBSE-472repro.txt
|
||||||||||||
| Issue Links: |
|
||||||||||||
| Description |
|
When adding a node to a cluster, I'd observed a number of AssertionErrors and some very odd errors about connections being null.
This popped up when I wasn't expecting an issue, so I'm a bit surprised. The scenario I think is: Steps to reproduce: 1. Have two nodes running (.200 and .201 in my case here) 2. Add another node (.202 in my case here) See the logs for what detail is available. |
| Comments |
| Comment by Michael Nitschinger [ 15/Mar/13 ] |
| This is the same root cause, the channel gets overriden on add. |
| Comment by Michael Nitschinger [ 15/Mar/13 ] |
| http://review.couchbase.com/#/c/25171/ |
| Comment by Matt Ingenthron [ 16/Mar/13 ] |
| Yes, that fixed the issue. I had some issues on adding that node back, but there was a problem at the cluster side. |
[JCBC-230] View Connection only released when successful (not on failure) Created: 01/Feb/13 Updated: 06/Feb/13 Resolved: 06/Feb/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.0, 1.1.1 |
| Fix Version/s: | 1.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 | ||
| Description |
|
When a view operation is cancelled (timeout or else), the underlying connection for the ConnectionManager is not released and as a result no new view request can go over it.
|
| Comments |
| Comment by Michael Nitschinger [ 06/Feb/13 ] |
| https://github.com/couchbase/couchbase-java-client/commit/4b733eb37351aa62bab7c6d58d7f689f829ea704 |
[JCBC-227] client behaves poorly if entire URI list is not available Created: 31/Jan/13 Updated: 01/Feb/13 Resolved: 01/Feb/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.1 |
| Fix Version/s: | 1.1.2 |
| Security Level: | Public |
| Type: | Bug | Priority: | Critical |
| Reporter: | Matt Ingenthron | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Flagged: |
Release Note
|
| Description |
|
Currently, if the client has no valid URIs in it's list, it's reported that it will spin trying to connect nonstop. We should add a backoff if the entire list is traversed and unavailable. An exponential backoff (do-while style) with a ceiling and warning to a log is probably best.
|
| Comments |
| Comment by Michael Nitschinger [ 31/Jan/13 ] |
| http://review.couchbase.org/#/c/24322/ |
[JCBC-198] Using ReplicateTo.ONE after node-failover leads to index out of bounds Created: 28/Dec/12 Updated: 27/Feb/13 Resolved: 27/Feb/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.0 |
| Fix Version/s: | 1.1.3 |
| Security Level: | Public |
| Type: | Bug | Priority: | Critical |
| 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 |
|
using couchbase client library version 1.1.0, server version 2.0.0 community edition (build-1976-rel).
The cluster configuration remains same as in my initial email - three servers with "Enable Failover" property ON, a dedicated port "couchbase" bucket with 1 replica enabled. When stopping a server the client fails to communicate with the cluster with several errors. Client initializing - List<URI> serverList = parseConnectionProperties(port, hosts); CouchbaseConnectionFactory cf = new CouchbaseConnectionFactory(serverList, cacheName, ""); client = new CouchbaseClient(cf); Usage of the client to write data - public void put(final String key, final String value) { client.set(key, expirationSeconds, value, PersistTo.MASTER, ReplicateTo.ONE); } During the tests, when cluster is not available, I did a thread dump to the application , see the print below (ajp--127.0.0.1-8020-1@8796). Is it possible that node that is down is in some way a "master" of the data, and since the client.set() method uses PersistTo.MASTER parameter the things do not work? "ajp--127.0.0.1-8020-1@8796" daemon prio=5 tid=0x8c nid=NA waiting java.lang.Thread.State: WAITING at sun.misc.Unsafe.park(Unsafe.java:-1) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1033) at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1326) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:282) at com.couchbase.client.CouchbaseClient.observe(CouchbaseClient.java:1650) at com.couchbase.client.CouchbaseClient.observePoll(CouchbaseClient.java:1750) at com.couchbase.client.CouchbaseClient.set(CouchbaseClient.java:1199) at com.liveperson.liveEngage.cache.CouchbaseReadWriteCache.put(CouchbaseReadWriteCache.java:40) at com.liveperson.liveEngage.cache.CouchbaseReadWriteCache.put(CouchbaseReadWriteCache.java:17) at com.liveperson.liveEngage.cache.LEUsersCacheManager.setSessionDataCache(LEUsersCacheManager.java:121) at com.liveperson.liveEngage.ssoIdpLogin.LoginVerification.writeLoginDataToJbossCache(LoginVerification.java:246) at com.liveperson.liveEngage.ssoIdpLogin.LoginVerification.verifySsoLogin(LoginVerification.java:87) at com.liveperson.liveEngage.filters.AuthFilter.doFilter(AuthFilter.java:71) at com.liveperson.liveengage.authentication.filters.AuthenticationByProtocolFilter.doFilter(AuthenticationByProtocolFilter.java:71) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) at com.liveperson.liveEngage.filters.CommonFilter.doFilter(CommonFilter.java:35) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:125) at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:91) at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:88) at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:56) at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) at org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:490) at org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpAprProtocol.java:480) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2039) at java.lang.Thread.run(Thread.java:722) The errors i get during the test after a server was failed over - 17:45:41,911 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) [ERROR] [ajp--127.0.0.1-8020-4] Verify Sso Login failed. sessionId - n2b+0EZEzTaM7a64gKKS7k+L.undefined [com.liveperson.liveEngage.ssoIdpLogin.LoginVerification] 17:45:41,911 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) java.lang.RuntimeException: Timed out waiting for operation 17:45:41,912 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at net.spy.memcached.internal.OperationFuture.get(OperationFuture.java:134) 17:45:41,912 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.couchbase.client.CouchbaseClient.set(CouchbaseClient.java:1188) 17:45:41,912 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.liveperson.liveEngage.cache.CouchbaseReadWriteCache.put(CouchbaseReadWriteCache.java:40) 17:45:41,912 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.liveperson.liveEngage.cache.CouchbaseReadWriteCache.put(CouchbaseReadWriteCache.java:17) 17:45:41,912 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.liveperson.liveEngage.cache.LEUsersCacheManager.setSessionDataCache(LEUsersCacheManager.java:121) 17:45:41,912 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.liveperson.liveEngage.ssoIdpLogin.LoginVerification.writeLoginDataToJbossCache(LoginVerification.java:246) 17:45:41,913 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.liveperson.liveEngage.ssoIdpLogin.LoginVerification.verifySsoLogin(LoginVerification.java:87) 17:45:41,913 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.liveperson.liveEngage.filters.AuthFilter.doFilter(AuthFilter.java:71) 17:45:41,913 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.liveperson.liveengage.authentication.filters.AuthenticationByProtocolFilter.doFilter(AuthenticationByProtocolFilter.java:71) 17:45:41,913 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) 17:45:41,913 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) 17:45:41,914 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.liveperson.liveEngage.filters.CommonFilter.doFilter(CommonFilter.java:35) 17:45:41,914 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) 17:45:41,914 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) 17:45:41,914 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) 17:45:41,914 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) 17:45:41,914 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:125) 17:45:41,915 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:91) 17:45:41,915 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:88) 17:45:41,915 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:56) 17:45:41,915 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) 17:45:41,915 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) 17:45:41,916 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) 17:45:41,916 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) 17:45:41,916 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) 17:45:41,916 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:490) 17:45:41,916 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpAprProtocol.java:480) 17:45:41,916 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2039) 17:45:41,917 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at java.lang.Thread.run(Thread.java:722) 17:45:41,917 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) Caused by: net.spy.memcached.internal.CheckedOperationTimeoutException: Timed out waiting for operation - failing node: tlv-le-couchbase-int1.tlv.lpnet.com/192.168.24.184:11210 17:45:41,918 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at net.spy.memcached.internal.OperationFuture.get(OperationFuture.java:159) 17:45:41,918 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at net.spy.memcached.internal.OperationFuture.get(OperationFuture.java:132) 17:45:41,918 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) ... 28 more OR 19:21:47,997 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) [ERROR] [ajp--127.0.0.1-8020-3] Verify Sso Login failed. sessionId - 6tJElgOsTUcr-7lWgJlWh2HV.undefined [com.liveperson.liveEngage.ssoIdpLogin.LoginVerification] 19:21:47,997 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) java.lang.ArrayIndexOutOfBoundsException: -1 19:21:47,998 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at java.util.ArrayList.elementData(ArrayList.java:371) 19:21:47,998 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at java.util.ArrayList.get(ArrayList.java:384) 19:21:47,998 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.couchbase.client.vbucket.config.DefaultConfig.getServer(DefaultConfig.java:81) 19:21:47,998 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.couchbase.client.vbucket.VBucketNodeLocator.getServerByIndex(VBucketNodeLocator.java:112) 19:21:47,999 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.couchbase.client.CouchbaseClient.observe(CouchbaseClient.java:1621) 19:21:47,999 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.couchbase.client.CouchbaseClient.observePoll(CouchbaseClient.java:1750) 19:21:47,999 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.couchbase.client.CouchbaseClient.set(CouchbaseClient.java:1199) 19:21:47,999 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.liveperson.liveEngage.cache.CouchbaseReadWriteCache.put(CouchbaseReadWriteCache.java:40) 19:21:48,000 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.liveperson.liveEngage.cache.CouchbaseReadWriteCache.put(CouchbaseReadWriteCache.java:17) 19:21:48,000 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.liveperson.liveEngage.cache.LEUsersCacheManager.setSessionDataCache(LEUsersCacheManager.java:121) 19:21:48,000 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.liveperson.liveEngage.ssoIdpLogin.LoginVerification.writeLoginDataToJbossCache(LoginVerification.java:246) 19:21:48,001 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.liveperson.liveEngage.ssoIdpLogin.LoginVerification.verifySsoLogin(LoginVerification.java:87) 19:21:48,001 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.liveperson.liveEngage.filters.AuthFilter.doFilter(AuthFilter.java:71) 19:21:48,001 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.liveperson.liveengage.authentication.filters.AuthenticationByProtocolFilter.doFilter(AuthenticationByProtocolFilter.java:71) 19:21:48,002 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) 19:21:48,002 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) 19:21:48,002 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.liveperson.liveEngage.filters.CommonFilter.doFilter(CommonFilter.java:35) 19:21:48,002 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) 19:21:48,003 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) 19:21:48,003 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) 19:21:48,003 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) 19:21:48,003 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:125) 19:21:48,004 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:91) 19:21:48,004 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:88) 19:21:48,004 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:56) 19:21:48,004 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) 19:21:48,005 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) 19:21:48,005 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) 19:21:48,005 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) 19:21:48,005 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) 19:21:48,006 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:490) 19:21:48,006 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpAprProtocol.java:480) 19:21:48,006 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2039) 19:21:48,006 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at java.lang.Thread.run(Thread.java:722) Hopefully it's the same one, but just in case, here's another one: 17:41:34,231 ERROR [stderr] (Couchbase View Thread for node tlv-le-couchbase-int2.tlv.lpnet.com/192.168.24.185:8092) 2012-12-10 17:41:34.231 INFO com.couchbase.client.ViewNode: I/O reactor terminated for tlv-le-couchbase-int2.tlv.lpnet.com 17:42:23,120 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) [ERROR] [ajp--127.0.0.1-8020-2] Exception while trying to remove data from cache for session id: y6mpopojZkaJDcWeRDL4J0xp.undefined [org.apache.jsp.views.logout_jsp] 17:42:23,121 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) java.lang.IndexOutOfBoundsException: Index: 2, Size: 2 17:42:23,121 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at java.util.ArrayList.rangeCheck(ArrayList.java:604) 17:42:23,122 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at java.util.ArrayList.get(ArrayList.java:382) 17:42:23,122 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.couchbase.client.vbucket.config.DefaultConfig.getServer(DefaultConfig.java:81) 17:42:23,122 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.couchbase.client.vbucket.VBucketNodeLocator.getServerByIndex(VBucketNodeLocator.java:112) 17:42:23,123 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.couchbase.client.CouchbaseClient.observe(CouchbaseClient.java:1624) 17:42:23,123 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.couchbase.client.CouchbaseClient.observePoll(CouchbaseClient.java:1753) 17:42:23,124 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.couchbase.client.CouchbaseClient.delete(CouchbaseClient.java:1113) 17:42:23,124 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.liveperson.liveEngage.cache.CouchbaseReadWriteCache.remove(CouchbaseReadWriteCache.java:28) 17:42:23,124 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.liveperson.liveEngage.cache.CouchbaseReadWriteCache.remove(CouchbaseReadWriteCache.java:17) 17:42:23,125 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.liveperson.liveEngage.cache.LEUsersCacheManager.removeDataFromCache(LEUsersCacheManager.java:132) 17:42:23,125 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.jsp.views.logout_jsp._jspService(logout_jsp.java:82) 17:42:23,125 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) 17:42:23,126 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) 17:42:23,126 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:369) 17:42:23,126 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326) 17:42:23,127 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:253) 17:42:23,127 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) 17:42:23,127 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) 17:42:23,128 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) 17:42:23,128 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.liveperson.liveEngage.filters.ExceptionFilter.doFilter(ExceptionFilter.java:26) 17:42:23,128 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) 17:42:23,129 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) 17:42:23,129 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.liveperson.liveengage.authentication.filters.SSOAuthorizationFilterChain.doFilter(SSOAuthorizationFilterChain.java:30) 17:42:23,130 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.liveperson.liveEngage.filters.AuthFilter.doFilter(AuthFilter.java:65) 17:42:23,130 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.liveperson.liveengage.authentication.filters.AuthenticationByProtocolFilter.doFilter(AuthenticationByProtocolFilter.java:71) 17:42:23,130 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) 17:42:23,131 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) 17:42:23,131 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at com.liveperson.liveEngage.filters.CommonFilter.doFilter(CommonFilter.java:35) 17:42:23,132 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) 17:42:23,132 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) 17:42:23,133 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) 17:42:23,133 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) 17:42:23,133 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:125) 17:42:23,134 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:91) 17:42:23,134 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:88) 17:42:23,134 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:56) 17:42:23,135 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) 17:42:23,136 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) 17:42:23,136 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) 17:42:23,136 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) 17:42:23,137 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) 17:42:23,137 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:490) 17:42:23,137 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpAprProtocol.java:480) 17:42:23,138 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2039) 17:42:23,140 INFO [stdout] (AsyncAppender-Dispatcher-Thread-56) at java.lang.Thread.run(Thread.java:722) |
[JCBC-190] Allow ComplexKeys to work with Floats (not only Doubles) Created: 19/Dec/12 Updated: 18/Jan/13 Resolved: 18/Jan/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.0 |
| Fix Version/s: | 1.1.1 |
| 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 | ||
| Description |
|
See: http://www.couchbase.com/forums/thread/set-floating-point-key-couchbase-client-1-1-0-jar
|
| Comments |
| Comment by Michael Nitschinger [ 28/Dec/12 ] |
| http://review.couchbase.com/#/c/23605/ |
[JCBC-165] ComplexKey does not support partial compound keys with single field Created: 04/Dec/12 Updated: 06/Dec/12 Resolved: 06/Dec/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | 1.1-beta |
| Fix Version/s: | 1.1.0 |
| Security Level: | Public |
| Type: | Bug | Priority: | Critical |
| Reporter: | Chris Tashjian | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
I can't figure out how to do partial compound keys with a single value --
ex. 1 - Specifying both parts of the key: http://localhost:8092/bucketname/_design/mydesigndoc/_view/myview?group_level=1&startkey=["0",1351742400000]&endkey=["Z",1353073898844] ex. 2 - Only specifying the first part of the key: http://localhost:8092/bucketname/_design/mydesigndoc/_view/myview?group_level=1&startkey=["0"]&endkey=["Z"] I can get ex. 1 to work via the Java client library, but I've had no luck with ex. 2. I've tried setting ranges, complex keys and regular keys. The closest I get is a query string where the "[" and "]" have been escaped which results in a bad URL. I was only able to get this far by manually concatenating the "[" and "]" onto my key and using the query.setKey(String) method. I believe that ComplexKey should be able to handle ex 2 by calling ComplexKey.of("0") and ComplexKey.of("Z"). |
| Comments |
| Comment by Michael Nitschinger [ 04/Dec/12 ] |
| Correct, I came across it today as well. |
| Comment by Michael Nitschinger [ 05/Dec/12 ] |
| http://review.couchbase.org/#/c/23086/ |
| Comment by Michael Nitschinger [ 06/Dec/12 ] |
| you can now use the forceArray method on the ComplexKey to do this! .. will be available in 1.1.0. |
[JCBC-155] add javadoc for AbstractView, View, SpatialView Created: 27/Nov/12 Updated: 03/Dec/12 Resolved: 29/Nov/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | 1.1-dp4 |
| Fix Version/s: | 1.1-beta |
| Security Level: | Public |
| Type: | Improvement | Priority: | Critical |
| 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 |
|
When fixing up a test after a merge commit, I noted that I had to create a View object directly. In the process, I found that many of these classes are public, have public ctors, but have no javadoc. The client API takes AbstractView as an argument, so it may be tempting to just construct one. Is it correct to do so? Maybe. Javadoc doesn't tell me much.
The arguments to the ctors could also be expanded as they're a bit outside code style. Specifically, variable names should be meaningful and at least three or more characters if the variable is to be around for a while. |
| Comments |
| Comment by Michael Nitschinger [ 28/Nov/12 ] |
| http://review.couchbase.org/#/c/22872/ |
| Comment by Michael Nitschinger [ 29/Nov/12 ] |
| Pushed to master, will be available in dp5/beta. |
[JCBC-152] Document testing procedures for unit/functional tests Created: 21/Nov/12 Updated: 03/Dec/12 Resolved: 29/Nov/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1-dp4 |
| Fix Version/s: | 1.1-beta |
| Security Level: | Public |
| Type: | Improvement | Priority: | Critical |
| Reporter: | Mark Nunberg | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Description |
|
It would be good to have clear documentation in the repo about how to:
(1) run individual tests (2) change cluster parameters (3) write more tests This might be trivial or obvious to do, but very much needed. For an example of what should be available, see: (This does not say how to run individual tests though) https://github.com/couchbase/libcouchbase#run-the-testsuite-towards-a-running-cluster A more extensive example for a more complex test suite: https://github.com/couchbase/php-ext-couchbase/blob/master/TESTING.pod I'm marking this as a 'library' bug because this would require some detailed knowledge of how the tests are written :) |
| Comments |
| Comment by Michael Nitschinger [ 28/Nov/12 ] |
| http://review.couchbase.org/#/c/22874/ |
| Comment by Michael Nitschinger [ 29/Nov/12 ] |
| This has been fixed and is available under TESTING.md in the lib. |
[JCBC-148] Issue with Observe API Persist.TWO and 1 dead node: Time Out when doing set operation Created: 18/Nov/12 Updated: 03/Dec/12 Resolved: 03/Dec/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1-dp4 |
| Fix Version/s: | 1.1-beta |
| Security Level: | Public |
| Type: | Bug | Priority: | Critical |
| Reporter: | Tug Grall | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
2 nodes cluster on couchbase-server-community_x86_2.0.0-1947-rel
1 node on Ubuntu (VM) 1 node on OS X Bucket configure with 1 replica |
||
| Attachments: |
CouchbaseSamples.zip
|
| Description |
|
I have a very simple Java program that connect to the 2 nodes and do a set with the following code:
1. So I try to connect to multiple nodes {code} List<URI> couchbaseServerUris = new ArrayList<URI>(); couchbaseServerUris.add( new URI("http://192.168.0.108:8091/pools") ); couchbaseServerUris.add( new URI("http://192.168.0.104:8091/pools") ); CouchbaseClient client = new CouchbaseClient( couchbaseServerUris , "default" , "" ); {code} 2. Then I call the set operation {code} OperationFuture<Boolean> stored = client.set( "my-dummy-key",0, "{\"name\" : \"foo\", \"title\" : \"bar-test\"}", PersistTo.TWO); {code} --- So everything is working as expected when the 2 nodes are up. When I kill 1 node (for example : disconnecting, or stopping, or pausing the Ubuntu VM) I have the following behavior: When I execute this program: 1- I have an exception saying that 1 node is down : Expected behavior (even if we could avoid a long stack trace) {code} 2012-11-18 08:14:55.830 WARN com.couchbase.client.vbucket.ConfigurationProviderHTTP: Connection problems with URI http://192.168.0.108:8091/pools ...skipping java.net.ConnectException: Host is down {code} 2- When I do the set the program is stopped/blocked until it reaches a network timeout 2012-11-18 08:20:13.462 INFO com.couchbase.client.CouchbaseConnection: Shut down Couchbase client {code} Error while storing : Observe Timeout - Polled Unsuccessfully for at least 40 seconds. 2012-11-18 08:20:13.466 INFO done : true done : {OperationStatus success=false: Observe Timeout - Polled Unsuccessfully for at least 40 seconds.} com.couchbase.client.ViewNode: Couchbase I/O reactor terminated 2012-11-18 08:20:13.467 INFO com.couchbase.client.ViewNode: Couchbase I/O reactor terminated {code} Note that it is only happening with PersistTo.TWO if I use PersistTo.MASTER or PersistTo.ONE : the program is executed with no error and no stop if I use PersistTo.THREE ( or more) : the program is executed, no stop with the expected observe message : ( Error while storing : Requested persistence to 3 node(s), but only 2 are available. ) |
| Comments |
| Comment by Tug Grall [ 18/Nov/12 ] |
| Sample program |
| Comment by Matt Ingenthron [ 20/Nov/12 ] |
|
I do believe that's actually expected behavior, but let's talk through it to get your opinion.
We have a couple of options in the state of unexpected failure. one is we try our hardest to get the operation requested of us done and we rely on timeouts to keep from blocking forever. The second is that we keep tabs on our connections, and if the connection is down, we fail operations immediately so as to not have the application code waiting for something that may or may not succeed. Had you gone in and removed the second node (click 'remove' and 'rebalance'), then the client should have done something similar to when you requested three nodes. The failure you describe above is unexpected. Further, the client library doesn't really know if it's temporary or permanent. Finally, I do want to note, and I think this is well documented, that many things with Observe protocol under them end in timeouts. This is not the only one. Generally speaking, application code should be ready to do *something* in the case of a timeout. |
| Comment by Matt Ingenthron [ 20/Nov/12 ] |
| Tug explained this further. The PersistTo.THREE check must be happening after doing some operations, which is a bit late considering this operation can never succeed. The failure should be the same with a cluster that has a down node as it is with a cluster that just doesn't have a primary and to replica locations. |
| Comment by Mike Wiederhold [ 21/Nov/12 ] |
|
The way Rags wrote this code originally was to do the set and then the observe. The observe part is the part that does all of the checking so the set will actually go through an then you will get the error. Similarly there is no checking for downed nodes and I don't think we actually have the ability to do this at the moment, but I may be wrong.
On another note, one other thing I thing is wrong is returning an OperationFuture from all of the observe functions, but it isn't actually an asynchronous function. |
| Comment by Michael Nitschinger [ 30/Nov/12 ] |
| http://review.couchbase.org/#/c/22936/ |
| Comment by Michael Nitschinger [ 03/Dec/12 ] |
| fixed and will be available in the beta release. |
[JCBC-134] resubscriber IllegalArgumentException during topology changes Created: 19/Oct/12 Updated: 23/Jan/13 Resolved: 23/Jan/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.0, 1.1.1 |
| Fix Version/s: | 1.1.1 |
| Security Level: | Public |
| Type: | Bug | Priority: | Critical |
| Reporter: | Mark Nunberg | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Got this during a swap-rebalance. I don't have any other relevant information to reproduce for now (fwiw I've run this many times and it's the first time I'm seeing it.. though I've just seen it again on the very next run).
During the second run, the cluster rebalance is actually hanging.. |
||
| Attachments: |
daschl-4-rebealance_two_nodes.log
daschl-4-restart.log
junit.zip
log2.txt.bz2
log2.txt.bz2
|
||||
| Issue Links: |
|
||||
| Description |
|
Exception in thread "couchbase cluster resubscriber - running" java.lang.IllegalArgumentException: Bucket name cannot be null and must never be re-set to a new object.
at com.couchbase.client.vbucket.ConfigurationProviderHTTP.subscribe(ConfigurationProviderHTTP.java:240) at com.couchbase.client.vbucket.ConfigurationProviderHTTP.finishResubscribe(ConfigurationProviderHTTP.java:215) at com.couchbase.client.CouchbaseConnectionFactory$Resubscriber.run(CouchbaseConnectionFactory.java:322) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) Unfortunately I don't have a whole lot more insight into what's happening, but the stack trace might be helpful to examine.. assigning to myself until I have more info.. |
| Comments |
| Comment by Michael Nitschinger [ 08/Nov/12 ] |
|
Hi Mark,
can you elaborate a bit more whats going on through the test? This particular exception can come up when the java sdk tries to subcribe to a new node when the old connection is closed. I think the scenario should give us a connection to what is happening at runtime in the java sdk. Thanks, Michael |
| Comment by Mark Nunberg [ 12/Dec/12 ] |
| I've run the Java SDKD tests several times already and cannot reproduce this. Will re-open it if i see it again |
| Comment by Mark Nunberg [ 21/Jan/13 ] |
|
Seen again at: http://review.couchbase.org/#/c/24092/ |
| Comment by Mark Nunberg [ 21/Jan/13 ] |
| So as I mentioned in the bug, I closed it because I haven't seen this error. Just now, both me and Michael encountered this error while running the SDKD tests |
| Comment by Michael Nitschinger [ 22/Jan/13 ] |
|
Attaching the logs for http://review.couchbase.org/#/c/24092 changeset 4 (prefixed with daschl-4-) on some test runs.
Deepti is currently running the changeset against the brun cluster, expect some info in 2 hours. |
| Comment by Michael Nitschinger [ 22/Jan/13 ] |
| ./stester -i 20devcluster.ini --service ALL --svcaction RESTART --num_nodes 3 --no_fo 1 -c failover.Once --dsw_timeres 1 -d -o restart.log -C 127.0.0.1:8050 |
| Comment by Michael Nitschinger [ 22/Jan/13 ] |
| ./stester -i 20devcluster.ini -c rebalance.Once --mode out --rbcount 2 --dsw_timeres 1 -d -o rebealance_two_nodes.log -C 127.0.0.1:8050 |
| Comment by Deepti Dawar [ 22/Jan/13 ] |
|
Attaching the functional test results. This was run against a local 2.0.0 node. Pass rate is better this time - 92%. |
| Comment by Deepti Dawar [ 22/Jan/13 ] |
|
For the Hybrid tests - failures are still coming.
Attaching the intermittent log. |
| Comment by Deepti Dawar [ 22/Jan/13 ] |
|
The error that seems to be problematic in the unit test logs is this one -
'Timeout occurred. Please note the time in the report does not reflect the time until the timeout. junit.framework.AssertionFailedError: Timeout occurred. Please note the time in the report does not reflect the time until the timeout.' Most of the issues coming due to timeout. Note : that these tests were run against a local cluster. Hence, such problems should not be occurring. |
| Comment by Michael Nitschinger [ 23/Jan/13 ] |
| Merged in today, right before the 1.1.1 release. |
[JCBC-125] Don't cast view documents to strings Created: 03/Oct/12 Updated: 03/Dec/12 Resolved: 08/Nov/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1-dp4 |
| Fix Version/s: | 1.1-beta |
| Security Level: | Public |
| Type: | Bug | Priority: | Critical |
| Reporter: | Michael Nitschinger | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | view | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: | All | ||
| Description |
|
When objects are stored as non-strings in Couchbase and then loaded through a View, the SDK currently casts every document to a string. This works fine for JSON documents, but as soon as you want to store serialized objects it breaks.
Implicit casting is not needed in this place (see fix). |
| Comments |
| Comment by Michael Nitschinger [ 03/Oct/12 ] |
|
Here is a quick sample on how to reproduce it, but I'm adding a correct test case to the code as well (the view used is just the default "emit key and null" view with no reduce).
import com.couchbase.client.CouchbaseClient; import com.couchbase.client.CouchbaseConnectionFactory; import com.couchbase.client.protocol.views.Query; import com.couchbase.client.protocol.views.View; import com.couchbase.client.protocol.views.ViewResponse; import com.couchbase.client.protocol.views.ViewRow; import java.io.IOException; import java.net.URI; import java.util.Arrays; import java.util.Date; import java.util.Iterator; public class BinaryviewTest { /** * @param args the command line arguments */ public static void main(String[] args) throws IOException { // Initialize Connection CouchbaseClient cb = new CouchbaseClient( new CouchbaseConnectionFactory( Arrays.asList( URI.create("http://192.168.1.105:8091/pools") ), "default", "" ) ); // Store binary objects Object ob1 = new Date(); cb.set("date1", 0, ob1); Object result = cb.get("date1"); System.out.println(result.getClass()); Query query = new Query(); query.setIncludeDocs(true); View view = cb.getView("testing", "binary"); ViewResponse response = cb.query(view, query); Iterator<ViewRow> iterator = response.iterator(); ViewRow row; while(iterator.hasNext()) { row = iterator.next(); Object obj = row.getDocument(); System.out.println(obj.getClass()); } cb.shutdown(); } } When run two times, this raises the exception as described here: http://www.couchbase.com/forums/thread/couchbase-2-view-non-json-docs I'll update it when I have the fix and test ready. |
| Comment by Michael Nitschinger [ 03/Oct/12 ] |
| See http://review.couchbase.com/#/c/21305/ |
| Comment by Michael Nitschinger [ 08/Nov/12 ] |
| pushed to master, will be available in dp5. |
[JCBC-97] documentation needs a discussion on JSON mapping, getting started needs an example of using JSON Created: 10/Aug/12 Updated: 22/Aug/12 Resolved: 22/Aug/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | None |
| Fix Version/s: | 1.1dp2 |
| Security Level: | Public |
| Type: | Bug | Priority: | Critical |
| Reporter: | Matt Ingenthron | Assignee: | Raghavan Srinivas |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
At one point, I thought we had a discussion of JSON document usage in the getting started and on the web page. It's not there now, but we need to have a discussion about how a Java developer maps their high-level objects into JSON.
|
| Comments |
| Comment by Raghavan Srinivas [ 22/Aug/12 ] |
| There were a couple of issues. The document changes were reverted back. That's fixed. The Getting Started has been enhanced to persist some JSON documents. |
[JCBC-74] Implement observe command Created: 12/Jul/12 Updated: 22/Aug/12 Resolved: 22/Aug/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | None |
| Fix Version/s: | 1.1dp2 |
| Security Level: | Public |
| Type: | Improvement | Priority: | Critical |
| Reporter: | Matt Ingenthron | Assignee: | Raghavan Srinivas |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Add the basic low level observe command
|
| Comments |
| Comment by Raghavan Srinivas [ 22/Aug/12 ] |
| This is implemented in dp2 and will be enhanced post dp2. |
[JCBC-72] View query returns null Created: 05/Jul/12 Updated: 11/Jul/12 Resolved: 11/Jul/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1dp |
| Fix Version/s: | 1.1dp2 |
| Security Level: | Public |
| Type: | Bug | Priority: | Critical |
| Reporter: | Sharon Barr | Assignee: | Mike Wiederhold |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
viewResponse return null, and i can't figure out why:
• I execute my code CouchbaseClient c = new CouchbaseClient(baseURIs, "default", ""); View view = c.getView("dev_lenders", "country_count"); Query query = new Query(); Stale stale=Stale.OK; query.setStale(stale); query.setGroup(true); ViewResponse viewResponse = c.query(view, query); • My viewRespons is null. • Checking the couchdb.1 log, I see: [couchdb:info] [2012-07-04 21:40:50] [ns_1@127.0.0.1:<0.24865.33>:couch_log:info:39] 10.32.5.29 - - GET /default/_design/dev_lenders/_view/country_count?group=true&stale=ok 200 • Running this URL directly against my server I do get results: http://10.2.1.12:8092/default/_design/dev_lenders/_view/country_count?group=true&stale=ok {"rows":[ {"key":null,"value":4171}, {"key":"AE","value":5}, {"key":"AF","value":1}, {"key":"AM","value":2}, ... Not sure what logs i can provide to debug this further. let me know how i can help. |
| Comments |
| Comment by Sharon Barr [ 05/Jul/12 ] |
|
On slight variation from the above issue, i did mange to get an error from the server via the HTTP request
{"error":"query_parse_error","reason":"Invalid URL parameter 'group' or 'group_level' for non-reduce view."} but the client still returns null. |
| Comment by Mike Wiederhold [ 09/Jul/12 ] |
| http://review.couchbase.org/#change,18094 |
[JCBC-59] authentication not working correctly with CouchbaseConnectionFactoryBuilder Created: 04/Jun/12 Updated: 06/Aug/12 Resolved: 09/Jun/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | 1.0.2 |
| Fix Version/s: | 1.0.3 |
| Security Level: | Public |
| Type: | Bug | Priority: | Critical |
| Reporter: | Matt Ingenthron | Assignee: | Raghavan Srinivas |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
The use of the CouchbaseConnectionFactoryBuilder like so yields a client that does not authenticate correctly.
CouchbaseConnectionFactoryBuilder cfb = new CouchbaseConnectionFactoryBuilder(); CouchbaseConnectionFactory cf = cfb.buildCouchbaseConnection(servers, "default_jOWPgw", "default_jOWPgw", "testing"); CouchbaseClient client = new CouchbaseClient(cf); |
| Comments |
| Comment by Matt Ingenthron [ 04/Jun/12 ] |
| http://review.couchbase.org/#change,16765 |
[JCBC-22] Spring Support for CouchbaseClient Created: 26/Jul/11 Updated: 31/Jan/13 Resolved: 31/Jan/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | New Feature | Priority: | Critical |
| Reporter: | Mike Wiederhold | Assignee: | Michael Nitschinger |
| Resolution: | Won't Fix | Votes: | 4 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
We need to add support for the following Spring Integration Parts:
- General Info on how to use the Client with Spring Beans - Caching Support through @Cacheable annotations - Spring Data Support (yet to be defined). Current progress of the (yet unofficial support) can be tracked here: https://github.com/couchbaselabs/couchbase-spring |
| Comments |
| Comment by osk [ 19/Nov/12 ] |
| Need any help on this? |
| Comment by Michael Nitschinger [ 31/Jan/13 ] |
|
I'm going to close this ticket because it's not part of the couchbase client.
All ongoing efforts can be found here: https://github.com/couchbaselabs/spring-data-couchbase |
| Comment by Michael Nitschinger [ 31/Jan/13 ] |
| This is now part of a separate project. |
[JCBC-254] handle NOT_FOUND responses in observe() method for delete observe situations Created: 26/Feb/13 Updated: 27/Feb/13 Resolved: 27/Feb/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.2 |
| Fix Version/s: | 1.1.3 |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | James Mauss | 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 [ 27/Feb/13 ] |
| Michael, the patch set for this is up already. Please review it at your earliest convenience! |
[JCBC-253] Observe timing out when failing over Created: 26/Feb/13 Updated: 27/Feb/13 Resolved: 27/Feb/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.0, 1.1.1, 1.1.2 |
| Fix Version/s: | 1.1.3 |
| Security Level: | Public |
| Type: | Task | 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 | ||
| Description |
|
When using observe commands and a node is failed over and not rebalanced automatically, the code will time out because no broadcast will ever return but it expects one.
Proposed solution is to throw an exception to fail fast when there is no replica available. |
| Comments |
| Comment by Michael Nitschinger [ 26/Feb/13 ] |
| http://review.couchbase.org/#/c/24867 |
[JCBC-243] Docs: Reference installation Created: 11/Feb/13 Updated: 11/Feb/13 Resolved: 11/Feb/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | 1.1.2 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Perry Krug | Assignee: | Michael Nitschinger |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
Customers have lots of choices at their fingertips, and many of those choices will result in a non-functioning installation, or at least a lot of time spent figuring out what the right pieces are.
Can we please provide as much details as possible about a reference installation that we can be sure will work for a customer who is just getting started? This is outside of our support for any one operatin system, but more about telling the customer "if you install with these versions and packages, this code will work" -OS -"language" version (JDK 6, etc) -other packages/modules required and/or tested with |
| Comments |
| Comment by Michael Nitschinger [ 11/Feb/13 ] |
| I think this issue pretty much duplicates the essential guide tickets! |
[JCBC-236] Error handling documentation Created: 05/Feb/13 Updated: 06/Feb/13 Resolved: 06/Feb/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | 1.1.1 |
| Fix Version/s: | 1.1.3 |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Perry Krug | Assignee: | Michael Nitschinger |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
Please create some documentation specifying possible error/failures to operations, what they "look" like in the logs/exceptions/stack traces and what our recommendation is on how to handle them.
i.e. tmp_oom, timeouts (connection/operation/java-internal/etc), "get miss" (it's technically a failure, let's make it overly obvious what it means), CAS failure, add() failure, replace() failure, Some of this should be covered in the API reference, but this bug is specifically for a single page where this information is aggregated that a customer/user could read about how to handle errors. |
[JCBC-232] Javadoc jar files should be renamed to be compliant with IDEs Created: 04/Feb/13 Updated: 26/Mar/13 Resolved: 26/Mar/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | infrastructure |
| Affects Version/s: | 1.1.0, 1.1.1 |
| Fix Version/s: | 1.1.5 |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Tug Grall | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
IntelliJ Idea won't automatically download couchbase-client-*-javadocs.jar or spymemcached-*-javadocs.jar from http://files.couchbase.com/maven2/ because they have an "s" at the end of "javadoc".
I don't know whether any other IDE's have trouble with this, but the standard appears to be "XXX-javadoc.jar" instead of "XXX-javadocs.jar". The executable and source jars download fine. Can this be changed for a future version? See : http://www.couchbase.com/forums/thread/java-sdk-javadoc-maven-download-problem |
[JCBC-226] Delete's get() doesnt return the right value Created: 30/Jan/13 Updated: 27/Feb/13 Resolved: 27/Feb/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.0, 1.1.1 |
| Fix Version/s: | 1.1.3 |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Balint Ureczky | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Linux Mint Maya
Couchbase Server 2.0, 1956, 1976 Couchbase Client Java API 1.1.0, 1.1.1 |
||
| Attachments: |
CouchBaseTester.java
Output.txt
|
| Description |
|
Deleting is faulty, I asked for get() which should wait for the result, but every 5th returns with false, however the deletion has performed.
I have attached a sample code and the output result. |
| Comments |
| Comment by Balint Ureczky [ 31/Jan/13 ] |
|
I also tested on the 2.0.0 enterprise server (build-1976), which was the same.
The server returns with the error "Key was modified" as you can see in the attached output.txt |
| Comment by Michael Nitschinger [ 31/Jan/13 ] |
| To clarify, this error comes up when using the persistence constraints (persist, replicate) in combination. Just out of curiosity, can you try without them and see if it works as expected? Thanks |
| Comment by Balint Ureczky [ 31/Jan/13 ] |
|
Yes, with the default ReplicateTo.ZERO, PersistTo.ZERO settings, its 1000 times faster and there arent any failure in 100.000 tries. With ReplicateTo.ZERO, PersistTo.ONE settings, i got ~20 failure in 100 tries. |
| Comment by Michael Nitschinger [ 27/Feb/13 ] |
| This will be fixed in 1.1.3, we just pushed some changes that fixes this. |
[JCBC-224] Functional Integration tests failure tracking. Created: 29/Jan/13 Updated: 30/Jan/13 Resolved: 30/Jan/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.1 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Deepti Dawar | Assignee: | Michael Nitschinger |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Description |
|
I am raising this JCBC issue as a blocker for the SDKQE task.
The new observations that are coming everyday on the test runs would be updated here and if those are identified as major issues which could be fixed in the release 1.1.2, should be fixed as part of this task. I understand that we dont have a build ready now. But it would be good to track the issues and fix them as a preventive measure for the upcoming build. |
| Comments |
| Comment by Michael Nitschinger [ 30/Jan/13 ] |
|
Hi Deepti, sorry to say but I have to disagree with you here. Please open tickets as issues arise. It doesn't make sense to have a bug ticket around that doesn't contain an actual bug, and tracking more than one bug in a ticket is not good either. As a result, I'm closing this, feel free to create distinct issues when they come up with a descriptive title and a detailed description. thanks! |
[JCBC-223] Cannot use Persist.ONE/MASTER on a single node installation Created: 29/Jan/13 Updated: 31/Jan/13 Resolved: 30/Jan/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.0, 1.1.1 |
| Fix Version/s: | 1.1.2 |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Tug Grall | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: | Couchbase 2.0.0 Single node installation | ||
| Issue Links: |
|
||||||||
| Description |
|
Using the default bucket I am trying to use the simple "Durability" option using the following code:
---- { System.out.println("Set a Key-Value and Get the Key-Value"); OperationFuture op = cb.set("mytest", 0, "my value", PersistTo.MASTER); System.out.println("cb.get(\"mytest\")" + " => " + cb.get("mytest") + "\""); System.out.println(""); } ---- This raises the following exception: java.lang.ArrayIndexOutOfBoundsException: -1 at java.util.ArrayList.get(ArrayList.java:324) at com.couchbase.client.vbucket.config.DefaultConfig.getServer(DefaultConfig.java:81) at com.couchbase.client.vbucket.VBucketNodeLocator.getServerByIndex(VBucketNodeLocator.java:112) at com.couchbase.client.CouchbaseClient.observe(CouchbaseClient.java:1601) at com.couchbase.client.CouchbaseClient.observePoll(CouchbaseClient.java:1730) at com.couchbase.client.CouchbaseClient.set(CouchbaseClient.java:1179) at com.couchbase.client.CouchbaseClient.set(CouchbaseClient.java:1211) at com.couchbase.devday.Ex02Storage.main(Ex02Storage.java:36) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) I am using the code available at : https://github.com/couchbaselabs/DeveloperDay https://github.com/couchbaselabs/DeveloperDay/blob/master/Java/basic-operations/src/main/java/com/couchbase/devday/Ex08Observe.java (this example does not contain the PersistTo.ONE or MASTER since it does not work on a single node. but as you can see this is a very basic sample code |
| Comments |
| Comment by Michael Nitschinger [ 29/Jan/13 ] |
|
Note that this only happens on a one-node bucket when replica is enabled.
Looks like this then: {"hashAlgorithm":"CRC","numReplicas":1,"serverList":["127.0.0.1:11210"],"vBucketMap":[[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1]]}," and when no replica is defined there is no -1 replica of course. |
| Comment by Michael Nitschinger [ 29/Jan/13 ] |
| http://review.couchbase.org/#/c/24261 |
| Comment by Michael Nitschinger [ 30/Jan/13 ] |
| fixed. |
[JCBC-220] Spymemcached doesn't flush the queues correctly during bulk loads Created: 25/Jan/13 Updated: 28/Jan/13 Resolved: 25/Jan/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.1 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Muthu Kumar | Assignee: | Michael Nitschinger |
| Resolution: | Cannot Reproduce | Votes: | 0 |
| Labels: | 1.1.1, bulk, clients, issue, java, memcached, queueing, sets | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
2.0-couchbase.png
Couch1234.java
|
| Description |
|
CB:2.0
Library: 1.1.1 There is data loss in couchbase 2.0 when using the set command and the couchbase bucket . Loss seem to be severe the longer away the servers are from the client. Same java client works well with memcached buckets in 2.0, and both couchbase and memcached buckets in 1.8.1. See screenshots below. Note the item count in the couchbase bucket which is missing 24% of the data. Attached Image for the total items stored in the couchbase bucket. Only 750K items stored for 1M inserts. On bulk loads using the 1.1.1 library, the customer is seeing data loss for the items that have been set. The customer tried to set 1M items using the latest Java Client 1.1.1 and figured out that all the items are getting persisted. An update from the customer....... I have rewritten it a bit and reproduced the problem here. Find the updated version enclosed where you can see the issue being reproduced. You will see that the number of keys reported by couchbase is not the number of keys that we have inserted. It seems that the problem is in the handling of queueing the set calls internally in the driver. I.e, if we don't actively force the "async" queues to flush (by calling the future get()), data on the queues could be discarded. So this sounds like a spymemcached bug where it does not correctly flush the queues during high loads? According to the javadoc we should have seen the below, and if not, we should have assumed that all operations were properly processed? java.lang.IllegalStateException - in the rare circumstance where queue is too full to accept any more requests Attache code using which we were able to reproduce this error on bulk loads. |
| Comments |
| Comment by Muthu Kumar [ 25/Jan/13 ] |
|
The customer is also interested to know as below.
Just a side note - could it be that the: net.spy.memcached.DefaultConnectionFactory# createOperationQueue need to be configured differently? From what I can see spymemcached provides two different operation queues, and it seems that it should either block the add of the async call or just let the queue keep growing (array versus linked queue). Looking forward to engineering response. |
| Comment by Muthu Kumar [ 25/Jan/13 ] |
| No Michael - Can I close this and raise a CBSE ? |
| Comment by Michael Nitschinger [ 25/Jan/13 ] |
| Yes please! |
| Comment by Matt Ingenthron [ 25/Jan/13 ] |
|
I'm sorry to say, the test is wrong. The client's shutdown method is never called, and that would allow the IO thread to complete work before shutting down. The get() method on the OperationFuture never does flush a queue. You're just killing the IO thread with a System.exit(0) from the main thread before the IO thread gets to complete its work. |
| Comment by Muthu Kumar [ 28/Jan/13 ] |
| Thanks Michael and Matt - I have updated the ticket with your comments and will raise a CBSE if the customer comes back with an issue. |
| Comment by Muthu Kumar [ 28/Jan/13 ] |
| Raised this http://www.couchbase.com/issues/browse/CBSE-366 |
[JCBC-218] CLONE - Client constructor blocks or deadlocks Created: 23/Jan/13 Updated: 27/Feb/13 Resolved: 27/Feb/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.0.2 |
| Fix Version/s: | 1.1.3 |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | sean diamond | Assignee: | Michael Nitschinger |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
OS: Windows 7 64bit
JDK: 1.6.0_31 also 1.6.0_33 64 bit Couchbase enterprise edition running on 3 nodes all Ubuntu 10.04 64bit server (VMware images) |
||
| Description |
|
I am evaluating the couchbase product and hit a brick wall immediately when running through the simple hello world example.
I have a 3 node cluster running couchbase enterprise 1.8.2 on ubuntu 10.04 64 bit VMware images. All three are running in VMWare player instances on Windows 7 64bit. When I try to run the Main example on Windows 7 using Java6 (64 bit) the code blocks somewhere in the Client constructor. The result is the logging below. 2012-06-14 14:07:46.313 INFO com.couchbase.client.CouchbaseConnection: Added {QA sa=/192.168.186.150:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue 2012-06-14 14:07:46.316 INFO com.couchbase.client.CouchbaseConnection: Added {QA sa=/192.168.186.151:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue 2012-06-14 14:07:46.319 INFO com.couchbase.client.CouchbaseConnection: Added {QA sa=/192.168.186.152:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue 2012-06-14 14:07:59.843 INFO com.couchbase.client.CouchbaseConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@24a4e2e3 2012-06-14 14:08:52.983 INFO com.couchbase.client.CouchbaseConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@21ec6696 2012-06-14 14:08:52.987 INFO com.couchbase.client.CouchbaseConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@27431340 I have also tried debugging but the code blocks in the constructor at client = new CouchbaseClient(uris, "default", ""); The program never completes. This works fine in a Linux environment with the following output received 2012-06-14 04:58:50.693 INFO com.couchbase.client.CouchbaseConnection: Added {QA sa=/192.168.186.150:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue 2012-06-14 04:58:50.703 INFO com.couchbase.client.CouchbaseConnection: Added {QA sa=/192.168.186.151:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue 2012-06-14 04:58:50.708 INFO com.couchbase.client.CouchbaseConnection: Added {QA sa=/192.168.186.152:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue 2012-06-14 04:58:50.830 INFO com.couchbase.client.CouchbaseConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@1bc74f37 2012-06-14 04:58:50.834 INFO com.couchbase.client.CouchbaseConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@3a21b220 2012-06-14 04:58:50.843 INFO com.couchbase.client.CouchbaseConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@732b3d53 2012-06-14 04:58:51.135 INFO com.couchbase.client.CouchbaseConnection: Shut down Couchbase client Set Succeeded Synchronous Get failed Asynchronous Get Succeeded: Hello World! Is there a JDK for windows 7 or a configuration setting that can be used to prevent this? |
| Comments |
| Comment by sean diamond [ 23/Jan/13 ] |
|
I am having this exact same issue with couchbase 2.0 community edition, and the latest java client 1.1
Only workaround is to not use the client on windows. If i connect to couchbase via linux with the same setup it works fine. Deadlocking on windows during the constructor. |
| Comment by Matt Ingenthron [ 23/Jan/13 ] |
| Can you confirm you see this with 1.1.1? We just released it in the last 12 hours, and there was a fix in the ctor area. |
| Comment by sean diamond [ 23/Jan/13 ] |
|
just updated to client version 1.1.1 and it has the same problem.
|
| Comment by Michael Nitschinger [ 31/Jan/13 ] |
| moving to 1.1.2 for more investigation. |
| Comment by sean diamond [ 26/Feb/13 ] |
|
I was able to figure out was was going on and fortunately it doesn't look like this is due to the couchbase client!
I am using avast antivirus which is appearing to forward the port. Resolution can be found here in this post for a similar issue someone was having due to port forwarding. Similar to this post here http://forum.avast.com/index.php?topic=95134.0 I am assuming the original poster of this issue is also using some kind of antivirus that may be messing with the port couchbase is trying to connect on. Thanks for looking into this anyway. |
| Comment by Michael Nitschinger [ 27/Feb/13 ] |
| Ok so I'm closing this. Thanks for updating us! |
[JCBC-216] buildinfo class is not packaged properly Created: 18/Jan/13 Updated: 18/Jan/13 Resolved: 18/Jan/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | 1.0.2, 1.0.3, 1.1.0 |
| Fix Version/s: | 1.1.1 |
| Security Level: | Public |
| Type: | Bug | 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 | ||
| Description |
|
The buildinfo class should be getting packaged properly.
$ java -jar build/jars/couchbase-client-1.1.0.jar Exception in thread "main" java.lang.NoClassDefFoundError: com/couchbase/client/BuildInfo Caused by: java.lang.ClassNotFoundException: com.couchbase.client.BuildInfo at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) $ jar -tvf build/jars/couchbase-client-1.1.0.jar | grep BuildInfo |
| Comments |
| Comment by Michael Nitschinger [ 18/Jan/13 ] |
| http://review.couchbase.org/#/c/24048/ |
| Comment by Michael Nitschinger [ 18/Jan/13 ] |
|
michael@daschlbook ~/couchbase/couchbase-java-client $ java -jar build/jars/couchbase-client-1.1.0.jar
Couchbase Java Client 1.1.0 Tree Version: 1.1.0-13-g584a1f7 Last Commit ID: 584a1f70953bcd90d120a0ef500d1eb9f791e582 Compiled by michael@daschlbook.local on Fri Jan 18 09:33:37 CET 2013 |
[JCBC-215] Refactor viewmode property loading Created: 18/Jan/13 Updated: 18/Jan/13 Resolved: 18/Jan/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.0 |
| Fix Version/s: | 1.1.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 | ||
| Description |
|
After having the CouchbaseProperties class in place as a centralized repository for both system and file-based properties, the "viewmode" should also use this code.
|
| Comments |
| Comment by Michael Nitschinger [ 18/Jan/13 ] |
| http://review.couchbase.com/#/c/24011/ |
[JCBC-214] client does not failover properly when bootstrap node fails in a soft way Created: 17/Jan/13 Updated: 18/Jan/13 Resolved: 18/Jan/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | 1.0.2, 1.0.3, 1.1.0 |
| Fix Version/s: | 1.1.1 |
| Security Level: | Public |
| Type: | Bug | 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 | ||
| Description |
|
If a given server just stops responding to TCP on both 8091 and 11210 (which can be simulated with a pkill -STOP), the client does not detect this failure mode and never recovers.
|
| Comments |
| Comment by Michael Nitschinger [ 17/Jan/13 ] |
| http://review.couchbase.com/#/c/24019/ |
[JCBC-212] Add new throttling feature to allow us to keep from using all system memory Created: 15/Jan/13 Updated: 18/Jan/13 Resolved: 18/Jan/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.1.1 |
| Security Level: | Public |
| Type: | New Feature | Priority: | Major |
| Reporter: | Matt Ingenthron | Assignee: | Matt Ingenthron |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
When doing things like bulk loading, there are times we have multiple workload profiles. Interactive applications using the same client and same server need "room to move" and should always be fast, while other workloads should throttle themselves.
The intent here would be to add a feature such that: for every N operations, pull stats from the nodes if the amount of memory used is below high_wat, don't do anything else if the amount of memory used is 10% of the remaining memory above high_wat before max memory usage, insert a sleep of Y milliseconds before each operation, and log the backoff at a debug level, check stats again ever M operations else if the amount of memory used is greater than 10% above that level above high_wat, insert a sleep of Z milliseconds before each operation and log the backoff at an info level, check stats again every O operations Turning this on or off should be done via a properties file or just simple -D args to the JVM, either one is okay. N, M, O and Y, Z should all be tuneable, either via a properties file or a define. All of them should be optional. Default values should be: N = 10000 M = N/100 O = M/10 Y = 1ms Z = Y * 3 |
| Comments |
| Comment by Michael Nitschinger [ 17/Jan/13 ] |
| http://review.couchbase.com/#/c/23658/ |
[JCBC-211] Refactor property management into a centralized class. Created: 15/Jan/13 Updated: 31/Jan/13 Resolved: 31/Jan/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.0 |
| Fix Version/s: | 1.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 | ||
| Flagged: |
Release Note
|
| Comments |
| Comment by Michael Nitschinger [ 31/Jan/13 ] |
| Fixed and merged into master. |
[JCBC-210] Throw CancellationException instead of RuntimeException on op cancel Created: 14/Jan/13 Updated: 21/Feb/13 Resolved: 21/Feb/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.0 |
| Fix Version/s: | 1.1.3 |
| 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 | ||
| Description |
|
This is only a semantical change because CancellationExceptions are children of RuntimeExceptions, but it should give us better debugabillity in production deployments and those Exceptions can be better caught.
|
| Comments |
| Comment by Michael Nitschinger [ 15/Jan/13 ] |
| Also, document these in the manual and in the docblocks where it makes sense. |
| Comment by Michael Nitschinger [ 21/Feb/13 ] |
| Pushed to master, will be available in 1.1.3 |
[JCBC-191] DOC: missing reference to "maven repository" in the tutorial Created: 19/Dec/12 Updated: 19/Dec/12 Resolved: 19/Dec/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | 1.1.0 |
| Fix Version/s: | 1.1.1 |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Tug Grall | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
The following page of the tutorial : ( 2.1.1. Project Setup )
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/preps-project.html show some information of the POM file, we need to be sure we also include the repository in all the docs: we need to add this: <repositories> <repository> <id>couchbase</id> <name>Couchbase Maven Repository</name> <layout>default</layout> <url>http://files.couchbase.com/maven2/</url> <snapshots> <enabled>false</enabled> </snapshots> </repository> </repositories> This is what it done here: http://www.couchbase.com/docs/couchbase-sdk-java-1.1/downloading.html |
| Comments |
| Comment by Michael Nitschinger [ 19/Dec/12 ] |
| PR submitted to the docs repo, will be in there asap. |
[JCBC-192] DOC : Downloading page mention the 1.1 BETA Created: 19/Dec/12 Updated: 19/Dec/12 Resolved: 19/Dec/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | 1.1.0 |
| Fix Version/s: | 1.1.1 |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Tug Grall | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
The page: Downloading fo the Java SDK
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/downloading.html mentions couchbase-client-1.1-beta.jar it should be couchbase-client-1.1.0.jar |
| Comments |
| Comment by Michael Nitschinger [ 19/Dec/12 ] |
| Also in the docs repo pull req, fixed asap. |
[JCBC-188] Tutorial quickstart Created: 17/Dec/12 Updated: 06/Feb/13 Resolved: 06/Feb/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | None |
| Fix Version/s: | 1.1.3 |
| Security Level: | Public |
| Type: | Improvement | 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 |
|
I think it worth to add quickstart section in the java tutorial to help people first quickly start the application and then experimenting while reading the rest of the tutorial. I've wrote and Michael merged already README file describing how to do it. Would be nice if some parts of it will be published in the tutorial: https://github.com/couchbaselabs/beersample-java/blob/master/README.markdown
I left an output of the terminal commands, because they will show what people should expect |
| Comments |
| Comment by Michael Nitschinger [ 06/Feb/13 ] |
| In review on docs repo, soon in master. |
[JCBC-186] there is no CouchbaseCacheManager in 1.1.0, but in the API reference Created: 15/Dec/12 Updated: 17/Dec/12 Resolved: 17/Dec/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | 1.1.0 |
| Fix Version/s: | 1.1.1 |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Matt Ingenthron | Assignee: | MC Brown |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
There is no CouchbaseCacheManager in the 1.1.0 SDK, but it seems to be in the API reference. Something like this is being worked on soon.
See http://www.couchbase.com/forums/thread/which-jar-couchbasecachemanager |
| Comments |
| Comment by Michael Nitschinger [ 17/Dec/12 ] |
|
Hi MC,
there is a pull request on the docs open that should remove this since it's out of date. I'm working on new stuff regarding this, but until its finished we need to remove this since it confuses people. Just merge the docs pull request, then this can be closed. Thanks! |
| Comment by MC Brown [ 17/Dec/12 ] |
| The merge has been published. |
[JCBC-185] autodocs don't have links to spymemcached methods (i.e., most of the API) Created: 14/Dec/12 Updated: 07/Jan/13 Resolved: 07/Jan/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | 1.1.0 |
| Fix Version/s: | 1.1.1 |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Tim Smith | Assignee: | MC Brown |
| 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-1.1.0/ | ||
| Description |
|
It's great to have the generated docs for the Java client available on the website. However, it is confusing for a lot of people because most of the API methods aren't documented there, they are inherited from spymemcached and the docs don't link to spymemcached classes.
If it is technically possible, it would be great to have live links in the autodocs for all the methods, including spymemcached ones. If not, it would be good to have a disambiguation page or some kind of explanation that, to get a complete view of the api docs, one must read both the spymemcached and couchbase docs. And a link to http://www.couchbase.com/autodocs/java/spymemcached/2.8.3/index.html (or whatever the latest link is). |
| Comments |
| Comment by Michael Nitschinger [ 17/Dec/12 ] |
|
MC, is it possible to do this? I also think this would greatly benefit the clarity of the docs, but can you merge two codebases (spy and couchbase-client) into one autodoc, or can we at least provide both that link each-other? Thanks, Michael |
| Comment by MC Brown [ 17/Dec/12 ] |
|
It is possible, but requires some changes to the way to I currently build the Javadoc content. I'll get this fixed.
Longer term, the intention is for the content to be incorporated into the API reference material in the main documentation as a unified reference. |
| Comment by MC Brown [ 07/Jan/13 ] |
| Fixed. The autodoc builds of the Couchbase client now include the spymemcached as a unified reference document. |
[JCBC-178] Java Client's Manual 1.1 Created: 11/Dec/12 Updated: 06/Feb/13 Resolved: 06/Feb/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | 1.1-beta |
| Fix Version/s: | 1.1.3 |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Deepti Dawar | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Following are the review comments :
1) Chapter 11. Line - 'The other alternative is create a logging.properties and add it to your in your classpath:' 2) Chapter 8. --> Table 8.1 --> line 2 --> Append a value to an existing key with custom transcoder. Also, incr and decr operation descriptions are the same for the three overloaded methods. 3) There is no mention of ViewConnection class and the methods like createViewConnection in the chapter 10 on Views and Queries. 4) The version of couchbase-client jar that is shown in the snap shots in the document is 1.1-dp2 and not 1.1-dp4. 5) Also, there is no mention of the helper classes for eg. BucketTool and their functionalities. 6) Chapter 6 --> section 6.2 should mention about Add with Observe like section 6.3 is about set with observe. 7) Couchbase client also has the methods observe and observePoll which have not been described in the manual. 8) Appendix A3 - mentions about the addition of delete and observe functionality on the server build 1553 and above, but the manual doesn't have a section on delete with observe in section 8.4. 9) Chapter 7. Table 7.1 - client.getAndLock(key [, getl-expiry ], transcoder) method is not hyperlinked. 10) Chapter 7. - only one 'unlock' method is defined, however in the API, there are two overloaded methods. 11) The getDesignDocument method is not defined in any chapter inside the manual. 12) Spatial Views and map reduce views are not defined in Chapter 10. Also the API methods to fetch the spatial views/paginator query have not been elaborated. 13) Chapter 9. - getKeyStats method is not defined. 14) Chapter 5, table 5.1 - string 'client.new' should be replaced with 'new'. 15) Chapter 4, Table 4.1 - Three add operations are not hyper-linked. 16) Section 4.3, Line - 'You can also use a custom transcoder the serialization of objects. This can be to serialize objects in a format that is com- patible with other languages or environments.' needs revision. 17) Instead of Query.new(), it should be new Query(). 18) Chapter 5 - Connection Operations need to be elaborated in more detail. Other that CouchbaseClient, there are other classes which act as the helper classes for building the client to server connection. |
| Comments |
| Comment by Michael Nitschinger [ 06/Feb/13 ] |
| In review on docs repo, soon in master. |
[JCBC-176] Using BucketTool helper - error in connection to the server, bucket creation, deletion. Created: 09/Dec/12 Updated: 31/Jan/13 Resolved: 31/Jan/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1-beta |
| Fix Version/s: | 1.1.2 |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Deepti Dawar | Assignee: | Michael Nitschinger |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
log.txt
|
||||||||||||||||
| Issue Links: |
|
||||||||||||||||
| Description |
|
BucketTool is not behaving properly to create default bucket and connect to the server.
Error received while running CouchbaseClientTest using the initClient method which is overridden - java.lang.RuntimeException: Http Error: 401 Reason: Unauthorized Details: No reason given at com.couchbase.client.ClusterManager.checkError(ClusterManager.java:300) at com.couchbase.client.ClusterManager.listBuckets(ClusterManager.java:186) at com.couchbase.client.BucketTool$1.callback(BucketTool.java:73) at com.couchbase.client.BucketTool.poll(BucketTool.java:108) at com.couchbase.client.BucketTool.deleteAllBuckets(BucketTool.java:84) at com.couchbase.client.CouchbaseClientTest.initClient(CouchbaseClientTest.java:60) at net.spy.memcached.ClientBaseCase.setUp(ClientBaseCase.java:72) at junit.framework.TestCase.runBare(TestCase.java:132) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83) 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) |
| Comments |
| Comment by Deepti Dawar [ 10/Dec/12 ] |
|
Attaching the log extracted from the 'ant test' run. The error is different but the same test is still failing. Not able to run CouchbaseClientTest. |
| Comment by Michael Nitschinger [ 19/Dec/12 ] |
| Is this still an issue for you? |
| Comment by Deepti Dawar [ 20/Dec/12 ] |
|
The problem still exists for the remote VMs. If I run the same test on the local server, then it passes.
I am linking this issue to the JCBC-189. |
| Comment by Deepti Dawar [ 20/Dec/12 ] |
| The resolution for these two issues should be similar as there is still a timeout issue that is appearing for the remotely hosted server. |
| Comment by Michael Nitschinger [ 31/Jan/13 ] |
| This is addressed in http://www.couchbase.com/issues/browse/JCBC-225 |
[JCBC-175] Small typo in Exception message "Node exepcted to receive data is inactive" Created: 08/Dec/12 Updated: 11/Dec/12 Resolved: 11/Dec/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.1.0 |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Tug Grall | Assignee: | Tug Grall |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | 1h | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | 1h | ||
| Description |
|
Fix typo in "Node exepcted to receive data is inactive ..."
|
| Comments |
| Comment by Michael Nitschinger [ 11/Dec/12 ] |
| Fixed, thanks |
[JCBC-167] ComplexKey converts longs to strings Created: 05/Dec/12 Updated: 17/Dec/12 Resolved: 17/Dec/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | 1.1-beta |
| Fix Version/s: | 1.1.0 |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Chris Tashjian | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
I previously added this as a comment on Query q1 = new Query(); long time1 = 0; long time2 = 99999999; long time3 = 99999999999l; q1.setRangeStart(ComplexKey.of(time1)); q1.setRangeEnd(ComplexKey.of(time2)); q1.toString() --> ?startkey=0&endkey=99999999 q1.setRangeStart(ComplexKey.of(time1)); q1.setRangeEnd(ComplexKey.of(time3)); q1.toString()) --> ?startkey=0&endkey=%2299999999999%22 It's throwing quotes around the long value. |
| Comments |
| Comment by Chris Tashjian [ 05/Dec/12 ] |
| long time3 = 99999999999l; //note that's 99999999999L; |
| Comment by Michael Nitschinger [ 11/Dec/12 ] |
| http://review.couchbase.com/#/c/23194/ |
| Comment by Michael Nitschinger [ 17/Dec/12 ] |
| This has been fixed with 1.1.0. |
[JCBC-159] 1.0.4 in release notes but not available for d/l Created: 30/Nov/12 Updated: 31/Jan/13 Resolved: 05/Dec/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | None |
| Fix Version/s: | 1.1.0 |
| Security Level: | Public |
| Type: | Bug | 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 |
|
Not sure if this is really a docs bug, but we need to address the inconsistency between what is avialable for d/l and the latest release notes.
|
| Comments |
| Comment by Matt Ingenthron [ 03/Dec/12 ] |
| Do you mean that release notes are published for 1.0.4, but there is no such release? I think that's for TechPubs. |
| Comment by Matt Ingenthron [ 03/Dec/12 ] |
| There seem to be 1.0.4 release notes, but no release. |
| Comment by MC Brown [ 03/Dec/12 ] |
|
Given that TechPubs don't write the release notes, or have visibility into what individual versions of the SDKs are actually released, I'm not quite sure how we would know that these weren't correct.
If the items that were fixed in what is marked as 1.0.4 were fixed in a different release, they need to be marked up as such. I've commented out the 1.0.4 release so it wont be published, but the entries must either be deleted or assigned to the correct version number. |
| Comment by Matt Ingenthron [ 03/Dec/12 ] |
|
MC: Thanks for the temporary removal. Michael: Can you see where these 1.0.4 release notes should be and fix them up appropriately? |
| Comment by Michael Nitschinger [ 05/Dec/12 ] |
|
I checked it and there were only two open, which both are related to this: http://www.couchbase.com/issues/browse/SPY-102 (which is open).
So I removed the release completely and both tickets, because nothing was actually fixed in there for the versions. This will go in there with the 1.1 GA release notes as well, so I'm going to close this here. |
| Comment by Michael Nitschinger [ 05/Dec/12 ] |
| fixed with the 1.1.0 release notes. |
[JCBC-157] Unsure if CouchbaseConnectionFactory.pastReconnThreshold really does what it's suppose to do Created: 28/Nov/12 Updated: 03/Dec/12 Resolved: 03/Dec/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.0.3 |
| Fix Version/s: | 1.1-beta |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Marcus Nylander | Assignee: | Matt Ingenthron |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: | Oracle Jdk 1.6.0_26 | ||
| Description |
|
{code}
private boolean pastReconnThreshold() { long currentTime = System.nanoTime(); if (currentTime - thresholdLastCheck > 100000000) { //if longer than 10 sec configThresholdCount = 0; // it's been more than 10 sec since last // tried, so don't try again just yet. } configThresholdCount++; thresholdLastCheck = currentTime; if (configThresholdCount >= maxConfigCheck) { return true; } return false; } {code} Does the above really work as expected? It looks strange. 100000000 in nanos is only 100 millis and not 10 seconds as stated in comments. If there is more than 100 millis between calls we always reset configThresholdCount and will never return true, which seems very strange. |
| Comments |
| Comment by Michael Nitschinger [ 28/Nov/12 ] |
| can you take a look at this? |
| Comment by Michael Nitschinger [ 29/Nov/12 ] |
| http://review.couchbase.org/#/c/22902/ |
| Comment by Marcus Nylander [ 29/Nov/12 ] |
|
Checking the fix. Not that I've looked deeply into what pastReconnThreshold() should do, but just increasing the timeout?
Isn't it more like it should return true every maxConfigCheck calls or return true if last call was more than 10 seconds ago? |
| Comment by Michael Nitschinger [ 03/Dec/12 ] |
| fixed and pushed to master, will be available in beta. |
[JCBC-156] several javadoc warnings emitted Created: 27/Nov/12 Updated: 03/Dec/12 Resolved: 28/Nov/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | 1.1-beta |
| Fix Version/s: | 1.1-beta |
| Security Level: | Public |
| Type: | Improvement | 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 | ||
| Description |
|
During build of javadoc:
[javadoc] /Users/ingenthr/src/couchbase-java-client/src/main/java/com/couchbase/client/ClusterManager.java:128: warning - @param argument "memorySize" is not a parameter name. [javadoc] /Users/ingenthr/src/couchbase-java-client/src/main/java/com/couchbase/client/ClusterManager.java:143: warning - @param argument "memorySize" is not a parameter name. [javadoc] /Users/ingenthr/src/couchbase-java-client/src/main/java/com/couchbase/client/ClusterManager.java:143: warning - @param argument "password" is not a parameter name. [javadoc] /Users/ingenthr/src/couchbase-java-client/src/main/java/com/couchbase/client/ClusterManager.java:158: warning - @param argument "memorySize" is not a parameter name. [javadoc] /Users/ingenthr/src/couchbase-java-client/src/main/java/com/couchbase/client/ViewConnection.java:199: warning - @return tag has no arguments. |
| Comments |
| Comment by Michael Nitschinger [ 28/Nov/12 ] |
| http://review.couchbase.org/#/c/22877/ |
| Comment by Michael Nitschinger [ 28/Nov/12 ] |
| Fixed, will be available in beta/dp5 |
[JCBC-145] Add the maven XML snippet to the getting started guide (both web page and docs) Created: 12/Nov/12 Updated: 13/Nov/12 Resolved: 13/Nov/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.1.0 |
| Security Level: | Public |
| Type: | Improvement | 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 | ||
| Description |
|
Our current maven documentation is limited to telling people what the repo URL is. This often isn't enough, and they need the groupId and artifactId. Best would be to describe it similar to:
http://code.google.com/p/spymemcached/wiki/Maven |
| Comments |
| Comment by Michael Nitschinger [ 13/Nov/12 ] |
| Merged and will be available in the next minutes at http://www.couchbase.com/docs/couchbase-sdk-java-1.1/downloading.html |
[JCBC-143] Prepend should not require CAS Created: 08/Nov/12 Updated: 21/Dec/12 Resolved: 21/Dec/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | 1.0.3 |
| Fix Version/s: | 1.1.1 |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Perry Krug | Assignee: | Michael Nitschinger |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
Hopefully this is just a doc bug and not in the actual code, but all of the atomic updates including prepend (http://www.couchbase.com/docs/couchbase-sdk-java-1.0/couchbase-sdk-java-update-prepend.html) should not require CAS. That significantly defeats their performance effectiveness.
If the function *does* require CAS, we should document that a CAS id of 0 will override the requirement to get the key again as in this example: client.prepend(casv.getCas(),"samplekey", "prependedstring"); |
| Comments |
| Comment by Michael Nitschinger [ 09/Nov/12 ] |
|
This is not a doc bug, both prepend and append require CAS values.
So is this still a doc enhancement or should we consider enhancing the library? |
| Comment by Perry Krug [ 10/Nov/12 ] |
| I think a simple doc enhancement to inform the user that they can replace the actual CAS call with a 0 to avoid the second round-trip to the server. There are a few situations where CAS would be appropriate for these ops, so it doesn't make sense to remove it from the library, but the most common case is to use them as atomic operations and therefore not need CAS...so the doc update should just make that clearer. Please make sure to note it on the various other atomic ops (incr/dev/append/touch/) |
| Comment by Michael Nitschinger [ 21/Dec/12 ] |
| This is a duplicate for JCBC-196, see the process over there. |
[JCBC-139] 'delete & persist' and' delete, persist and replicate' functionalities not supported in 1.1-dp3 SDK. Created: 07/Nov/12 Updated: 14/Nov/12 Resolved: 14/Nov/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | 1.1-dp3 |
| Fix Version/s: | 1.1-beta |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Deepti Dawar | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
couchbase-sdk-java-1.0 Manual has presented the usage specific to the 'delete & persist' and' delete, persist and replicate' functionalities but the SDK API's dont support this functionality due to an ongoing defect in the the couchbase server. Similar issue is there with the 'set and persist' and 'set and replicate' functionalities.
The manual needs to be updated accordingly. |
| Comments |
| Comment by Deepti Dawar [ 07/Nov/12 ] |
|
The Github link for reference, depicting this change is as follows -
https://github.com/couchbase/couchbase-java-client/commit/f5603e21c7cbf94d4804e01688c1160375dae418 |
| Comment by Michael Nitschinger [ 14/Nov/12 ] |
| Pulled into the main repo by the docs team, will be available in a few minutes in the official docs. |
[JCBC-141] Graceful Shutdown Test fails on dp4 Created: 07/Nov/12 Updated: 03/Dec/12 Resolved: 08/Nov/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1-dp4 |
| Fix Version/s: | 1.1-beta |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Michael Nitschinger | Assignee: | Michael Nitschinger |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
The gracefulShutdown test on the CouchbaseClient fails.
More inspection needed before we hit a stable release! |
| Comments |
| Comment by Michael Nitschinger [ 08/Nov/12 ] |
| I quickly re-checked and it works on master. Instead, some of the observe tests fail for which I'll reopen a new JCBC ticket. |
[JCBC-137] During the failure Java client cannot do any operations Created: 01/Nov/12 Updated: 04/Nov/12 Resolved: 04/Nov/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Pavel Paulau | Assignee: | Matt Ingenthron |
| Resolution: | Cannot Reproduce | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
We simulated the split-brain by blocking all network traffic on one node for a minute. We used iptables with DROP target.
During the failure the client cannot do any operations. During this minute the console doesn't even say that any node is down. Is this a correct behavior? Can client work with a part of the cluster? I see the client has some possible failure modes: http://www.couchbase.com/autodocs/java/spymemcached/2.8.3/index.html?net/spy/memcached/FailureMode.html Which is the best to allow client to be functional while one node of the cluster is down? I cannot chose from this API docs short description :( Tried all three options for FailureMode. Always the same behavior: client cannot do any requests. |
| Comments |
| Comment by Matt Ingenthron [ 02/Nov/12 ] |
|
Was this with spymemcached directly? If so, was it using moxi, or taught the binary ports and auth?
What was the workload? |
| Comment by Denis Nelubin [ 02/Nov/12 ] |
|
We're using YCSB. And this client: https://github.com/couchbaselabs/YCSB/blob/master/src/couchbase-1.8/src/main/java/com/yahoo/ycsb/couchbase/CouchbaseClient1_8.java
The issue doesn't relate to any workload. For example, it happens with YCSB's workload A (50% reads, 50% updates). We installed the couchbase-server-community_x86_64_1.8.1.deb downloaded from here: http://www.couchbase.com/download It runs moxi processed on the nodes. Does the client connects to them? I don't know. The client configuration is: couchbase.hosts=r1.local,r2.local,r3.local,r4.local couchbase.bucket=test couchbase.user= couchbase.password= couchbase.opTimeout=60000 #couchbase.failureMode=... tried any couchbase.checkOperationStatus=true |
| Comment by Matt Ingenthron [ 02/Nov/12 ] |
|
My suspicion here is that the the client can do operations, but it appears that all workload stops because all threads are blocking/waiting on a down node. You'd have to look at how YCSB works to determine if that's the case though.
Take for example, if you have nodes A, B, C, D. Then assume your workload is randomly reading or writing a key. Depending on how the key hashes, it'd go to one of the four nodes. If this random read/write is in a loop, it'd generate a good amount of traffic. Then assume node C fails, so now we have A, B, (C), D. Assuming that loop is waiting until a response comes back from the server, all of the threads will quickly end up blocking and retrying on C, as designed. After a failover is initiated, everything should go back to normal. This is different than split brain. Split brain would be nodes A & B can see each other and nodes C & D can see each other. The client may see either or both groups. If I understand it correctly, all you did was simulate node failure with the firewall. |
| Comment by Denis Nelubin [ 04/Nov/12 ] |
|
Ok.
You're saying that each of my (32) threads comes (in random order) to the unfunctional server and this transaction hangs (and, actually, fails with timeout errors later). This thread block makes transactions to other functional servers impossible. Sounds reasonable. But theoretically, because I have 1 replica copy, it's possible to do the transaction over the copy of data. This requires some intelligence on client side, to route the requests to another server. Is there a fair way to get such functionality with Couchbase? Run client side moxi? What do you recommend? |
| Comment by Matt Ingenthron [ 04/Nov/12 ] |
|
At the moment, the answer is no. There is a feature we're looking to add, casually called "replica read" which would allow application code to try reading data from a replica in the event the primary location is unavailable, but it's not complete yet. It wouldn't do anything to help with data mutations though.
It's worth noting that for any distributed database, this is a design decision. It's not just a function of the client library. In the case of Couchbase Server, we've chosen to focus on making primary key access to data consistent. We alleviate the availability concern by making sure we can failover quickly (it's nearly instantaneous) and doing what we can within reason to make autofailover part of the cluster (autofailover can be set up for as low as a 30s period). We believe that's the right model for the DB to back a webapp. There are times when you can increase availability at the cost of consistency, but it means the code you write has to be much more defensive. We trade off momentary availability for consistency. I'm not sure of your goals, but I don't think running YCSB with a failed node in a cluster is really the right thing to be doing. If you did want to get as many operations through as possible, you may want to consider using asynch operations and having a separate threadpool handling responses. There are a couple of other approaches too, like wrapping the async operations with something that'll give you a callback. |
| Comment by Matt Ingenthron [ 04/Nov/12 ] |
| Through the discussion, worked out that it's not total lack of availability, but rather that the way the workload is distributed by the app all threads will likely end up blocked at a particular node. |
| Comment by Denis Nelubin [ 04/Nov/12 ] |
|
So, for my case: continuously running YCSB workload and down the node - it's not possible to keep the cluster functional?
But in real world, where actual clients can reconnect to the cluster avoiding non-functional node, or use async requests, it's not a problem? But what is the role of replica in Couchbase if clients cannot operate with replicated data when primary is down? |
| Comment by bengber [ 04/Nov/12 ] |
|
It's certainly clear that there's an availability/consistency tradeoff here. But you guys seem to be misunderstanding each other.
If a node goes down, what is the correct way for the database to fail over? We certainly don't mind having a brief period of unavailability. The question is what is the correct way to test failover on Couchbase? 1. We have 4 nodes in a cluster: A, B, C ,D 2. Node C goes down (because of network failure, power failure, etc.) 3. What should happen now? What we're experiencing is the entire cluster fails and stays down. That can't possibly be the correct behavior. So we need to know the proper remediation steps. Is there are server side command to bring the cluster back into a usable state? Or is there some client-specific logic we should add? |
| Comment by Matt Ingenthron [ 04/Nov/12 ] |
|
I think I addressed that in the second paragraph of my reply above. When a node fails, there are two ways to failover and bring the cluster back to a healthy state. Both of these happen immediately when failover is triggered.
The first is that through the web console (or REST interface) you can trigger failover for data which is primarily available from a given node. This would be done after the administrator decides something is definitely wrong with the given node, and thus he declares a failure. The second is that autofailover may be configured to automatically failover if a given node goes down. There is a minimum of 30s to determine if failure has really occurred, but once failure is declared by autofailover, it happens immediately. All official Couchbase clients handle this failover, and moxi can handle it for memcached clients which are not cluster aware. See the documentation for more info: http://www.couchbase.com/docs/couchbase-manual-1.8/couchbase-admin-tasks-failover.html (for 1.8) http://www.couchbase.com/docs/couchbase-manual-2.0/couchbase-admin-tasks-failover.html (for 2.0) Note that it's covered in each manual's architecture and concepts chapter too. |
[JCBC-136] Add support for spatial view queries Created: 29/Oct/12 Updated: 03/Dec/12 Resolved: 21/Nov/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1-dp3, 1.1-dp4 |
| Fix Version/s: | 1.1-beta |
| 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 | ||
| Issue Links: |
|
||||||||
| Flagged: |
Release Note
|
||||||||
| Description |
|
Add query support for spatial views.
|
| Comments |
| Comment by Michael Nitschinger [ 06/Nov/12 ] |
| http://review.couchbase.org/#/c/22308/ |
| Comment by Michael Nitschinger [ 15/Nov/12 ] |
| Update: http://review.couchbase.org/#/c/22563/ |
| Comment by Michael Nitschinger [ 21/Nov/12 ] |
| Implemented and pushed to master, will be available in dp5. |
[JCBC-124] Cannot operate on keys with spaces in them Created: 02/Oct/12 Updated: 09/Oct/12 Resolved: 09/Oct/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | None |
| Fix Version/s: | 1.1-beta |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Aaron Miller | Assignee: | Michael Nitschinger |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
The other clients allows keys with spaces in them, such as "test key", but there is no way to operate on these using the Java client.
myclient.set("test key", 0, "test value"); java.lang.IllegalArgumentException: Key contains invalid characters: ``test key'' at net.spy.memcached.util.StringUtils.validateKey(StringUtils.java:79) at net.spy.memcached.MemcachedConnection.enqueueOperation(MemcachedConnection.java:639) at net.spy.memcached.MemcachedClient.asyncStore(MemcachedClient.java:300) at net.spy.memcached.MemcachedClient.set(MemcachedClient.java:733) |
| Comments |
| Comment by Matt Ingenthron [ 04/Oct/12 ] |
| At the moment, we'll need to see if allowing keys with spaces are intended to be supported. Earlier discussion with folks indicated it was not intended to be supported. |
| Comment by Aaron Miller [ 05/Oct/12 ] |
|
Well, this is really an issue with spymemcached, as it's incorrectly applying ASCII protocol key restrictions over binary protocol.
If we have extra key restrictions in Couchbase, those should probably be handled in the Couchbase client. I believe the approach we're using in Couchbase was that you could -insert- whatever you want, since there are lots of memcached clients out there that will be used, and community libraries and such, and that UTF-8 keys were required for your item to be picked up by views. As it stands today the libcouchbase-based clients can insert items that the java client cannot touch, which makes using the java client with other clients in the same system very likely to cause frustration if they run into this problem. |
| Comment by Michael Nitschinger [ 08/Oct/12 ] |
|
http://review.couchbase.com/#/c/21323/
That's a good one Aaron, I'll test that and abandon my changeset. |
| Comment by Mike Wiederhold [ 08/Oct/12 ] |
|
Aaron,
This has been an open argument on the Java SDK for some time. The reason that we don't allow spaces in the key names is so that Java users can switch between ascii and binary connections and still have their applications function correctly. I think the correct thing to do here would be to add an option in the connection factory to enable the use of keys with spaces in binary protocol. |
| Comment by Aaron Miller [ 08/Oct/12 ] |
|
That seems silly, because as it stands right now they cannot switch from another language to Java and have it work correctly, nor do what I'm trying to do, which is attempting to interoperate with another piece of software that I did not write that uses a different language's SDK, since the other language SDKs allow spaces. Once we have a JRuby client based on this java client ready, they wouldn't even be able to switch from Ruby to JRuby.
I don't see a compelling reason for the Java client to behave differently from other clients, and if somebody is tripped up in this manner the fix would be simply to use the binary protocol. It doesn't seem worth breaking interoperability over. |
| Comment by Mike Wiederhold [ 09/Oct/12 ] |
|
Duplicate of |
[JCBC-135] Using Couchbase inside netty server fails Created: 25/Oct/12 Updated: 26/Mar/13 Resolved: 26/Mar/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | None |
| Fix Version/s: | 1.1.5 |
| 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 | ||
| Flagged: |
Release Note
|
| Description |
|
See this forum question for a description of the issue as well as the fix for it:
http://www.couchbase.com/forums/thread/using-couchbaseclient-inside-netty-server |
| Comments |
| Comment by Michael Nitschinger [ 16/Nov/12 ] |
| http://review.couchbase.com/#/c/22589/ |
| Comment by Michael Nitschinger [ 16/Nov/12 ] |
|
I could reproduce this issue by instantiating a couchbase server inside a handler. If you instantiate the connection outside it works. Here is the code to reproduce it:
when you run it in the IDE and telnet to localhost 8080 it will die and throw the exception: package com.couchbase.nettyexample; import com.couchbase.client.CouchbaseClient; import java.io.IOException; import java.net.InetSocketAddress; import java.net.URI; import java.util.Arrays; import java.util.concurrent.Executors; import org.jboss.netty.bootstrap.ServerBootstrap; import org.jboss.netty.channel.ChannelHandlerContext; import org.jboss.netty.channel.ChannelPipeline; import org.jboss.netty.channel.ChannelPipelineFactory; import org.jboss.netty.channel.Channels; import org.jboss.netty.channel.MessageEvent; import org.jboss.netty.channel.SimpleChannelUpstreamHandler; import org.jboss.netty.channel.socket.nio.NioServerSocketChannelFactory; /** * Hello world! * */ public class App { private final int port = 8080; private CouchbaseClient client; public void run() throws IOException { ServerBootstrap bootstrap = new ServerBootstrap( new NioServerSocketChannelFactory( Executors.newCachedThreadPool(), Executors.newCachedThreadPool() ) ); bootstrap.setPipelineFactory(new ChannelPipelineFactory() { public ChannelPipeline getPipeline() throws Exception { return Channels.pipeline(new EchoServerHandler()); } }); bootstrap.bind(new InetSocketAddress(port)); } public static void main(String[] args) throws IOException { new App().run(); } class EchoServerHandler extends SimpleChannelUpstreamHandler { private CouchbaseClient client; public EchoServerHandler() throws IOException { this.client = new CouchbaseClient( Arrays.asList(URI.create("http://localhost:8091/pools")), "default", "" ); this.client.set("received", 0, "foo"); } @Override public void messageReceived(ChannelHandlerContext ctx, MessageEvent e) { System.out.println("Received Message"); System.out.println(client.get("received")); } } } |
| Comment by Michael Nitschinger [ 26/Mar/13 ] |
| will be available in 1.1.5. |
[JCBC-131] Java Sample Application Created: 12/Oct/12 Updated: 11/Dec/12 Resolved: 11/Dec/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | None |
| Fix Version/s: | 1.1.0 |
| 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 | ||
| Description |
|
Create and document the sample application (port the ruby example app to java).
|
| Comments |
| Comment by Michael Nitschinger [ 11/Dec/12 ] |
| Done, and will be released with the 1.1.0 release. |
[JCBC-127] Publish Couchbase Java SDK Javadoc online, and as a complete resource (zip) Created: 06/Oct/12 Updated: 07/Nov/12 Resolved: 07/Nov/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.1.0 |
| Security Level: | Public |
| Type: | New Feature | Priority: | Major |
| Reporter: | Tug Grall | Assignee: | MC Brown |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Publish Couchbase Java SDK Javadoc online, and as a complete resource (zip)
|
| Comments |
| Comment by MC Brown [ 07/Nov/12 ] |
|
Done. We have a summary page on couchbase.com/autodocs/index.html Some refinements will follow, but this is being auto-created and updated now. |
[JCBC-123] ArrayOutOfBounds exception during failover Created: 02/Oct/12 Updated: 03/Dec/12 Resolved: 09/Nov/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | 1.0.3 |
| Fix Version/s: | 1.1-beta |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Mark Nunberg | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
While running a sequence of getsAsync operations, the entry point/bootstrap node is failed over. The output follows
Exception in thread "SDK Handle-8" java.lang.ArrayIndexOutOfBoundsException: -1 at java.util.ArrayList.elementData(ArrayList.java:338) at java.util.ArrayList.get(ArrayList.java:351) at com.couchbase.client.vbucket.config.DefaultConfig.getServer(DefaultConfig.java:81) at com.couchbase.client.vbucket.VBucketNodeLocator.getPrimary(VBucketNodeLocator.java:74) at com.couchbase.client.CouchbaseConnection.addOperation(CouchbaseConnection.java:144) at net.spy.memcached.MemcachedConnection.enqueueOperation(MemcachedConnection.java:639) at net.spy.memcached.MemcachedClient.asyncGets(MemcachedClient.java:888) at net.spy.memcached.MemcachedClient.asyncGets(MemcachedClient.java:902) at com.couchbase.sdkd.cbclient.GetCommandContext.doOneCommand(GetCommandContext.java:60) at com.couchbase.sdkd.cbclient.CommandContext.execute(CommandContext.java:266) at com.couchbase.sdkd.server.SdkServer.executeCommand(SdkServer.java:114) at com.couchbase.sdkd.server.SdkServer.handleRequest(SdkServer.java:133) at com.couchbase.sdkd.server.SdkServer.run(SdkServer.java:187) |
| Comments |
| Comment by Matt Ingenthron [ 05/Oct/12 ] |
| This may fall into rewriting the configuration handling. I'll discuss this more with Michael as needed. |
| Comment by Michael Nitschinger [ 15/Oct/12 ] |
|
Hey Mark, can you check if this also happens against the dp3 release? I saw that the sdkd-java builds against the stable release. Thanks! |
| Comment by Michael Nitschinger [ 08/Nov/12 ] |
| Tracked here: http://review.couchbase.org/#/c/22352/ |
| Comment by Michael Nitschinger [ 09/Nov/12 ] |
|
An exception is now raised, because a vbucket master of -1 means that no server is able to respond for the given key. This is a strong indication of data loss. This could be the case because no replica was defined and a node was failed over or more nodes have been failed over than replicas defined. Either way, the client itself has no chance of dealing with the situation and therefore populates a controlled exception up to the caller. The fix has been pushed to master and will be available in dp5. |
[JCBC-118] Improve the docs for observe around the ReplicateTo flag Created: 25/Sep/12 Updated: 26/Sep/12 Resolved: 26/Sep/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | None |
| Fix Version/s: | 1.1-beta |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Mike Wiederhold | Assignee: | Raghavan Srinivas |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
See the comment to my response of this question. http://stackoverflow.com/questions/12521102/in-couchbases-observe-feature-what-is-the-difference-between-persistto-and/12521346#comment16856063_12521346 |
| Comments |
| Comment by Raghavan Srinivas [ 26/Sep/12 ] |
| I have generated a pull request to have this fixed. |
[JCBC-109] Reduce observe poll interval latency Created: 11/Sep/12 Updated: 12/Sep/12 Resolved: 12/Sep/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Matt Ingenthron | Assignee: | Raghavan Srinivas |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Current observe poll latencies are very long, some 400ms by default. Testing shows latencies can be as low as 10ms in some cases, so to optimize for the best case, we should lower the polling interval to 100ms, but still poll for up to 4000 sec.
JCBC-108 tracks converting this to an adaptive algorithm based on server statistics. |
| Comments |
| Comment by Mike Wiederhold [ 12/Sep/12 ] |
| Matt checked in a fix for this last night. |
[JCBC-107] OperationStatus message is incorrect if observe poll interval or limit is tuned Created: 10/Sep/12 Updated: 12/Sep/12 Resolved: 12/Sep/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.1-dp3 |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Matt Ingenthron | Assignee: | Matt Ingenthron |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Comments |
| Comment by Matt Ingenthron [ 10/Sep/12 ] |
| http://review.couchbase.org/#/c/20712/ |
[JCBC-106] Upgrade Netty dependency Created: 31/Aug/12 Updated: 18/Sep/12 Resolved: 18/Sep/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1dp2 |
| Fix Version/s: | 1.1-dp3 |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Ben McCann | Assignee: | Raghavan Srinivas |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
There have been reports of Couchbase client causing issues with Play Framework due to using an outdated Netty dependency
https://groups.google.com/d/topic/play-framework/_ZnyqUxiem4/discussion Netty 3.5.5 is currently available from netty,io |
| Comments |
| Comment by Raghavan Srinivas [ 16/Sep/12 ] |
| In review for dp3. |
[JCBC-105] Expose "stats key" results through client API Created: 28/Aug/12 Updated: 30/Sep/12 Resolved: 30/Sep/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.0.3 |
| Fix Version/s: | 1.1.0 |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Perry Krug | Assignee: | Mike Wiederhold |
| Resolution: | Fixed | Votes: | 1 |
| Labels: | customer | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Customer request to access per-key metadata information from API:
verification for key foo key_cas: 1 key_data_age: 0 key_dirtied: 0 key_exptime: 0 key_flags: 0 key_is_dirty: 0 key_last_modification_time: 1346067947 key_valid: valid |
| Comments |
| Comment by Mike Wiederhold [ 30/Sep/12 ] |
|
http://review.couchbase.org/#/c/21200/ http://review.couchbase.org/#/c/21202/ |
[JCBC-104] Cannot discern difference between modified and timed out on synchronous operations - OperationStatus on observed operations does not record the status of the observe Created: 27/Aug/12 Updated: 12/Sep/12 Resolved: 12/Sep/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | None |
| Fix Version/s: | 1.1-dp3 |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Matt Ingenthron | Assignee: | Raghavan Srinivas |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
From the synchronous set method, the underlying observePoll() is called but the results of the OperationFuture are set with the result of the status of the mutation, not the result of the status of the observe.
public OperationFuture<Boolean> set(String key, int exp, String value, PersistTo req, ReplicateTo rep) { OperationFuture<Boolean> setOp = set(key, exp, value); try { if (setOp.get()) { observePoll(key, setOp.getCas(), req, rep); } } catch (InterruptedException e) { setOp.set(false, setOp.getStatus()); } catch (ExecutionException e) { setOp.set(false, setOp.getStatus()); } catch (TimeoutException e) { setOp.set(false, setOp.getStatus()); } catch (IllegalArgumentException e) { setOp.set(false, setOp.getStatus()); } catch (RuntimeException e) { setOp.set(false, setOp.getStatus()); } return (setOp); } Note that the setOp response is used when setting it's own status, not the status of the observe, which is buried in the exception. The exception is out of scope by the time the response goes back to the caller's code. |
| Comments |
| Comment by Raghavan Srinivas [ 12/Sep/12 ] |
| This has been fixed and should be available in 1.1 beta |
[JCBC-102] Client.get() returns null values when using CouchbaseConnectionFactoryBuilder Created: 20/Aug/12 Updated: 13/Sep/12 Resolved: 13/Sep/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1dp |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Tim Pedersen | Assignee: | Raghavan Srinivas |
| Resolution: | Cannot Reproduce | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
OSX
Couchbase Server 2.0.0dp4r-730-rel Java Client 1.1-dp |
||
| Description |
|
Java client 1.1-dp seems to have a problem using CouchbaseConnectionFactoryBuilder. Client.get() returns null values regardless of whether a key exists or not. Java client 1.0.3 doesn't have the problem.
With 1.1-dp, if I set up a client like so: URI base = new URI(String.format("http://%s:8091/pools", server)); List<URI> baseURIs = new ArrayList<URI>(); baseURIs.add(base); CouchbaseConnectionFactoryBuilder cfb = new CouchbaseConnectionFactoryBuilder(); cfb.setOpTimeout(10000); cfb.setOpQueueMaxBlockTime(10000); CouchbaseConnectionFactory cf = cfb.buildCouchbaseConnection(baseURIs, bucket, "", ""); CouchbaseClient client = new CouchbaseClient(cf); then try to get a key like so: getFuture = client.asyncGet(key); value = (String) getFuture.get(); // value is null the .get() doesn't fail but the returned value is null. However, if I set up the 1.1-dp client like so, using just CouchbaseConnectionFactory: URI base = new URI(String.format("http://%s:8091/pools", server)); List<URI> baseURIs = new ArrayList<URI>(); baseURIs.add(base); CouchbaseConnectionFactory cf = new CouchbaseConnectionFactory(baseURIs, bucket, ""); CouchbaseClient client = new CouchbaseClient(cf); getFuture = client.asyncGet(key); value = (String) getFuture.get(); // value is not null and contains the document for the key I want to use CouchbaseConnectionFactoryBuilder because I'm doing a bulk import of millions of documents and I need the timeout/blocking behaviour to prevent swamping the client. Java client 1.0.3 works correctly - using CouchbaseConnectionFactoryBuilder to build connection factories and clients results in the correct behaviour. |
| Comments |
| Comment by Tim Pedersen [ 20/Aug/12 ] |
|
This also affects getting documents from queries/views see |
| Comment by Raghavan Srinivas [ 13/Sep/12 ] |
|
I tried to reproduce this with the latest builds as below and I don't see this error. I see the following relevant output.
{"presidency":"1","name":"George Washington","wikipedia_entry":"http://en.wikipedia.org/wiki/George_Washington","took_office":"1789","left_office":"1797","party":"Independent","portrait":"GeorgeWashington.jpg","thumbnail":"thmb_GeorgeWashington.jpg","home_state":"Virginia","type":"president"} value = {"presidency":"1","name":"George Washington","wikipedia_entry":"http://en.wikipedia.org/wiki/George_Washington","took_office":"1789","left_office":"1797","party":"Independent","portrait":"GeorgeWashington.jpg","thumbnail":"thmb_GeorgeWashington.jpg","home_state":"Virginia","type":"president"} import java.net.URI; import java.util.ArrayList; import java.util.List; import com.couchbase.client.CouchbaseClient; import com.couchbase.client.CouchbaseConnectionFactory; import com.couchbase.client.CouchbaseConnectionFactoryBuilder; import net.spy.memcached.internal.GetFuture; public class cfb { public static void main(String args[]) { try { URI base = new URI( String.format("http://%s:8091/pools","localhost")); List<URI> baseURIs = new ArrayList<URI>(); baseURIs.add(base); // baseURIs.add(fallback); CouchbaseConnectionFactoryBuilder cfb = new CouchbaseConnectionFactoryBuilder(); // wait up to 10 seconds for an operation to succeed cfb.setOpTimeout(10000); CouchbaseConnectionFactory cf = cfb.buildCouchbaseConnection(baseURIs, "default", "", ""); // new // CouchbaseConnectionFactory(baseURIs, "default", ""); CouchbaseClient client = new CouchbaseClient(cf); System.out.println(client.get("1")); GetFuture getFuture = client.asyncGet("1"); String value = (String) getFuture.get(); System.out.println("value = " + value); } catch (Exception e) { System.err.println("Error connecting to Couchbase: " + e.getMessage()); } finally { System.exit(0); } } } |
| Comment by Raghavan Srinivas [ 13/Sep/12 ] |
|
Based on my comments earlier during the day, I could not reproduce. Please reopen if you stil see the same issue or if the steps I am not following are not exactly the same? |
[JCBC-99] Java 1.1 DP exception on failed auth Created: 16/Aug/12 Updated: 13/Nov/12 Resolved: 13/Nov/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1dp2 |
| Fix Version/s: | 1.1-beta |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Perry Krug | Assignee: | Matt Ingenthron |
| Resolution: | Incomplete | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
couchbasetrace.txt
|
| Description |
|
Stack trace attached. Looks like a few different failures around multi-gets, there are some incomplete binary ops and failed authentications (alongside successful authentications, so I presume the user/pass is actually correct).
|
| Comments |
| Comment by Michael Nitschinger [ 09/Nov/12 ] |
|
Perry, do you have code around this stack trace?
I wonder whats going on here because of so many connects and reconnects - I guess the failed bulk get has to do with it. The problem is that - at least to me - the stack trace doesn't show much information that hints to a defect in the SDK. If you have more meat I'll be happy to look at it! |
| Comment by Michael Nitschinger [ 13/Nov/12 ] |
|
Hey, Perry told me that he has not more information regarding this ticket. To me this doesn't look like an issue in the first place, more like a weird network thing. I'd like to close it and reopen it when a specific issue pops up, but feel free to pass it back to me when you think we need to take action on this. Thanks! |
| Comment by Matt Ingenthron [ 13/Nov/12 ] |
| Unfortunately, there's not enough info here to indicate an issue. If more info becomes available, please re-open. |
[JCBC-96] client IO thread is blocked by the fix applied for JCBC-20, doWrites() needs to put data somewhere for another thread to do the work Created: 09/Aug/12 Updated: 01/Oct/12 Resolved: 16/Aug/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Matt Ingenthron | Assignee: | Mike Wiederhold |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
In The ViewNode has it's own thread, so this should be moved to that node's thread. |
| Comments |
| Comment by Matt Ingenthron [ 09/Aug/12 ] |
|
Mike: you know this area well and did the fix for |
| Comment by Matt Ingenthron [ 09/Aug/12 ] |
|
A temporary workaround:
diff --git a/src/main/java/com/couchbase/client/ViewConnection.java b/src/main/java/com/couchbase/client/ViewConnection.java index c4ae419..75bfcf6 100644 --- a/src/main/java/com/couchbase/client/ViewConnection.java +++ b/src/main/java/com/couchbase/client/ViewConnection.java @@ -140,6 +140,7 @@ public class ViewConnection extends SpyThread implements public void handleIO() { for (ViewNode node : couchNodes) { + getLogger().debug("Handling view IO on: " + node.getSocketAddress()); node.doWrites(); } diff --git a/src/main/java/com/couchbase/client/ViewNode.java b/src/main/java/com/couchbase/client/ViewNode.java index 8b6cfa7..f1b56e1 100644 --- a/src/main/java/com/couchbase/client/ViewNode.java +++ b/src/main/java/com/couchbase/client/ViewNode.java @@ -101,7 +101,8 @@ public class ViewNode extends SpyObject { public void doWrites() { HttpOperation op; try { - while ((op = writeQ.take()) != null) { + getLogger().debug("Will try to write view request to node: " + addr); + while ((op = writeQ.poll(50, TimeUnit.MILLISECONDS)) != null) { if (!op.isTimedOut() && !op.isCancelled()) { AsyncConnectionRequest connRequest = connMgr.requestConnection(); try { @@ -156,6 +157,7 @@ public class ViewNode extends SpyObject { } public void addOp(HttpOperation op) { + getLogger().debug("Adding an operation on the view node " + addr); try { if (!writeQ.offer(op, opQueueMaxBlockTime, TimeUnit.MILLISECONDS)) { throw new IllegalStateException("Timed out waiting to add " + op |
| Comment by Mike Wiederhold [ 01/Oct/12 ] |
| This fix is in 1.0.2+ and should be in 1.1dp3+. |
[JCBC-95] view requests do not have HTTP authorization header Created: 08/Aug/12 Updated: 18/Sep/12 Resolved: 18/Sep/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1dp |
| Fix Version/s: | 1.1-dp3 |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Matt Ingenthron | Assignee: | Matt Ingenthron |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Authorization checking has only been recently added to the server and it's been found that view requests are missing authorization headers. This means view requests come back empty, owing to a 401 on request.
|
| Comments |
| Comment by Raghavan Srinivas [ 22/Aug/12 ] |
| This issue exists in dp2 as well. We will fix this for dp3. |
| Comment by Matt Ingenthron [ 24/Aug/12 ] |
| Rags said this is build 1616 of the server. |
| Comment by Michael Nitschinger [ 26/Aug/12 ] |
|
Should this be done the same way as adding the authorization to design doc creation?
Is there already someone assigned to it? |
| Comment by Matt Ingenthron [ 26/Aug/12 ] |
| This one is believed to be fixed, but Rags said he had a problem with build 1616. Someone just needs to verify authorization headers are being built and used correctly, then we can close this. |
| Comment by Matt Ingenthron [ 18/Sep/12 ] |
| Fixed some time ago, verified this evening. |
[JCBC-94] Shutdown function does not shutdown ViewConnection Thread Created: 02/Aug/12 Updated: 03/Dec/12 Resolved: 08/Nov/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.1-beta |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | James Mauss | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: | 1.0.3 | ||
| Description |
|
The patch (ViewConnection.java) in the bug http://www.couchbase.com/issues/browse/JCBC-26 fixed the dead loop issue, but it introduced another Shutdown issue.
when calling the shutdown function of CouchbaseClient, it could not shutdown the thread of the ViewConnection. Public void run() { While(running) { If (!reconfiguring) { Synchronized(threadLock) { Boolean hasOps = false; While(!hasOps) { ==> While(!hasOps && running) For (viewNode node: couchNodes) { If (node.hasWriteOps()) { hasOps = true; break; } } ...... If (!hasOps) { threadLock.wait(); } } } If (running) { handleIO(); } |
| Comments |
| Comment by Mike Wiederhold [ 14/Sep/12 ] |
|
Duplicate of |
| Comment by Michael Nitschinger [ 02/Oct/12 ] |
| I guess there is something I need to look into - I'm going to verify that soon and report my findings! |
| Comment by Michael Nitschinger [ 03/Oct/12 ] |
|
I started tracking this down today. See the progress of it here: http://review.couchbase.com/#/c/21301/
I'll update this ticket as soon as the problem is reliably detected. |
| Comment by Michael Nitschinger [ 08/Nov/12 ] |
| pushed to master, will be available in dp5. |
[JCBC-93] Download link is "protected" based on referrer URL Created: 01/Aug/12 Updated: 07/Aug/12 Resolved: 07/Aug/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1dp |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Tim Smith | Assignee: | Matt Ingenthron |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: | I did this from a VM host in our office, but it's the same from anywhere. | ||
| Description |
|
I don't think this makes sense. I believe we can get reasonable download counts from the web server logs. This makes it more difficult for people to access the SDK and may turn people away.
[couch@localhost dist]$ wget --referer=http://www.couchbase.com/develop/java/next http: //packages.couchbase.com/clients/java/1.1-dp/Couchbase-Java-Client-1.1-dp.zip --2012-08-01 16:08:49-- http://packages.couchbase.com/clients/java/1.1-dp/Couchbase-Java-Client-1.1-dp.zip Resolving packages.couchbase.com... 72.21.214.199 Connecting to packages.couchbase.com|72.21.214.199|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1789840 (1.7M) [application/zip] Saving to: `Couchbase-Java-Client-1.1-dp.zip' 100%[=============================================>] 1,789,840 666K/s in 2.6s 2012-08-01 16:08:53 (666 KB/s) - `Couchbase-Java-Client-1.1-dp.zip' saved [1789840/1789840] [couch@localhost dist]$ wget http://packages.couchbase.com/clients/java/1.1-dp/Couchbas e-Java-Client-1.1-dp.zip --2012-08-01 16:09:03-- http://packages.couchbase.com/clients/java/1.1-dp/Couchbase-Java-Client-1.1-dp.zip Resolving packages.couchbase.com... 72.21.214.199 Connecting to packages.couchbase.com|72.21.214.199|:80... connected. HTTP request sent, awaiting response... 403 Forbidden 2012-08-01 16:09:04 ERROR 403: Forbidden. [couch@localhost dist]$ |
| Comments |
| Comment by Matt Ingenthron [ 07/Aug/12 ] |
| That's certainly not the intent. Downloads should be available from anywhere. Let me check. |
| Comment by Matt Ingenthron [ 07/Aug/12 ] |
| Should have been open. We probably set permissions incorrectly when the update went out on June 29. |
| Comment by Matt Ingenthron [ 07/Aug/12 ] |
|
$ curl -I http://packages.couchbase.com/clients/java/1.1-dp/Couchbase-Java-Client-1.1-dp.zip
HTTP/1.1 200 OK x-amz-id-2: ptzygXwJD+uta4zxuM5deoKWp3EswCe43076XhyqSH3jfjQS1gAnQo0lcooJyfrI x-amz-request-id: 98BE66A901D8CD19 Date: Wed, 08 Aug 2012 00:29:12 GMT Last-Modified: Fri, 29 Jun 2012 22:41:03 GMT x-amz-version-id: IWceZI0OgXKSCWDjC8GE_MLVfwRT_RoQ ETag: "01f0881c7ae34f80037a0cf634fa9f9b" Accept-Ranges: bytes Content-Type: application/zip Content-Length: 1789840 Server: AmazonS3 |
[JCBC-92] Java error when a node is removed - need to check for pending state on a bucket Created: 01/Aug/12 Updated: 03/Dec/12 Resolved: 09/Nov/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1dp |
| Fix Version/s: | 1.1-beta |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Raghavan Srinivas | Assignee: | Raghavan Srinivas |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
This is related to CBSE-187.
While the test was running we removed a node from the cluster, there were failures due to operation cancelled and TimeoutException and the test didn't continue. Then we started the test again without adding back the removed node, it just threw: java.lang.ArrayIndexOutOfBoundsException: -1 at java.util.ArrayList.get(Unknown Source) at com.couchbase.client.vbucket.config.DefaultConfig.getServer(DefaultConfig.java:81) at com.couchbase.client.vbucket.VBucketNodeLocator.getPrimary(VBucketNodeLocator.java:74) at com.couchbase.client.CouchbaseConnection.addOperation(CouchbaseConnection.java:143) at net.spy.memcached.MemcachedConnection.enqueueOperation(MemcachedConnection.java:639) at net.spy.memcached.MemcachedClient.asyncStore(MemcachedClient.java:296) at net.spy.memcached.MemcachedClient.set(MemcachedClient.java:727) <supressed> |
| Comments |
| Comment by Michael Nitschinger [ 09/Nov/12 ] |
|
This is a duplicate of See the description of the ticket for more details. |
[JCBC-91] NPE when using malformed URI Created: 01/Aug/12 Updated: 13/Sep/12 Resolved: 13/Sep/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.0.3 |
| Fix Version/s: | 1.1-beta |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Perry Krug | Assignee: | Raghavan Srinivas |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Caused by: java.lang.NullPointerException
at com.couchbase.client.CouchbaseConnectionFactory.getVBucketConfig(CouchbaseConnectionFactory.java:154) at com.couchbase.client.CouchbaseClient.<init>(CouchbaseClient.java:156) at com.couchbase.client.CouchbaseClient.<init>(CouchbaseClient.java:125) at com.couchbase.client.CouchbaseClient.<init>(CouchbaseClient.java:77) at com.playtika.pool.membase.MembasePool.start(MembasePool.java:55) ... 48 more Would prefer a more meaningful error or exception to indicate that the URI was incorrect |
| Comments |
| Comment by Raghavan Srinivas [ 13/Sep/12 ] |
| Same as JCBC-18 |
[JCBC-88] if timeout is lowered, client can fail to resubscribe for cluster reconfiguration updates in a failure scenario Created: 29/Jul/12 Updated: 30/Jul/12 Resolved: 30/Jul/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | 1.0.2 |
| Fix Version/s: | 1.0.3 |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Matt Ingenthron | Assignee: | Matt Ingenthron |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
The resubscription logic depends on performing the resubscribe from a thread from the application calling us. The problem is that it can take upward of 700ms for this to occur meaning the timeout may yank us away before finishing the resubscribe.
|
| Comments |
| Comment by Matt Ingenthron [ 29/Jul/12 ] |
| http://review.couchbase.org/#change,19008 |
[JCBC-87] incr/decr should return a BigInteger Created: 20/Jul/12 Updated: 13/Aug/12 Resolved: 13/Aug/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Mike Wiederhold | Assignee: | Unassigned |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
We can easily incr past the size of a long so we should use something that can hold a value of any size.
|
| Comments |
| Comment by Mike Wiederhold [ 13/Aug/12 ] |
| I looked at the ep-engine source code and if you incr past a 64 bit number you get an error. |
[JCBC-86] Remove getHashAlgorithm and verify correct behavior of client Created: 20/Jul/12 Updated: 03/Dec/12 Resolved: 21/Nov/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.1-beta |
| Security Level: | Public |
| Type: | Bug | 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 | ||
| Description |
|
Current CacheConfig class has a getHashAlgorithm method and it seems to define native hash. Since there don't seem to be any uses of this, it should be removed or somehow refactored out.
|
| Comments |
| Comment by Michael Nitschinger [ 15/Nov/12 ] |
|
Investigations show that the getHashAlgorithm() is defined by the Cache interface, but actually never used throughout the codebase.
michael@daschlbook ~/couchbase/couchbase-java-client $ grep -r 'getHashAlgorithm()' src/* src/main/java/com/couchbase/client/vbucket/config/CacheConfig.java: public HashAlgorithm getHashAlgorithm() { src/main/java/com/couchbase/client/vbucket/config/Config.java: HashAlgorithm getHashAlgorithm(); src/main/java/com/couchbase/client/vbucket/config/DefaultConfig.java: public HashAlgorithm getHashAlgorithm() { Also, the CacheConfig never makes use of its defined hashAlgorithm. Therefore we, can either remove it from the interface alltogether (the getter), or just throw an unsupported method from the config? |
| Comment by Michael Nitschinger [ 15/Nov/12 ] |
| What do you think should we do in this case? |
| Comment by Matt Ingenthron [ 15/Nov/12 ] |
| I'm good either removing it or having it throw something. Your choice. |
| Comment by Michael Nitschinger [ 16/Nov/12 ] |
| http://review.couchbase.com/#/c/22586/ |
| Comment by Michael Nitschinger [ 21/Nov/12 ] |
| Fixed and merged into master. Will be available in dp5! |
[JCBC-85] We need a better way to run our view tests Created: 12/Jul/12 Updated: 31/Jan/13 Resolved: 31/Jan/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.1.0 |
| Security Level: | Public |
| Type: | Improvement | 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 | ||
| Description |
|
Right now we create a view and the wait for 30 seconds. We should add dome logic to be able to tell exactly when the view is created so that the unit tests run faster.
|
| Comments |
| Comment by Matt Ingenthron [ 08/Oct/12 ] |
| Passing to Michael as an improvement to be made in the 1.2 timeframe since there is a server dependency. We can't currently determine when the cluster has distributed ddocs (that happens asynchronously). |
| Comment by Michael Nitschinger [ 31/Jan/13 ] |
| This has been fixed with the introduction of the ClusterManager as part of the test suite. |
[JCBC-84] We need more unit tests for views Created: 12/Jul/12 Updated: 08/Nov/12 Resolved: 08/Nov/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | None |
| Fix Version/s: | 1.1-beta |
| Security Level: | Public |
| Type: | Improvement | 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 Mike Wiederhold [ 30/Aug/12 ] |
| This bug may be vague, but I don't think we should close it until we actually add more view tests to our unit testing. I constantly hear from the support team for example that users are sending valid queries that are put together incorrectly by the client. It is tests like these that should be added. |
| Comment by Matt Ingenthron [ 10/Sep/12 ] |
|
as part of |
| Comment by Michael Nitschinger [ 04/Oct/12 ] |
|
I've been adding view tests here, are there some areas where we can improve further (or any scenarios that are not covered here):
http://review.couchbase.com/#/c/21338/ http://review.couchbase.com/#/c/21305/ Also I've been adding new ComplexKey and query unit tests here that should prove the correct functionality: http://review.couchbase.com/#/c/21337/ |
| Comment by Mike Wiederhold [ 05/Oct/12 ] |
| This is great progress on this issue. Once you have figured out where we are lacking on testing for views feel free to close this and open up some more specific issues. |
| Comment by Matt Ingenthron [ 08/Oct/12 ] |
| Would like Michael N. to open specific issues as recommended and then close this issue. |
| Comment by Michael Nitschinger [ 08/Nov/12 ] |
|
I think we are in pretty good shape with view tests now, since the query object is unit tested and we have view tests in place for (hopefully) all the params and also for observe-variations in combination with stale = false. If special issues come up we can reopen a specific issue for them as noted. |
[JCBC-81] Update the getting started to match the Beer sample DB Created: 12/Jul/12 Updated: 05/Dec/12 Resolved: 05/Dec/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | None |
| Fix Version/s: | 1.1.0 |
| Security Level: | Public |
| Type: | Improvement | 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 | ||
| Description |
|
Once the sample DB has been integrated into the server, update the getting started (both on the web page and in the documentation) to use the sample database.
|
| Comments |
| Comment by Michael Nitschinger [ 05/Dec/12 ] |
| Updated and available! |
[JCBC-80] Add a unit/integration test validation of OBSERVE + view stale=false Created: 12/Jul/12 Updated: 03/Dec/12 Resolved: 09/Oct/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | None |
| Fix Version/s: | 1.1-beta |
| Security Level: | Public |
| Type: | Improvement | 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 | ||
| Description |
|
Ensure that when a synchronous set is used with the new low-level observe, the index is fully updated when querying with stale=false.
|
| Comments |
| Comment by Michael Nitschinger [ 09/Oct/12 ] |
| http://review.couchbase.com/#/c/21444/ |
| Comment by Michael Nitschinger [ 09/Oct/12 ] |
|
In my tests while writing the integration test, I found that when using PersistTo.MASTER and ReplicateTo.ONE, all records were correctly returned.
But when I just use PersistTo.MASTER, only a subset is returned - I guess this should be investigated. |
| Comment by Michael Nitschinger [ 08/Nov/12 ] |
| pushed to master, will be available in dp5. |
[JCBC-77] Design document management, including error handling Created: 12/Jul/12 Updated: 14/Sep/12 Resolved: 14/Sep/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | None |
| Fix Version/s: | 1.1-beta |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Matt Ingenthron | Assignee: | Raghavan Srinivas |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Add the additional functionality needed to create and replace design documents. This will likely be an extension on the Bucket class.
|
| Comments |
| Comment by Mike Wiederhold [ 14/Sep/12 ] |
|
Duplicate of |
[JCBC-79] View error options at query time Created: 12/Jul/12 Updated: 13/Sep/12 Resolved: 13/Sep/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.1-dp3 |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Matt Ingenthron | Assignee: | Raghavan Srinivas |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
At view query time, we need to ensure the developer has the ability to add an "on_error" parameter with values of either "stop" or "continue".
|
| Comments |
| Comment by Matt Ingenthron [ 13/Sep/12 ] |
|
Dupe of |
[JCBC-78] Bucket management Created: 12/Jul/12 Updated: 14/Sep/12 Resolved: 14/Sep/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | None |
| Fix Version/s: | 1.1-beta |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Matt Ingenthron | Assignee: | Raghavan Srinivas |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Add the necessary features to create and remove buckets. Also, add the ability to call the RESTful bucket flush.
|
| Comments |
| Comment by Mike Wiederhold [ 14/Sep/12 ] |
|
Duplicate of |
[JCBC-75] Highlevel synchronous mutation operations atop observe Created: 12/Jul/12 Updated: 22/Aug/12 Resolved: 22/Aug/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | None |
| Fix Version/s: | 1.1dp2 |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Matt Ingenthron | Assignee: | Raghavan Srinivas |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Comments |
| Comment by Raghavan Srinivas [ 22/Aug/12 ] |
| set() and delete() support observe. Looking to support more Mutation operations. |
[JCBC-71] Not able to run the sample program Created: 28/Jun/12 Updated: 23/Aug/12 Resolved: 22/Aug/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.1dp2 |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Pardeep Sharma Pardeep | Assignee: | Raghavan Srinivas |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: | Window 7 -64 bit | ||
| Description |
|
I installed Couchbase Server on my machine with default setting and then tried to run the sample program and got the following error:
2012-06-28 21:12:12.677 INFO com.couchbase.client.CouchbaseConnection: Added {QA sa=/169.254.20.219:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue 2012-06-28 21:12:17.309 WARN com.couchbase.client.CouchbaseConnection: Node exepcted to receive data is inactive. This could be due to afailure within the cluster. Will check for updated configuration. Key without a configured node is: spoon. Jun 28, 2012 9:12:17 PM com.couchbase.client.CouchbaseConnectionFactory checkConfigUpdate WARNING: No reconnect required, though check requested. Current config check is 1 out of a threshold of 10. Exception in thread "main" net.spy.memcached.OperationTimeoutException: Timeout waiting for value at net.spy.memcached.MemcachedClient.get(MemcachedClient.java:1003) at net.spy.memcached.MemcachedClient.get(MemcachedClient.java:1018) at Main.main(Main.java:34) Caused by: net.spy.memcached.internal.CheckedOperationTimeoutException: Timed out waiting for operation - failing node: 169.254.20.219/169.254.20.219:11210 at net.spy.memcached.internal.OperationFuture.get(OperationFuture.java:93) at net.spy.memcached.internal.GetFuture.get(GetFuture.java:62) at net.spy.memcached.MemcachedClient.get(MemcachedClient.java:997) ... 2 more |
| Comments |
| Comment by Matt Ingenthron [ 12/Jul/12 ] |
| This does not appear to be a bug with the client. We'd like to get it to the right place. Was there anything in the server logs? |
| Comment by Raghavan Srinivas [ 22/Aug/12 ] |
| Can you please try this again and post another issue with the sample code? |
| Comment by Pardeep Sharma Pardeep [ 23/Aug/12 ] |
|
Did you fix something?
|
[JCBC-69] Java 1.1DP zip is missing dependent jars Created: 26/Jun/12 Updated: 29/Jun/12 Resolved: 29/Jun/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1dp |
| Fix Version/s: | 1.1dp2 |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Matt Ingenthron | Assignee: | Mike Wiederhold |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Java .zip distribution seems to be missing httpcore-4.1.1.jar,httpcore-nio-4.1.1.jar.
|
[JCBC-68] Query.copy() copies Key into EndkeyDocID Created: 26/Jun/12 Updated: 29/Jun/12 Resolved: 29/Jun/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1dp |
| Fix Version/s: | 1.1dp2 |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Jose | Assignee: | Mike Wiederhold |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | 5m | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | 5m | ||
| Environment: |
All.
Tested on Ubuntu Server 12.04LTS, Oracle/Sun JDK 1.6.0_31 |
||
| Description |
|
The bug causes all query results are not as expected: in every case "key" argument is changed to "EndkeyDocID".
My proposed patch: $ diff --git a/src/main/java/com/couchbase/client/protocol/views/Query.java b/src/main/java/com/couchbase/client/protocol/views/Query.java index fca7ccf..3a019a0 100644 --- a/src/main/java/com/couchbase/client/protocol/views/Query.java +++ b/src/main/java/com/couchbase/client/protocol/views/Query.java @@ -174,7 +174,7 @@ public class Query { query.setInclusiveEnd(((Boolean)args.get(INCLUSIVEEND)).booleanValue()); } if (args.containsKey(KEY)) { - query.setEndkeyDocID(((String)args.get(KEY))); + query.setKey(((String)args.get(KEY))); } if (args.containsKey(LIMIT)) { query.setLimit(((Integer)args.get(LIMIT)).intValue()); $ |
[JCBC-54] configuration checks can overwhelm application code if run without a threshold Created: 22/May/12 Updated: 30/Jul/12 Resolved: 30/Jul/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | 1.0.2 |
| Fix Version/s: | 1.0.3 |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Matt Ingenthron | Assignee: | Matt Ingenthron |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
With changes introduced in 1.0.2, there are frequent configuration checks. They are, unfortunately, too frequent and can overload a system if there there are a large number of requests. Also, ConfigurationProviders are not being shut down gracefully.
|
| Comments |
| Comment by Matt Ingenthron [ 30/Jul/12 ] |
| http://review.couchbase.org/16338 |
[JCBC-49] Query limit does not work with paged queries Created: 15/May/12 Updated: 18/Sep/12 Resolved: 18/Sep/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1dp |
| Fix Version/s: | 1.1-dp3 |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Steven Cooke | Assignee: | Mike Wiederhold |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: | all java | ||
| Description |
|
Query limit property does not work with paged queries. Paginator overwrites the limit with the page size without saving the original and a counter is not kept.
|
| Comments |
| Comment by Mike Wiederhold [ 03/Jun/12 ] |
|
From this issue it sounds like you want to add the following:
1. The limit in the Query class should override the numDocs parameter in the Paginator class. 2. A counter of the number of documents we have iterated through the paginator should be kept. Am I correct here? |
| Comment by Mike Wiederhold [ 14/Sep/12 ] |
| I think I'm going to throw an exception in the case that a user defines their own limit parameter. |
| Comment by Mike Wiederhold [ 18/Sep/12 ] |
| Query limit is now honored in paginated queries. |
[JCBC-45] asyncGetAndLock returns the same value when a lock is refused and when a key is not found Created: 09/May/12 Updated: 03/Jun/12 Resolved: 03/Jun/12 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.0.2 |
| Fix Version/s: | 1.0.3 |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Hari Subramaniam | Assignee: | Mike Wiederhold |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | customer | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
CASGetStatus.java
couchbasediff.txt
|
| Description |
|
This report is re: asyncGetAndLock method in the java client.
From the current implementation of asyncGetAndLock , it is impossible to tell the difference between - a value that doesn't exist(& should be added) and - a value that exists, but is locked by another client. In both cases, you get this: CASValue<T>(-1, null); which customer opines is pretty non-useful in the cases where you want to decide whether to try again or move on to an add. Suggestion from the customer is: Add the CasGetStatus class which has additional information about the failure type (attached), and modify CouchbaseClient.java to create and return that class (diff attached). Attached files: 1) CASGetStatus.java 2) couchbasediff.txt |
| Comments |
| Comment by Matt Ingenthron [ 09/May/12 ] |
| Not sure about that implementation, but need acknowledged. |
| Comment by Matt Ingenthron [ 09/May/12 ] |
| Also, note that code contributions can be posted over at http://review.couchbase.org. Thanks! |
| Comment by Matt Ingenthron [ 09/May/12 ] |
|
(from Mike)
The information that you are trying to get from the asyncGetAndLock() function can already be obtained by calling getStatus() on the Future object that is returned. See my example below: Future<CasValue<Object>> future = client.asyncGetAndLock("key"); future.getStatus().getMessage(); // If key is locked returns "locked" // If key is not found returns "not found" // If key is timed out returns "timed out" Can you try using this method? If you find any shortcomings or feel that your approach provides a major improvement to this then please let me know. - Mike |
| Comment by Hari Subramaniam [ 11/May/12 ] |
|
Mike:
Thanks for the quick response. While I understand your suggestion on how to get at the exact status by introspecting the returned Future object, I received an understandable response back from the customer - i.e. the API return code should indicate the accurate return status so the program logic can make runtime decisions without having to parse the string returned by getstatus()..Here are the customers' comments (unedited): ------------------------------------------------------------------------------------------------------------------- I need the status so I can make run time decisions about whether to retry the request (in the case that it is locked, and will likely be unlocked by the time the retry happens) or to add the object (in the case that it doesn't exist). The OperationFuture's status is fine for logging, but of course we don't want to make run time decisions based on string equality. ------------------------------------------------------------------------------------------------------------------- sample snippet from the customer: CASValue<T> rawCas = this.memcacheClient.getAndLock(key.getRaw(), getOperationTimeout().intValue(), trans); Assert.isTrue(rawCas instanceof CASGetStatus); CASGetStatus<T> cas = (CASGetStatus<T>) rawCas; if (cas.getGetResponse() == CASGetResponse.NOT_FOUND) { return null; } else if (cas.getGetResponse() != CASGetResponse.OK) { throw new CASReadException( "Failed to get an object due to a timeout", cas.getGetResponse()); } To do that with the current system, I'd have to do something sketchy like: If(future.getStatus().getMessage().equals("not found")) { return null; } else … Hope that helps. Any further comments on the suggested change? Thanks! |
| Comment by Mike Wiederhold [ 03/Jun/12 ] |
|
Turns out I just committed some code to review that allows the customer to do this. The commits are below. I will close this bug once it gets through review.
http://review.couchbase.org/#change,15948 http://review.couchbase.org/#change,15949 |
| Comment by Mike Wiederhold [ 03/Jun/12 ] |
| This change that were just committed will allow the user to get the error code returned by all operations. This can be done by calling getStatus().getErrorCode() on any Future returned to the user through CouchbaseClient. Error codes are kept in the ErrorCode enum in the net.spy.memcached.op.ErrorCode class. Please inquire with either myself or Matt for more information. |
|
|