testcase.cpp
[CCBC-193] libcouchbase build is not checking install properly Created: 22/Mar/13 Updated: 22/Mar/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Matt Ingenthron | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
I was trying to package the PHP client, which depends on libcouchase, and it is was refusing to build on some systems.
After looking into it a bit, there may be a couple of problems, but the big one is in the summary. One problem is that it seems the dpkg -i doesn't actually get run. I added an echo of the label in there, and see that in the console output in Jenkins, but I don't see the lines under the label run. I'm stumped there. |
[CCBC-208] libvbucket CRC32 hashing function returns wrong hashes Created: 09/May/13 Updated: 09/May/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | library |
| Affects Version/s: | 2.0.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5, 2.0.6 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Orfeas Zafeiris | Assignee: | Matt Ingenthron |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: | Windows & Linux (debian) | ||
| Description |
|
It seems that the CRC32 hashing function in libvbucket (hash_crc32()) returns an invalid hash.
For instance, hashing the key '1234567890' returns 9757 (0x261D), while it should return 639479525 (0x261DAEE5). Every key I tried (on both win and linux) returns a 16bit hash. The problem seems to be on line 85 in crc32.c. Changing the return expression to 'return crc ^ ~0;' fixes the problem and computes the correct hash. |
| Comments |
| Comment by Sergey Avseyev [ 09/May/13 ] |
| The algorithm based on CRC32, but it isn't CRC32, for example java client does the same: https://github.com/dustin/java-memcached-client/blob/master/src/main/java/net/spy/memcached/DefaultHashAlgorithm.java#L103-108 |
| Comment by Sergey Avseyev [ 09/May/13 ] |
| Do we have official documentation about "crc32-based hash" used in vbucket algorithm? |
| Comment by Orfeas Zafeiris [ 09/May/13 ] |
| I see, however the function name and the comments in vbucket.c make it really confusing for people developing their own clients for interacting with couchbase. |
[CCBC-184] There are a lot of connections are established after restarting Couchbase server Created: 18/Feb/13 Updated: 25/Feb/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | library |
| Affects Version/s: | 2.0.3 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Bug | Priority: | Critical |
| Reporter: | Haster | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Linux, HP-UX
libcouchbase-2.0.3 Couchbase Server 1.8.1 |
||
| Description |
|
1) Start Couchbase Server
2) Start to recieve some key from Couchbase server using a client based on libcouchbase library. We use about 250 threads for receiving key 3) Restart Couchbase server 4) After that a lot of connections are created (all of then in ESTABLISHED state). And soon quota for handlers is over. |
| Comments |
| Comment by Trond Norbye [ 21/Feb/13 ] |
|
I'm not sure I understand the problem here. Are you seeing all of the connections on the server node or on the client node (or is this the same machine)? If this is on the client nodes, are the "old" connections not properly shut down? or does it seem like it is creating multiple new connections per libcouchbase instance? |
| Comment by Haster [ 25/Feb/13 ] |
|
The sockets are created on client side.
We investigate this problem and found that this truble happend than we try to get many values from Couchbase. lcb_get(); lcb_get(); ... lcb_get(); lcb_wait(); And if we have temporary errors libcouchbase make reconnect many times. I don't know is this bug or not. But we avoid this problem by receiving one get a time and waiting if temporary error is happend |
[CCBC-181] enhance observe man page with a more complete example Created: 15/Feb/13 Updated: 02/Apr/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | docs |
| Affects Version/s: | 2.0.3 |
| Fix Version/s: | 2.1.0 |
| Security Level: | Public |
| Type: | Improvement | Priority: | Critical |
| Reporter: | Matt Ingenthron | Assignee: | Matt Ingenthron |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
The current observe man page doesn't really go into how to interpret results from the request. I needs to have that.
Ideally it should also show how one would do a regular poll to show checking for replication or persistence. |
| Comments |
| Comment by Trond Norbye [ 02/Apr/13 ] |
| should probably be written by our native english speaking committer ;) |
[CCBC-162] API reference uses old names, not current lcb_* names Created: 03/Jan/13 Updated: 31/Jan/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | docs |
| Affects Version/s: | 2.0.1 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Bug | Priority: | Critical |
| Reporter: | Tim Smith | Assignee: | MC Brown |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: | http://www.couchbase.com/docs/couchbase-sdk-c-2.0/api-reference-summary.html | ||
| Description |
|
The API reference for all functions uses libcouchbase_* names (libcouchbase_create, etc.) instead of the correct lcb_* names (lcb_create, etc.).
|
| Comments |
| Comment by Trond Norbye [ 29/Jan/13 ] |
| The manual pages for libcouchbase use the correct names :) |
| Comment by Karen Zeller [ 29/Jan/13 ] |
| There is something wrong. At this page, I get: Sorry. We can’t seem to find that page. Can you let me know where this actually appears (name guide, section, page, etc) |
| Comment by Tim Smith [ 30/Jan/13 ] |
|
There's something even bigger wrong, because the page is missing. There's no reference material at all now in the C client library docs, the TOC has:
1. Getting Started 1.1. Downloading the Couchbase Client Library 1.2. Installing from Source: Linux and Mac OS X 1.3. Installing from Source: Microsoft Windows 1.4. Installing on CentOS/ReHat 1.5. Installing on Ubuntu 1.6. Hello C Couchbase 2. Tutorial 2.1. Simple Example 2.2. Additional Resources A. Release Notes The reference page that lists all of the functions, etc., has been removed entirely. Is it supposed to be auto-generated, and perhaps that process is failing? I don't know. |
| Comment by Karen Zeller [ 30/Jan/13 ] |
| I'm going to ask MC to look at this as it appears to be the production system. I noticed a couple pages that had correctly linked as cross references in the past are also 404 missing... |
| Comment by MC Brown [ 31/Jan/13 ] |
| Matt and I agreed to temporarily remove the API reference from the documentation because we know it needs significant updating. The source material for the API is based on the document that Trond produced last year, and which I have no ability to change or fix at the moment, but I'll work to get that updated. |
[CCBC-209] Make Windows builds work with jom Created: 09/May/13 Updated: 10/May/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | library |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Improvement | Priority: | Critical |
| Reporter: | Mark Nunberg | Assignee: | Trond Norbye |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Jom supports parallel-make for windows' nmake (the equivalent to normal make's '-j' option). Right now compiling on windows is painfully slow.
Another alternative would be to make a solution file. http://qt-project.org/wiki/jom |
| Comments |
| Comment by Trond Norbye [ 10/May/13 ] |
| what is stopping the current makefile for being executed by a parallel make? |
[CCBC-200] lcb_make_http_request doesn't respect timeouts Created: 05/Apr/13 Updated: 05/Apr/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | None |
| Affects Version/s: | 2.0.4 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | matthew newhook | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: | Windows 7, VS2010 | ||
| Attachments: |
testcase.cpp
|
| Description |
|
Run the attached testcase on Windows (after fixing the host and such). The lcb_wait after calling lcb_make_http_request will hang for a very long time (perhaps forever) if the server is no longer accessible.
I tested this by starting the client. When it prints "sleeping" I pull the ethernet cable on my machine. If the lcb_make_http_request is replaced by lcb_get then you'll get a timeout which is expected. |
[CCBC-199] Problem with a newly created memcached bucket Created: 02/Apr/13 Updated: 02/Apr/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Trond Norbye | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
See: http://www.couchbase.com/forums/thread/libcouchbase-problem-newly-created-memcached-bucket
|
[CCBC-195] config cache will crash client due to relocating buffers Created: 01/Apr/13 Updated: 02/Apr/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | library |
| Affects Version/s: | 2.0.5 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Mark Nunberg | Assignee: | Mark Nunberg |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
See CCBC-190
During a cluster configuration change, the buffers are relocated while they are being processed. This causes crashes. A solution would be to "request" a configuration refresh and have that take place once it is safe to move buffers around (i.e. once we are out of the buffer processing call chain). |
| Comments |
| Comment by dongzaixx [ 02/Apr/13 ] |
| Same Issue: http://www.couchbase.com/issues/browse/CCBC-188 |
[CCBC-194] Please add support for setsockopt() SO_KEEPALIVE & TCP_KEEPIDLE Created: 25/Mar/13 Updated: 25/Mar/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | library |
| Affects Version/s: | 2.0.4 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Task | Priority: | Major |
| Reporter: | Michael Leib | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: | CentOS 6.x, Linux | ||
| Description |
|
Please add support for setsockopt() options SO_KEEPALIVE & TCP_KEEPIDLE through (suggestion)
lcb_connect() or some other such api so that I can control the connection's ability to not timeout and have a firewall cause a disconnection from lack of inactivity...without such control, receive NETWORK_ERROR from couchbase apis. I cannot adjust the firewall, so I need to keep the connection alive. |
| Comments |
| Comment by Mark Nunberg [ 25/Mar/13 ] |
| As a workaround, you can wrap your own IOPS structure, and override the socket creation bits so as to set your own socket options. |
[CCBC-192] Failure to handle host that has been removed from a cluster Created: 20/Mar/13 Updated: 20/Mar/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | library |
| Affects Version/s: | 2.0.4 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Toby Corkindale | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: | Linux, Ubuntu 12.04 Precise | ||
| Description |
|
We're encountering an issue where both the Ruby and Perl clients get() method will consistently, repeatedly just return an error. On the Perl client it is "Temporary error. try again later", and on Ruby it is "Bucket not found".
This occurs when we have several couchbase servers, and have connected using the node list option to supply all of them to the library. We remove the first server in the node list via the Couchbase GUI, trigger a rebalance, and wait for it to complete. Once the rebalance has completed, we start a script that simply attempts to connect and retrieve some keys we previously inserted. Instead of success, we find that it repeatedly gives the errors mentioned above. note that if we remain connected to the cluster, then everything seems fine. The errors only start occurring when a client connects. note also that the issue only occurs if the first server (or servers) in the list are down; if the first server listed is currently actively in the cluster, then we're OK. It seems like the problem is that the now-removed server is still accepting connections on port 8091, and thus the client library thinks that this means it is a valid server. However because it's removed from the pool, it causes confusion and errors to the client. Obviously, the correct/desired behaviour would be for the client library to behave as if the removed-server was not accepting connections, and to move onto the next server in the node list. |
| Comments |
| Comment by Matt Ingenthron [ 20/Mar/13 ] |
|
Others should comment as well, but our current expectation is that if you're removing a server from the cluster, you're also removing it from the bootstrap list. Thus, the best practice would be to remove it from the list first, then remove the server from the cluster. We can probably make this better though. |
| Comment by Toby Corkindale [ 20/Mar/13 ] |
|
That is our current work-around. However it is rather annoying, and makes rolling updates/reboots an extremely time consuming process. ie. Update puppet with new node list, wait an hour for that to get deployed over every server, then rebalance and remove server1; apply system updates and reboot, then add back to cluster and rebalance. Then update puppet's node list to include that server, but not the next one, wait an hour for it to apply everywhere, etc etc etc. There's also the danger that someone will forget to update the managed node list one day and remove a server from the cluster, expecting it to Just Work. I also have to point out that the current behaviour is unexpected, and I don't recall seeing any warnings about it in the documentation or tutorials; thus it's likely other users may hit this in the future and have some accidental production downtime, as we did. |
| Comment by Matt Ingenthron [ 20/Mar/13 ] |
| Yes, all good points-- we'll definitely look to make it better. |
[CCBC-190] Conncache configuration not passing integration tests Created: 15/Mar/13 Updated: 01/Apr/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | library |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Task | Priority: | Major |
| Reporter: | Mark Nunberg | Assignee: | Trond Norbye |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Description |
|
There are two primary issues which occur during server configuration changes (i.e. failover, rebalance):
1) [SDKD(WARNING) 56.55 cbsdk.sdkd.remote remote.py:266] sdkd_lcb: src/event.c:211: parse_single: Assertion `(lcb_size_t)idx < c->instance->nservers' failed. 2) The client may just hang. |
| Comments |
| Comment by Matt Ingenthron [ 19/Mar/13 ] |
| Trond, can you update this when you have a moment? |
| Comment by Matt Ingenthron [ 26/Mar/13 ] |
| Trond, I know you gave me status via IM, but please update this when you have a moment. |
| Comment by Trond Norbye [ 27/Mar/13 ] |
|
I had problems reproducing any of these problems when I tested it at home (tested both adding nodes, removing nodes, failover nodes etc). I need more time to try to reproduce this, and more information on how to reproduce it. I really don't like using jira as a "task list". JIRA should be used to file bugs, and one bug report PER issue, not multiple issues like this. It would be nice if we could use cbbugg or something with less overhead than the JIRA taskflow (and something that don't require me to log in on a daily basis, but allow me to let the tool be running over night.. after all this is bugs we're talking about, not my credit card information of a flight control system.) |
| Comment by Mark Nunberg [ 27/Mar/13 ] |
|
sdkd_lcb: src/event.c:211: parse_single: Assertion `(lcb_size_t)idx < c->instance->nservers' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 0x54a20940 (LWP 13592)] 0x000000315d230285 in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); (gdb) bt #0 0x000000315d230285 in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x000000315d231d30 in abort () at abort.c:88 #2 0x000000315d229706 in __assert_fail (assertion=0x2aaaaaf6e438 "(lcb_size_t)idx < c->instance->nservers", file=0x2aaaaaf6e385 "src/event.c", line=211, function=0x2aaaaaf6e3bf "parse_single") at assert.c:78 #3 0x00002aaaaaf5448e in parse_single (c=0x2aaac0011000, stop=1364387212495254000) at src/event.c:211 #4 0x00002aaaaaf546e0 in do_read_data (c=0x2aaac0011000, allow_read=0) at src/event.c:275 #5 0x00002aaaaaf5490a in lcb_server_event_handler (sock=312, which=4, arg=0x2aaac0011000) at src/event.c:352 #6 0x00002aaaab39459a in event_base_loop () from /usr/lib64/libevent-1.4.so.2 #7 0x00002aaaab17c321 in lcb_io_run_event_loop (iops=0x6cc7a0) at plugins/io/libevent/plugin-libevent.c:320 #8 0x00002aaaaaf647d8 in lcb_wait (instance=0x6ce720) at src/wait.c:67 #9 0x00002aaaaaae2870 in CBSdkd::Handle::postsubmit (this=0x6cb5a0, rs=..., nsubmit=1) at Handle.cpp:209 #10 0x00002aaaaaae2e22 in CBSdkd::Handle::dsMutate (this=0x6cb5a0, cmd=..., ds=..., out=..., options=...) at Handle.cpp:301 #11 0x00002aaaaaaee6f8 in CBSdkd::WorkerDispatch::_process_request (this=0x2aaab00372c0, req=..., rs=0x2aaab002dec0) at IODispatch.cpp:606 #12 0x00002aaaaaaefc5d in CBSdkd::WorkerDispatch::run (this=0x2aaab00372c0) at IODispatch.cpp:711 #13 0x00002aaaaaaec2d4 in CBSdkd::new_worker_thread (worker=0x2aaab00372c0) at IODispatch.cpp:278 #14 0x000000315de0677d in start_thread (arg=<value optimized out>) at pthread_create.c:301 #15 0x000000315d2d3c1d in clone () from /lib64/libc.so.6 (gdb) frame 3 #3 0x00002aaaaaf5448e in parse_single (c=0x2aaac0011000, stop=1364387212495254000) at src/event.c:211 211 assert((lcb_size_t)idx < c->instance->nservers); (gdb) print idx $1 = -1 (gdb) print c->instance->nservers $2 = 2 It seems that vbucket_found_incorrect_master is returning -1. I'm not sure why this would happen or what the appropriate solution is. In general this piece of "retry" code is subject to the thundering herd problem anyway. A temporary fix would be to just retry the old index until we get a valid config. I'll modify the code and test with that hack, will report results again. |
| Comment by Mark Nunberg [ 27/Mar/13 ] |
|
Additionally: ==16609== Thread 19: ==16609== Conditional jump or move depends on uninitialised value(s) ==16609== at 0x315D2791B4: strstr (strstr.c:110) ==16609== by 0x50B1C90: lcb_load_config_cache (config_cache.c:71) ==16609== by 0x50B1D40: lcb_refresh_config_cache (config_cache.c:99) ==16609== by 0x50B2499: parse_single (event.c:218) ==16609== by 0x50B280E: do_read_data (event.c:308) ==16609== by 0x50B2A38: lcb_server_event_handler (event.c:385) ==16609== by 0x62E2599: event_base_loop (in /usr/lib64/libevent-1.4.so.2.1.3) ==16609== by 0x60DB320: lcb_io_run_event_loop (plugin-libevent.c:320) ==16609== by 0x50C2907: lcb_wait (wait.c:67) ==16609== by 0x4C4086F: CBSdkd::Handle::postsubmit(CBSdkd::ResultSet&, unsigned int) (Handle.cpp:209) ==16609== by 0x4C40E21: CBSdkd::Handle::dsMutate(CBSdkd::Command, CBSdkd::Dataset const&, CBSdkd::ResultSet&, CBSdkd::ResultOptions const&) (Handle.cpp:301) ==16609== by 0x4C4C6F7: CBSdkd::WorkerDispatch::_process_request(CBSdkd::Request const&, CBSdkd::ResultSet*) (IODispatch.cpp:606) |
| Comment by Trond Norbye [ 27/Mar/13 ] |
|
what is the content of buffer? |
| Comment by Mark Nunberg [ 27/Mar/13 ] |
| Fixed the issue, see http://review.couchbase.org/#/c/25372/ |
| Comment by Mark Nunberg [ 27/Mar/13 ] |
| There are other issues. A rudimentary patch has fixed the assertion failure (by doing what I suggested). The subsequent effect however is that the newer configuration is never re-read (resulting in about half the ops getting a NETWORK_ERROR). |
| Comment by Mark Nunberg [ 27/Mar/13 ] |
| Can you explain the consensus process in how a single client decides it will be the "master" for storing the config information? I am tempted to try using flock(2) and see how that works. Keep in mind I am testing with many concurrent clients. |
| Comment by Trond Norbye [ 27/Mar/13 ] |
| There is no masters.. and in theory all of them may update the configuration at the same time. |
| Comment by Trond Norbye [ 27/Mar/13 ] |
| is there a reproducible test case one may run for this?? I had a php script looping in a while (true) mode creating a new cached config while I added, removed, failed over etc nodes and I was not able to reproduce the problem.. |
| Comment by Mark Nunberg [ 28/Mar/13 ] |
| So I've found the underlying cause of the issue. The buffers are being relocated from underneath us while lcb_refresh_config_cache is called. This causes subsequent assertions to fail. Investigating this further now. |
| Comment by Mark Nunberg [ 01/Apr/13 ] |
| I'll split these into several issues (as they are really several issues) |
[CCBC-189] Create a compat mode that cache the configuration objects Created: 26/Feb/13 Updated: 26/Feb/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | library |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Trond Norbye | Assignee: | Trond Norbye |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
[CCBC-187] Set TCP_NODELAY flag Created: 25/Feb/13 Updated: 25/Feb/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Haster | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
We think it is good idea to set TCP_NODELAY flag to switch off the Nagle mode
(don't wait for sending a short packets) Couchbase server, as we think, use this flag |
[CCBC-186] Request to provide concrete examples in the documentation for OBSERVE functionality Created: 21/Feb/13 Updated: 21/Feb/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | docs |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Saran Kumar | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
http://support.couchbase.com/tickets/2608
Customer are interested in using OBSERVE functionality to allow them to check whether items have been replicated successfully, as they are worried about unreplicated items. https://github.com/couchbase/libcouchbase/blob/master/man/man3couchbase/lcb_observe.3couchbase.txt has basic info on the OBSERE functionality in libcouchbase, but we need to provide concrete examples on how to check multiple keys having been replicated successfully (they do a bulk write, so should be more efficient to wait for all of them, rather than wait for them individually) Examples provided to the customer : You will find the below example very useful for simple operations : https://github.com/couchbase/php-ext-couchbase/blob/master/simple_observe.c The below example would provide more insights when you have any performance or reliability issues : https://github.com/couchbase/php-ext-couchbase/blob/master/observe.c The basic idea here is to constantly "poll" the keys (sleeping within a given interval) until all of them are declared as "OK". The structures involved are the "observe_expectation" (persistence/replication requirements), the "pollprefs" (i.e. timeout, interval, etc.) and the "keystate" - this keeps tabs on how the actual status of each key matches up with the specified criteria. The lcb_observe callback is called for each "status report" for each key from each server; so it is necessary to check and see if the requirements have been met during each individual update. |
[CCBC-183] Implement approach to specify behaviour for lcb_get_replica() Created: 15/Feb/13 Updated: 15/Feb/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Task | Priority: | Major |
| Reporter: | Sergey Avseyev | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
The users might want to ask only first or single replica
|
[CCBC-177] Docs: Reference installation Created: 11/Feb/13 Updated: 11/Feb/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | docs |
| Affects Version/s: | 2.0.3 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Perry Krug | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| 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 -other packages/modules required and/or tested with |
[CCBC-174] Error handling documentation Created: 05/Feb/13 Updated: 05/Feb/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | docs |
| Affects Version/s: | 2.0.2 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Perry Krug | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| 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. |
[CCBC-170] After upgrading to 2.0.2 with CBC163, I now get timesouts again!!! Created: 22/Jan/13 Updated: 06/Feb/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | library |
| Affects Version/s: | 2.0.2 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Michael Leib | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: | CentsOS 5.X, 64 Bit, libev version | ||
| Description |
|
I was using 2.0.0 beta3 with the patch for TIMEOUTS manually applied....this was working fine but I had high CPU. This ran for weeks (if not a month) without any
timeouts at all...I was the happiest with lcb as I had been in a long time. However, after getting some complaints from my server admins and NOC, I upgraded to 2.0.2 with the fix for high CPU... I rebuilt all modules and rolled to production. It's now been about 4 hours and I have received 2 timeouts as to where I had NONE for weeks without this change. The load is now normal though but somehow something has broken because of this fix. I looked at the change with CBC-163, but I don't see how this could have broken the code...but, it has - I promise. Can someone please take a look? HELP! |
| Comments |
| Comment by Michael Leib [ 06/Feb/13 ] |
|
I have changed my code around so that I have an ev_timer throttle the millions of lcb_get() requests that I need to make over multiple request chunks from a queue rather than doing it all in a single loop and then letting libev handle it all and that appears to be working. There is still be a problem with the latest code if you do millions of requests within a function call before control is returned to the libev event loop. This doesn't happen everytime, but it does happen frequently enough. Keeping the number of lcb_get() calls sitting on the event stack low makes a BIG difference. Once again, with the version that didn't have the high-load fix implemented worked great (except for the load)...when the fix was applied, large amounts of pending events cause TIMEOUT returns from lcb_get(), |
| Comment by Michael Leib [ 06/Feb/13 ] |
|
And, of course, event with an ev_timer throttle of .01 secs, performance is about 1/4 of what it was when I just threw everything on the queue - basically about 5k/sec throughput vs 20k/sec just focusing on lcb_get() returns. My CB Cluster (2 servers) is reporting 50K ops/sec consistently without issue. |
[CCBC-169] Handle 30x HTTP response code when chosen node doesn't have active vbuckets Created: 15/Jan/13 Updated: 05/Mar/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | library |
| Affects Version/s: | 2.0.2, 2.0.3 |
| Fix Version/s: | 2.1.0 |
| Security Level: | Public |
| Type: | New Feature | Priority: | Major |
| Reporter: | Sergey Avseyev | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Flagged: |
Release Note
|
||||||||
| Comments |
| Comment by Matt Ingenthron [ 15/Jan/13 ] |
| Changed the description to be clear that we should be handling more 30x codes. |
[CCBC-152] Provide lcb_check to (weakly) check for the existence of a key Created: 21/Dec/12 Updated: 21/Dec/12 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | library |
| Affects Version/s: | 2.0.1 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | New Feature | Priority: | Major |
| Reporter: | Mark Nunberg | Assignee: | Mark Nunberg |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
This API will be a variant of OBSERVE and shall do a simple probe against the master node to see if the key exists in cache.
We need to have this in libcouchbase as normal observe is implemented by 'broadcasting' to all the nodes |
[CCBC-145] Provide API for durability operations Created: 13/Dec/12 Updated: 21/Dec/12 |
|
| Status: | In Progress |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 2.1.0 |
| Security Level: | Public |
| Type: | New Feature | Priority: | Major |
| Reporter: | Mark Nunberg | Assignee: | Mark Nunberg |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
This feature will provide a callback-oriented API for durability (aka observe-poll) operations. Considering that the logic of implementing these operations has proved somewhat more complex than intended, it would be better to centralize this in libcouchbase.
The API will provide a "durability set" which is a group of keys to be monitored, a "per-key" callback for when each key reaches its persistence/durability requirements, a "set callback" for when all keys have been endured (or have encountered a condition in which no further retries can be made) |
[CCBC-144] Standardize view option handling Created: 12/Dec/12 Updated: 10/Jan/13 |
|
| Status: | In Progress |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | library |
| Affects Version/s: | None |
| Fix Version/s: | 2.1.0 |
| Security Level: | Public |
| Type: | New Feature | Priority: | Major |
| Reporter: | Mark Nunberg | Assignee: | Mark Nunberg |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Centralize view option conversion, validation, and construction so dependent code does not have to repeat the same boilerplate all the time. This makes it easier for client libraries to adapt to new view options, as well as provide common expected behavior with current options.
|
| Comments |
| Comment by Mark Nunberg [ 13/Dec/12 ] |
| http://review.couchbase.org/#/c/23249/ |
[CCBC-135] lcb_server_purge_implicit_responses: Assertion `nr == sizeof(req)' failed Created: 04/Dec/12 Updated: 14/Dec/12 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | library |
| Affects Version/s: | 2.0.0 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Mark Nunberg | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
core
|
| Description |
|
Cannot reproduce, this is all the info I have
FAIL GetMulti - MgetOrdered [tests/phpt/GetMulti/MgetOrdered.phpt] mnunberg@csure:/sources/lcb2.0-repo/php$ cat tests/phpt/GetMulti/*.out PHP_COUCHBASE_OK php: src/server.c:799: lcb_server_purge_implicit_responses: Assertion `nr == sizeof(req)' failed. *Might* be related to To reiterate again, I cannot reproduce this - I just happened to notice it |
| Comments |
| Comment by Mark Nunberg [ 05/Dec/12 ] |
|
#0 0x00007f4d29d00475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x00007f4d29d036f0 in *__GI_abort () at abort.c:92 #2 0x00007f4d29cf9621 in *__GI___assert_fail (assertion=0x7f4d28a88fd3 "nr == sizeof(req)", file=<optimized out>, line=799, function=0x7f4d28a893c0 "lcb_server_purge_implicit_responses") at assert.c:81 #3 0x00007f4d28a7ab53 in lcb_server_purge_implicit_responses (c=0x2c35ff0, seqno=34, end=1354691478793889000) at src/server.c:799 #4 0x00007f4d28a79a56 in lcb_server_destroy (server=0x2c35ff0) at src/server.c:394 #5 0x00007f4d28a74ba5 in lcb_destroy (instance=0x2c83ed0) at src/instance.c:347 #6 0x00007f4d28c9b836 in php_couchbase_res_dtor (rsrc=<optimized out>) at /sources/lcb2.0-repo/php/couchbase.c:43 #7 0x00000000006ae89e in list_entry_destructor (ptr=0x7f4d27d177d8) at /tmp/buildd/php5-5.4.4/Zend/zend_list.c:183 #8 0x00000000006ac6bd in zend_hash_del_key_or_index (ht=0xdb8750, arKey=0x0, nKeyLength=0, h=56, flag=753497888) at /tmp/buildd/php5-5.4.4/Zend/zend_hash.c:531 #9 0x00000000006ae9b1 in _zend_list_delete (id=14243) at /tmp/buildd/php5-5.4.4/Zend/zend_list.c:57 #10 0x000000000068fa5a in _zval_ptr_dtor (zval_ptr=0x7f4d27d175d8) at /tmp/buildd/php5-5.4.4/Zend/zend_variables.h:35 #11 0x00000000006bf947 in zend_object_std_dtor (object=0x7f4d27c9c978) at /tmp/buildd/php5-5.4.4/Zend/zend_objects.c:54 #12 0x00000000006bf979 in zend_objects_free_object_storage (object=0x7f4d27c9c978) at /tmp/buildd/php5-5.4.4/Zend/zend_objects.c:137 #13 0x00000000006c5693 in zend_objects_store_del_ref_by_handle_ex (handle=753383344, handlers=0x37a3) at /tmp/buildd/php5-5.4.4/Zend/zend_objects_API.c:220 #14 0x00000000006c56b3 in zend_objects_store_del_ref (zobject=0x7f4d27ca0b60) at /tmp/buildd/php5-5.4.4/Zend/zend_objects_API.c:172 #15 0x000000000068fa5a in _zval_ptr_dtor (zval_ptr=0x7f4d27cfc130) at /tmp/buildd/php5-5.4.4/Zend/zend_variables.h:35 #16 0x00000000006ac7b8 in zend_hash_destroy (ht=0x7f4d27cfd508) at /tmp/buildd/php5-5.4.4/Zend/zend_hash.c:560 #17 0x00000000006bf8ec in zend_object_std_dtor (object=0x7f4d27cb9900) at /tmp/buildd/php5-5.4.4/Zend/zend_objects.c:44 #18 0x00000000006bf979 in zend_objects_free_object_storage (object=0x7f4d27cb9900) at /tmp/buildd/php5-5.4.4/Zend/zend_objects.c:137 #19 0x00000000006c5693 in zend_objects_store_del_ref_by_handle_ex (handle=753383728, handlers=0x37a3) at /tmp/buildd/php5-5.4.4/Zend/zend_objects_API.c:220 #20 0x00000000006c56b3 in zend_objects_store_del_ref (zobject=0x7f4d27cb9100) at /tmp/buildd/php5-5.4.4/Zend/zend_objects_API.c:172 #21 0x000000000068fa5a in _zval_ptr_dtor (zval_ptr=0x7f4d27cb9a78) at /tmp/buildd/php5-5.4.4/Zend/zend_variables.h:35 #22 0x00000000006ac7b8 in zend_hash_destroy (ht=0x7f4d27cb9c58) at /tmp/buildd/php5-5.4.4/Zend/zend_hash.c:560 ---Type <return> to continue, or q <return> to quit--- #23 0x000000000069d9f7 in _zval_dtor_func (zvalue=0x7f4d27cb9d38) at /tmp/buildd/php5-5.4.4/Zend/zend_variables.c:43 #24 0x000000000068fa5a in _zval_ptr_dtor (zval_ptr=0x7f4d27e325b0) at /tmp/buildd/php5-5.4.4/Zend/zend_variables.h:35 #25 0x00000000006bf947 in zend_object_std_dtor (object=0x7f4d27cf8fa8) at /tmp/buildd/php5-5.4.4/Zend/zend_objects.c:54 #26 0x00000000006bf979 in zend_objects_free_object_storage (object=0x7f4d27cf8fa8) at /tmp/buildd/php5-5.4.4/Zend/zend_objects.c:137 #27 0x00000000006c51c7 in zend_objects_store_free_object_storage (objects=0xdb8880) at /tmp/buildd/php5-5.4.4/Zend/zend_objects_API.c:92 #28 0x000000000068ffbc in shutdown_executor () at /tmp/buildd/php5-5.4.4/Zend/zend_execute_API.c:297 #29 0x000000000069e9e5 in zend_deactivate () at /tmp/buildd/php5-5.4.4/Zend/zend.c:941 #30 0x000000000063e36a in php_request_shutdown (dummy=0x37a3) at /tmp/buildd/php5-5.4.4/main/main.c:1781 #31 0x0000000000748374 in do_cli (argc=0, argv=0x7fff0f1f03e5) at /tmp/buildd/php5-5.4.4/sapi/cli/php_cli.c:1174 #32 0x00000000004310ca in main (argc=32767, argv=0x2a5e210) at /tmp/buildd/php5-5.4.4/sapi/cli/php_cli.c:1361 (gdb) |
| Comment by Mark Nunberg [ 05/Dec/12 ] |
| Core Dump -- self-compiled versions of lcb and php-ext |
| Comment by Matt Ingenthron [ 14/Dec/12 ] |
|
Talking with Mark, he can't regularly repro this, but does still see it randomly
|
[CCBC-128] Allow semi-static bootstrapping Created: 19/Nov/12 Updated: 05/Mar/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | None |
| Affects Version/s: | 2.0.0beta2 |
| Fix Version/s: | 2.1.0 |
| Security Level: | Public |
| Type: | New Feature | Priority: | Major |
| Reporter: | Mark Nunberg | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
I'm marking this as critical because many folks seem to frown upon the high delays (read http connection latency) when establishing a new couchbase client.
In this case, this would be a constructor option available for lcb_create which will accept an opaque 'map file'. This 'map file' will really just be a dump of a vbucket configuration. What makes this different from compat mode is that the clients will bootstrap when a network error or timeout occurs. However in the normal model of spawn -> mc operation, where the cluster config is fairly static, there is no need for the latency induced by an extra http connection. We'd need to implement file-locking semantics to write to this file (we'd maybe just ask for a path to read/write the config to/from, perhaps checking the timestamp, too).. as we'd have multiple clients trying to read/write to this. This is simple enough in Unix This is in conjunction with a different discussion regarding how to best handle re-bootstrapping, where it was suggested that we really don't need the bootstrap connection in the first place. There are inherent risks involved with this approach, for example, if one specifies the wrong nodes, then we only know about this during the re-bootstrap. |
| Comments |
| Comment by Matt Ingenthron [ 19/Nov/12 ] |
|
I'm certainly not opposed to this idea, but I'm not sure about it being at the critical level. I do think it'd have to be portable though.
Sergey, what do you think? Is this a hotly needed feature? |
| Comment by Sergey Avseyev [ 20/Nov/12 ] |
| Frankly speaking I don't understand the benefit from dumping some configuration to the disk. It might be better to implement lcb_reconnect() and in this case the user just won't destroy lcb_t internal structs and reuse previous in-memory config. |
| Comment by Mark Nunberg [ 20/Nov/12 ] |
|
This is for performance enhancements, it's not directly related to failures, but can increase speed for some use cases dramatically, as it cuts out a lot of latency.
The idea is that the node map is static, so we don't need to have the initial HTTP connection. If you really want to be inventive, this can also use POSIX IPC instead of actual 'disk' (i.e. define a common shm path). The idea here in any event is to not depend so heavily on the REST connection in normal non-failure situations. |
| Comment by Matt Ingenthron [ 20/Nov/12 ] |
| While I think this makes sense, I do believe it can be deferred. |
| Comment by Matt Ingenthron [ 13/Feb/13 ] |
|
Let's see about this in the near future Sergey. We can discuss in our next sync up. |
[CCBC-111] Make iops functions 'private', and discourage calls to run_event_loop/stop_event_loop Created: 22/Oct/12 Updated: 10/Dec/12 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | library |
| Affects Version/s: | 2.0.0beta2 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Task | Priority: | Major |
| Reporter: | Mark Nunberg | Assignee: | Mark Nunberg |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
There's quite a bit of user code which calls io->run_event_loop and io->stop_event_loop.
These functions are largely private and are intended for use by libcouchbase itself. The fact that they are public API is only accidental, due to the fact that they are part of the iops structure. These functions should never be called by user code: 1) They are a source of confusion (especially when mixed with lcb_wait) 2) They prevent any kind of wrapping/sanity logic done by lcb_wait (some already exists, and some can be implemented in future versions) The following should be done 1) Remove the iops structure definition from being included by the main header file. Thus, #include <libcouchbase/couchbase.h> should not allow a dereference of the iops structure. Rather the iops structure should be defined in a new header file (iops.h) - so that users who want to explicitly manipulate and write event loop plugins can include it, but should otherwise not be present in 'user' code. types.h should include a predeclaration of the structure so that it may still be passed around as a simple pointer value. 2) Document the purpose of run_event_loop/stop_event_loop. Make it very clear that lcb_wait should be used in all synchronous use cases. If we have any examples using run_event_loop/stop_event_loop, remove them. 3) [ Optional? ] - In order to further discourage users from using these functions, throw a compiler warning/error for those functions unless LIBCOUCHBASE_INTERNAL is defined - tbd |
[CCBC-110] Implement lcb_reconnect() which will reconnect all dead sockets Created: 17/Oct/12 Updated: 20/Nov/12 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | library |
| Affects Version/s: | 2.0.0beta2 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Sergey Avseyev | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
This functionality very important for long-living connection handles
|
| Comments |
| Comment by Matt Ingenthron [ 20/Nov/12 ] |
|
This issue needs more of a description.
As discussed with Sergey, it's visible when using libcouchbase in a completely asynchronous app with an external event loop. According to Sergey, this does not affect any of our main use cases with Ruby/PHP/node and rebuilding the connection. |
[CCBC-108] Allow per-command retries for not-my-vbucket and other transient errors Created: 04/Oct/12 Updated: 10/Dec/12 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | None |
| Affects Version/s: | 2.0.0beta |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Mark Nunberg | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
We should avoid the possibility of 'infinite' errors and allow the user the ability of seeing the 'real' error which caused the command to fail..
http://review.couchbase.org/13177 |
[CCBC-127] libvbucket RPM is missing /usr/lib64/libvbucket.la file Created: 16/Nov/12 Updated: 16/Nov/12 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | library |
| Affects Version/s: | 1.0 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Tim Smith | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
libvbucket1-1.8.0.4-1
centos 5.5 couchbase repo x86_64 |
||
| Description |
|
The libvbucket1 rpm does not include the libvbucket.la file. The libcouchbase.la file references libvbucket.la as a dependency.
Linking via libtool against libcouchbase fails because of this. For example, compiling the php-ext-couchbase package fails like: /bin/sh /root/code/php-ext-couchbase/libtool --mode=link cc -DPHP_ATOM_INC -I/root/code/php-ext-couchbase/include -I/root/code/php-ext-couchbase/main -I/root/code/php-ext-couchbase -I/usr/include/php -I/usr/include/php/main -I/usr/include/php/TSRM -I/usr/include/php/Zend -I/usr/include/php/ext -I/usr/include/php/ext/date/lib -I/usr/include/ -DHAVE_CONFIG_H -g -O2 -o couchbase.la -export-dynamic -avoid-version -prefer-pic -module -rpath /root/code/php-ext-couchbase/modules compress.lo couchbase.lo fastlz/fastlz.lo -lz -lcouchbase grep: /usr/lib64/libvbucket.la: No such file or directory /bin/sed: can't read /usr/lib64/libvbucket.la: No such file or directory libtool: link: `/usr/lib64/libvbucket.la' is not a valid libtool archive make: *** [couchbase.la] Error 1 I created a fake libvbucket.la by copying /usr/lib64/libcouchbase.la and editing it, and it allowed the compile to succeed. |
[CCBC-116] Heavy errors during short network loss Created: 07/Nov/12 Updated: 14/Nov/12 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | library |
| Affects Version/s: | 2.0.0beta2 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Mark Nunberg | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
During network loss to the nodes, there are heavy network errors - a combination of both timed-out operations as well as operations which fail with a network error. Might we want to provide an option to retry these operations?
|
| Comments |
| Comment by Matt Ingenthron [ 14/Nov/12 ] |
| While this would be nice, I think failure of operations during network loss is okay as long as we highlight the loss up the chain appropriately. Leaving this as major. |
[CCBC-100] Allow Incremental Row Callbacks Created: 11/Sep/12 Updated: 08/Dec/12 |
|
| Status: | In Progress |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | library |
| Affects Version/s: | None |
| Fix Version/s: | 2.0.1 |
| Security Level: | Public |
| Type: | New Feature | Priority: | Major |
| Reporter: | Mark Nunberg | Assignee: | Mark Nunberg |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
View query results may return large amounts of data. We should offer a row callback which returns a JSON string whose contents is a single row.
There are awesome JSON libraries to do this task, and it's something that I've found myself doing in the Perl client.. so why not move it into libcouchbase and let everyone be happy? :). Basic idea: Two callbacks are put into place. The first is a 'row callback' which receives rows, and the second is a complete callback, at which time any other non-row data is returned as a JSON object. So for example { "total_rows" : 30, "rows" : [ { "id" : "foo" }, { "id" : bar" }, .... The row callback will first receive the string '{ "id" : "foo" }', then the second time around, '{"id":"bar"}' The complete callback will return: ' { "total_rows" : 30 } ' |
[CCBC-83] Update the getting started to match the Beer sample DB Created: 12/Jul/12 Updated: 18/Oct/12 |
|
| Status: | In Progress |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | docs |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Matt Ingenthron | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | 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 Matt Ingenthron [ 13/Sep/12 ] |
| Sergey: Can you update the getting started web page to do some gets/sets against the beer sample DB? |
| Comment by Sergey Avseyev [ 13/Sep/12 ] |
| Ok, will do it on staging |
| Comment by Matt Ingenthron [ 18/Oct/12 ] |
| I think this is closeable, right? |
[CCBC-84] Updated screencast for /develop pages Created: 12/Jul/12 Updated: 12/Jul/12 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Matt Ingenthron | Assignee: | Matt Ingenthron |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Create an updated screencast to ship with the new 2.0 developer SDKs
|
[CCBC-49] API reference is complete Created: 12/Jan/12 Updated: 10/Dec/12 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | docs |
| Affects Version/s: | 1.0 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | New Feature | Priority: | Major |
| Reporter: | Matt Ingenthron | Assignee: | Matt Ingenthron |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
[CCBC-205] Provide stricter semantics/behavior for configuration cache. Created: 30/Apr/13 Updated: 01/May/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | library |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Mark Nunberg | Assignee: | Trond Norbye |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
We may want to create a 'cache-only' mode in which creation of the client fails if the cache cannot be created (e.g. a bad path was passed, or the file is not writeable, etc.)
Currently, the cache is mostly a transparent extra, but there is no way for a user to determine whether the mechanism is at all working. |
[CCBC-3] libcouchbase lacks a tutorial Created: 15/Aug/11 Updated: 02/May/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | docs |
| Affects Version/s: | None |
| Fix Version/s: | 2.0.1 |
| Security Level: | Public |
| Type: | New Feature | Priority: | Major |
| Reporter: | Matt Ingenthron | Assignee: | Matt Ingenthron |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
libcouchbase lacks a tutorial document
|
| Comments |
| Comment by Karen Zeller [ 26/Mar/13 ] |
|
Dependencies, Blockers: -Need sample application for C SDK demonstrating CRUD and using Views from SDK. -Need technical notes and information on sample application. -Any related resources? |
| Comment by Karen Zeller [ 26/Mar/13 ] |
| See information required/dependencies. |
[CCBC-204] configuration cache does not work for memcached buckets Created: 29/Apr/13 Updated: 08/May/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | library |
| Affects Version/s: | 2.0.6 |
| Fix Version/s: | 2.1.0 |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Matt Ingenthron | Assignee: | Trond Norbye |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: | multiplatform | ||
| Description |
|
Currently, the configuration cache relies on not_my_vbucket responses as an indicator that the configuration needs to be updated. In an environment with memcached buckets only though, there will not be such a response and thus we need another way to reliably update the configuration.
One thought would be to simply ensure the configuration cache is not more than NN seconds old. The process who has the configuration connection would simply need to touch it every NN-1 seconds if the configuration connection is still active. If that process exits, then after NN seconds, processes will race to create a new configuration cache file. The only downside I can see is that certain failure modes (stale TCP socket) would still need to be handled. |
[CCBC-207] Failed connection attempts will hang until timeout interval is reached on win32 Created: 08/May/13 Updated: 08/May/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | library |
| Affects Version/s: | 2.0.6 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Task | Priority: | Major |
| Reporter: | Mark Nunberg | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Failed connection errors are not detected in the select() call. This is because the select call does not add the socket to the exception fdset.
MSDN documentation states that failed connections are delivered through exceptfds, and that only successful connections are delivered as writability notifications. See http://msdn.microsoft.com/en-us/library/windows/desktop/ms740141(v=vs.85).aspx |
[CCBC-198] Instance should close REST connection upon receiving valid config cache Created: 01/Apr/13 Updated: 11/May/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | library |
| Affects Version/s: | 2.0.5 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Mark Nunberg | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
If a valid config cache configuration is received, there is no point in keeping the REST socket open; (one of the reasons someone would even want to use a cached config is in order to reduce load from the server - so we should try to minimize connections in such cases).
Close the socket immediately (or eventually) if a valid configuration is obtained. Re-open as necessary. |
[CCBC-137] libcouchbase test improvements Created: 31/Aug/12 Updated: 11/May/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Task | Priority: | Major |
| Reporter: | Mark Nunberg | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| ÎŁ Remaining Estimate: | Not Specified | Remaining Estimate: | Not Specified |
| ÎŁ Time Spent: | Not Specified | Time Spent: | Not Specified |
| ÎŁ Original Estimate: | Not Specified | Original Estimate: | Not Specified |
| Sub-Tasks: |
|
| Description |
|
Generic improvements and fixes for libcouchbase test suite
|
libcouchbase test improvements
(CCBC-137)
|
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Technical task | Priority: | Major |
| Reporter: | Mark Nunberg | Assignee: | Mark Nunberg |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Comments |
| Comment by Farshid Ghods [ 31/Aug/12 ] |
|
1- timeout to a server that is down
2- timeout a server that is slow |
| Comment by Mark Nunberg [ 05/Sep/12 ] |
| Apparently there are some new tests for this already.. I'll document them again during next pass |
[CCBC-4] libcouchbase lacks sample applications Created: 15/Aug/11 Updated: 11/May/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | docs |
| Affects Version/s: | None |
| Fix Version/s: | 2.0.1 |
| Security Level: | Public |
| Type: | New Feature | Priority: | Major |
| Reporter: | Matt Ingenthron | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Libcouchbase requires sample applications for completeness.
|
| Comments |
| Comment by Trond Norbye [ 01/Sep/11 ] |
| This is not true. There are at least 4 sample applications in the source code: memcat, memcp, memrm and memdump |
| Comment by Matt Ingenthron [ 01/Sep/11 ] |
| This is on the "docs" component, and with all client libraries, we have a more comprehensive sample application, so you're correct, but there's more to it. |
| Comment by Sergey Avseyev [ 09/Apr/12 ] |
|
There is vacuum application https://github.com/trondn/vacuum and the corresponding blog post on Trond's blog http://trondn.blogspot.com/2012/01/so-whats-story-about-libcouchbase-and.html
Why use them in docs? |
| Comment by Mark Nunberg [ 28/Aug/12 ] |
|
From my experience in answering developers' questions regarding libcouchbase, I don't think sample applications would be as helpful as providing common code idioms, such as ways to handle multi-get, ways to handle errors; things like expiry etc.
It would take quite a bit to write a useful "application" for libcouchbase, so let's just stick to idioms for now.. and assume our readers know how to program in C :) |
libcouchbase test improvements
(CCBC-137)
|
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Technical task | Priority: | Major |
| Reporter: | Mark Nunberg | Assignee: | Mark Nunberg |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
[CCBC-210] segfault from lcb_wait and libev Created: 10/May/13 Updated: 16/May/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | None |
| Affects Version/s: | 2.0.6 |
| Fix Version/s: | 2.1.0 |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Matt Ingenthron | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
When running a test with a broken cluster, I happened to have PHP segfault after a long, long wait.
#0 0xffffffffffffffff in ?? () #1 0x00002aab69d1fab4 in ?? () from /usr/lib64/libcouchbase.so.2 #2 0x00002aab69d16421 in ?? () from /usr/lib64/libcouchbase.so.2 #3 0x00002aab6b271e73 in ev_invoke_pending () from /usr/lib64/libev.so.4 #4 0x00002aab6b276688 in ev_run () from /usr/lib64/libev.so.4 #5 0x00002aab6b06dd86 in ?? () from /usr/lib64/libcouchbase_libev.so #6 0x00002aab69d1e698 in lcb_wait () from /usr/lib64/libcouchbase.so.2 #7 0x00002aab69af22b3 in php_couchbase_view_impl (ht=2, return_value=0x178de850, return_value_ptr=0x0, this_ptr=0x178dcf28, return_value_used=1, oo=1, uri_only=0) at /tmp/tmpwlG54H/couchbase-1.1.5/views.c:347 #8 0x00002aab69adfe86 in zim_couchbase_view (ht=395387424, return_value=0x1, return_value_ptr=0x11, this_ptr=0x0, return_value_used=16) at /tmp/tmpwlG54H/couchbase-1.1.5/apidecl.c:768 #9 0x00000000005e78e9 in ?? () #10 0x00000000005bd9ab in execute () #11 0x0000000000599f45 in zend_execute_scripts () #12 0x000000000054ad48 in php_execute_script () #13 0x0000000000622cde in ?? () #14 0x0000003d16a1d994 in __libc_start_main () from /lib64/libc.so.6 #15 0x0000000000421789 in _start () |
| Comments |
| Comment by Matt Ingenthron [ 10/May/13 ] |
| by the way, I always seem to get libev when installing libcouchbase2 on CentOS 5.8. It has libevent 1.4. Is this normal? |
| Comment by Sergey Avseyev [ 16/May/13 ] |
|
libcouchbase2 depends on virtual package libcouchbase2-backend, which is provided by libcouchbase2-libev and libcouchbase2-libevent. I think it picks libev version because of alphabetical order. By the time I've written package description I cannot found how to write alternaltion rule, like for DEB packages (which is also ordered) https://github.com/couchbase/libcouchbase/blob/master/packaging/deb/control#L58. $ ls -1 libcouchbase2-2.0.6-1.x86_64.rpm libcouchbase2-bin-2.0.6-1.x86_64.rpm libcouchbase2-core-2.0.6-1.x86_64.rpm libcouchbase2-libev-2.0.6-1.x86_64.rpm libcouchbase2-libevent-2.0.6-1.x86_64.rpm libcouchbase-debuginfo-2.0.6-1.x86_64.rpm libcouchbase-devel-2.0.6-1.x86_64.rpm |
| Comment by Sergey Avseyev [ 16/May/13 ] |
| and the stacktrace not complete, is it possible to install debug symbols and reproduce it? |
[CCBC-214] Re-design internal operations in a queue/linked list structure Created: 21/May/13 Updated: 21/May/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | library |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Mark Nunberg | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
[CCBC-213] Unify internal connect() routines Created: 21/May/13 Updated: 21/May/13 |
|
| Status: | In Progress |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | library |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Mark Nunberg | Assignee: | Mark Nunberg |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
This will unify the connection routines in terms of error handling and callback invocations.
|
[CCBC-215] Test whether server gets reconnected when user idle for longer than timeout interval Created: 22/May/13 Updated: 22/May/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Task | Priority: | Major |
| Reporter: | Mark Nunberg | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
see inline discussion here: http://review.couchbase.org/#/c/26462/2/src/timeout.c
Basically, the semantics of the timeouts aren't clear - the timeout will unconditionally purge the server and disconnect if the timeout hits, even if there is nothing waiting. In practice this might not be a bug, but it means needless connection code to the server (and SASL auth) is being executed each time. |
[CCBC-211] libcouchbase may touch a failed node after failover Created: 21/May/13 Updated: 21/May/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | library |
| Affects Version/s: | 2.0.6 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Ivan Chernetsky | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: | Observed on CentOS (details in the description) | ||
| Description |
|
Library version: v2.0.6 (compiled from the source code, on x64)
Server version: v2.0.1 Number of nodes in my test setup: 3 (2 x CentOS 6.2 x64, and 1 x CentOS 5.8 x86, if it's of any relevance) Steps to reproduce: 1. Create a new cluster 2. Print the returned value by lcb_get_server_list function (there shoud be 3 servers printed) 3. Bring down network on one of servers 4. Try to put several values, until one of them is routed to the failed node. The library should return an error, which is expected. 5. Repeat 2 6. Manually fail over the failed node. 7. Print the returned value by lcb_get_server_list function (there should be 2 servers printed) 8. Try to put several values, until one of them is routed to the failed node. This behaviour is not expected. 9. Start rebalance. 10. While rebalancing takes place, a request might be routed to the failed node. It is not expected as well. 11. Once rebalance is completed, no requests are routed to the failed node. It is as expected. Thanks in advance for your support. |
[CCBC-216] Change 'lcb_wait' semantics Created: 22/May/13 Updated: 22/May/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | library |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Task | Priority: | Major |
| Reporter: | Mark Nunberg | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
Currently we have 'wait' and 'breakout' which is optimized and termed for a synchronous model.
We should rename these functions (though we can still maintain aliases) to something like: lcb_operations_flush: Which indicates that the user has finished sending requests, and that packets should be sent And: lcb_operations_done_callback Which will be called when the operations have been completed. Effectively this is the same as lcb_wait and the stop_event_loop callback, but the usage and purpose of those two existing functions aren't clear. |
[CCBC-212] IO Enhancements Created: 21/May/13 Updated: 22/May/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Epic | Priority: | Major |
| Reporter: | Mark Nunberg | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Epic Name: | IO Enhancements | ||||||||||||||||
| Description |
|
This super bug is an umbrella task for refactoring our IO system to be more streamlined, readable, and compatible with other I/O models.
|
[CCBC-129] Add libevent support for win32 Created: 20/Nov/12 Updated: 21/Nov/12 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | None |
| Affects Version/s: | 2.0.0beta2 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | New Feature | Priority: | Minor |
| Reporter: | Brett Harrison | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
win32libevent.zip
|
| Description |
|
I created a NMakefile and made changes to the code to support libevent on windows.
Files affected: iofactory.c plugin-libevent.c New file: NMakefile.libevent I uploaded a zipfile of the changes if you are interested in merging them. |
| Comments |
| Comment by Sergey Avseyev [ 21/Nov/12 ] |
| it would be awesome if you can move your patch to our review system. http://review.couchbase.com |
| Comment by Brett Harrison [ 21/Nov/12 ] |
| Is there a guild on how to use the review system? If you can explain the steps I'll upload the patch. |
| Comment by Matt Ingenthron [ 21/Nov/12 ] |
|
It's roughly http://www.couchbase.com/wiki/display/couchbase/Contributing+Changes
Repo tool isn't required for this project though |
| Comment by Matt Ingenthron [ 21/Nov/12 ] |
| Also, Brett: saw your CLA on review.couchbase.org and you're all set. |
[CCBC-101] allow google test suite to be preserved between invocations of make distclean and friends Created: 18/Sep/12 Updated: 18/Sep/12 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Mark Nunberg | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
additionally we should make it into a DSO and link the tests against that.. would make it somewhat quicker..
This is obviously not a major issue.. but would be nice :) |
[CCBC-78] Improved Sample Code for "Simple Example" Created: 05/Jul/12 Updated: 05/Jul/12 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | library |
| Affects Version/s: | 1.0 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Karen Zeller | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | customer | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: | all platforms | ||
| Description |
|
Hi,
I received a variety of content corrections from a customer for the C SDK. I made all possible, however some require changes in the sample code the SDK Team provides. The existing sample code is here: http://www.couchbase.com/docs/couchbase-sdk-c-1.0/simple_example.html The customer requests: - The tutorial example bails from callbacks with exit(), rather than passing control back to main (after setting a global flag, for example, or one passed in via the cookie, etc.). - The tutorial should also show use of libcouchbase_remove() and what to expect from libcouchbase_mget() afterwards (the latter is in the Python docs, but not the C docs). - The tutorial should use libcouchbase_destroy(). - Some mention of whether a disconnect is needed or not would be appropriate. Let me know if you are able to demonstrate use of these other methods in the sample code and send the code. I will add the new sample and document. Also let me know if a C client needs to be destroyed and if so how. |
[CCBC-161] libcouchbase_flush wrongly documented to "flush entire cluster" Created: 03/Jan/13 Updated: 02/May/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | docs |
| Affects Version/s: | 2.0.1 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Bug | Priority: | Minor |
| Reporter: | Tim Smith | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: | http://www.couchbase.com/docs/couchbase-sdk-c-2.0/api-reference-summary.html#table-couchbase-sdk-c-summary | ||
| Description |
|
The docs say that libcouchbase_flush() will "Flush the entire cluster" and "libcouchbase_flush may be used to remove all key/value pairs from the entire cluster."
It actually flushes a bucket, not the entire cluster. |
[CCBC-206] Improve libcouchbase rpm instructions Created: 19/Feb/13 Updated: 02/May/13 |
|
| Status: | Open |
| Project: | Couchbase C client library libcouchbase |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Improvement | Priority: | Minor |
| Reporter: | James Mauss | Assignee: | Sergey Avseyev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | info-request | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
There is currently no documentation about installing libcouchbase from the rpm or deb files.
The only documentation is for installation with yum or apt-get. Since some packages are optional, more instructions would be nice. |
| Comments |
| Comment by Karen Zeller [ 28/Mar/13 ] |
|
Hi,
Can you point me to any information about rpm install for the SDK on github, or anywhere else. Assign back to me to document. Thanks, Karen |
| Comment by Karen Zeller [ 02/May/13 ] |
|
Can you close this and reopen this under the Couchbase C Client Library project?
We're doing massive housekeeping on docs requests and want to keep this separate from server. Thanks! |
[CCBC-139]