[CCBC-317] Consolidate lcb_list_t and lcb_clist_t Created: 03/Feb/14  Updated: 03/Feb/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: 2.3.0-dp2
Fix Version/s: .future
Security Level: Public

Type: Bug Priority: Blocker
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   
We should split our our list implementation to a node type (next/prev) and a list type (which also contains size and some other metadata).




[CCBC-360] date mutated in libcouchbase's send buffer Created: 08/Apr/14  Updated: 13/Apr/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.2.0
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Blocker
Reporter: killgxlin Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: usability
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: libcouchbase-2.2.0
couchbase-server 2.2.0
ubuntu 13.04 g++ 4.8.1

Attachments: File key_3423.base64     File key_3423.hexdump     File key_3423.json    

 Description   
while true
  set 1000 json document to couchbase-server
  get 1000 json documents from couchbase-server
  some of them may become invalid json document

the test code is here https://github.com/killgxlin/libcouchbase_testcode
i think it may be a bug of libcouchbase. if not it may be a bug of myself ,please point out and mail me
killgxlin@hotmail.com please.

broken document is in attachment
key_*.base64 is the broken document saved in couchbase-server
key_*.json is a broken json which decoded from key_*base64,
key_*.hexdump is a hexdumped text from broken key_*.json

by watch key_*.hexdump i could see that the past of the document is overwroted by a network msgof couchbase which head is 80 01 PROTOCOL_BINARY_REQ PROTOCOL_BINARY_CMD_SET

 Comments   
Comment by Sergey Avseyev [ 13/Apr/14 ]
https://github.com/couchbase/libcouchbase/pull/13




[CCBC-377] Handle API/ABI modifications from 2.x => 3.0/2.4 Created: 20/Apr/14  Updated: 20/Apr/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: 2.4.0
Fix Version/s: 2.4.0
Security Level: Public

Type: Task Priority: Blocker
Reporter: Mark Nunberg Assignee: Mark Nunberg
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:
Key
Summary
Type
Status
Assignee
CCBC-378 lcb_socket_t is DWORD on Win32, not int Technical task Open Mark Nunberg  

 Description   
This is a parent task for handling/documenting API/ABI changes and removals between those versions.




[CCBC-325] Provide ability to fail fast on unserviceable requests Created: 14/Feb/14  Updated: 14/Feb/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: None
Fix Version/s: None
Security Level: Public

Type: New Feature Priority: Critical
Reporter: Brett Lawson Assignee: Matt Ingenthron
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
A customer wishes to be able to 'fail-fast' on operations which are known to be currently unserviceable (connection to node which will handle the operation is currently unavailable).

I see a few possible options to allow this to happen:
1. Provide a configuration option or flag that the customer can specify that will cause libcouchbase operations to fail fast in instances where it knows that an operation will need to be queued rather than processed immediately.
2. Alternatively, we can also provide a per-operation option which has the same effect as option 1.
3. We can provide a method to identify if an operation against a specific key will be destined for a server which we do not currently have a connection for
4. We can suggest that the customer make alterations to their platform such that operations are performed asynchronously. This would allow them to queue operations inside libcouchbase without any worry of blocking further operations from occurring. This has a nice side effect of likely allowing more than one operation to be performed simultaneously and increasing throughput, though there may be synchronization issues that may prevent this from being a viable option.


 Comments   
Comment by Mark Nunberg [ 14/Feb/14 ]
Several problems with this.

(1) At the library level we have no idea if a request is unserviceable or not. Connections are scheduled on-demand initially as well as after a configuration change.

(2) In the event of a socket error, the command chain is failed out. However, the next request to that server triggers a reconnect.

(3) If we know in advance that a node is down or not present in the vbucket map, the library fast-fails already

The "Negative caching" mechanism is the only way this can be implemented. Basically:

(1) Specify how many connection attempts/errors on a socket would be needed in order to mark a socket as "Dead".
(2) Specify a grace interval in wall time that would indicate how often to re-check the connection again.
(3) On a successful connection attempt, the flag would be cleared. Note however that this does not do well with flapping links.
Comment by Brett Lawson [ 14/Feb/14 ]
When we go to dispatch an operation, we can tell at that point whether the socket for that server is connected or not, if it is not, they just wish for it to fail fast rather than queuing it while it waits for a connection to be established my connmgr.
Comment by Mark Nunberg [ 14/Feb/14 ]
And how would reconnections be made?
Comment by Brett Lawson [ 14/Feb/14 ]
Well, I would expect that when the connection drops we retry to connect anyways?
Comment by Matt Ingenthron [ 14/Feb/14 ]
The other proposal was that there be a flag or options to do fail fast or really try. The idea being that the app may have some situations where it wants to manage retrying things that couldn't complete to a later date.




[CCBC-309] Infinite loop in lcb_wait function when 1 node in cluster is off Created: 30/Jan/14  Updated: 31/Jan/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.2.0
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Critical
Reporter: Haster Assignee: Subhashni Balakrishnan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Couchbase claster with 2 nodes on Windows (couchbase version 2.1.1)
Client use libcouchbase 2.2.0 and plugin iocp or select


 Description   
How to reproduce:
1) Start claster
2) Shutdown 1 node by stopping couchbase service
3) try to connect to that node

I have investigate this problem on select plugin:
the problem is that in this case method select return 1 (exceptfds == 1) and as a result reconnect method
and so on

 Comments   
Comment by Mark Nunberg [ 31/Jan/14 ]
I believe, but have not verified that this should be fixed in 2.3.0
Comment by Matt Ingenthron [ 31/Jan/14 ]
Subhashni: let's review where we can get this into the test cycle.
Comment by Mark Nunberg [ 31/Jan/14 ]
Don't test this until we have a commit sha




[CCBC-304] mystery query time out and views_timeout Created: 30/Dec/13  Updated: 08/Jan/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.2.0
Fix Version/s: None
Security Level: Public

Type: New Feature Priority: Critical
Reporter: Tao Wei Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on PYCBC-213 Expose LCB_CNTL integer constants Resolved

 Description   
Hi,

Many people have reported that queries are broken due to mystery time out, while the server's load is not heavy, even with only 1 client. But there is no clear explanation yet. Unfortunately, I hit the same bug and have to dig it myself.

After digging into the libcouchbase source code, I found that there is a field called views_timeout in the lcb instance set in lcb_create():

    obj->views_timeout = LCB_DEFAULT_VIEW_TIMEOUT; // 75000000 -> 75 sec

And lcb_http_request_connect() sets it as the connection timeout:

    conn->timeout.usec = req->instance->views_timeout;

Thus, all queries longer than 75 sec will be interrupt by the timer.

We can use lcb_set_view_timeout() to set a longer views_timeout. Unfortunately, there is no doc in couchbase.com to describe this:

   https://www.google.com/search?q=lcb_set_view_timeout+site%3Acouchbase.com

And there is no such an interface exposed by the python client library.

I suggest that we need to add this interface to python client libraries, and add a doc into related documents.


thanks,

Lenx

 Comments   
Comment by Matt Ingenthron [ 30/Dec/13 ]
Agreed, this should be tuneable.

Tao: it'd be unusual for a view query to take that long except under heavy load or initial index build. That seems to be the problem that you should look into. The logging at the cluster will probably give you some more information and adding debug = true will log more information.
Comment by Tao Wei [ 30/Dec/13 ]
Hi Matt,

We use couchbase as a data warehouse. Thus, we need long queries to get some stats.

thanks,

Lenx
Comment by Matt Ingenthron [ 30/Dec/13 ]
That may be, but Couchbase is always building the views in background by default. Is your view query using stale=false?
Comment by Tao Wei [ 30/Dec/13 ]
Hi Matt,

Sure, we have used "stale=ok", but there are 20M records we need to go through.

thanks,

Lenx
Comment by Mark Nunberg [ 30/Dec/13 ]
This is unfortunately not yet tunable via the Python extension. I've added a PYCBC to resolve this; and it's simply a matter of exposing the correct timeout value.

Comment by Matt Ingenthron [ 30/Dec/13 ]
Tao: I guess that's where I'm confused because the default with Couchbase buckets is that they update the views all the time. The frequency to this is tuneable. The "stale=false" would only matter in situations where some documents have been updated since the most recent auto-update. We can increase the frequency of the auto-update perhaps.

Are you saying that you're dumping in a whole bunch of data and then doing a stale=false query? That's the only way I can see that you'd hit this timeout in normal operations.
Comment by Tao Wei [ 30/Dec/13 ]
Hi Matt: I fixed a typo in my reply. I use "stale=ok" in those queries. We have stored a lot of data into couchbase first, and then we want to do some analysis based on those data. Thus, we need to go through records according to some views.
Comment by Matt Ingenthron [ 30/Dec/13 ]
A stale=ok query should be quite fast, so we may have to look elsewhere for what is causing it to exceed the timeout. Note that on the cluster side, the query execution timeout is 60 seconds, so just turning up the timeout at the client won't address the core problem.
Comment by Tao Wei [ 30/Dec/13 ]
Matt, we have about 24M records. After setting views_timeout to 30min, the client took about 19 min to go through all those records. Here is the output:

# time ./couch_test

count:23977620

real 18m21.663s
user 0m49.199s
Comment by z r [ 07/Jan/14 ]
Hi,
I faced the same problem too:
based on your comments I wrote a
C program which sets the view_timeout to a higher limit, I verified that
it is doing the right thing, however the set value does not seem to take effect on subsequent connections. So my
theory is that the set_view_timeout is per connection and it reverts back to its default
value for subsequent connections.

The get_view_timeout returns the value which I set.
My question to you is did you have to do anything more before the views started
timing out after your specified value which was 30 mins.

My workflow is :
1.Call c program from python to set view_timeout
2. continue with python prog to iterate over view results.

I tried the view both with stale=False and True. Thanks very much for your time and please let me know if you see anything amiss.

This is what my code looks like in main:
1.lcb_wait(instance);
2.int k = 90000000;
3.lcb_set_view_timeout(instance,k);
4.int set_timeout = lcb_get_view_timeout(instance);
5.printf("after setting view timeout, value retrieved from server.\n");
6.printf("%d",set_timeout); // Fetches 90000000 as expected, if I run this by commenting line 6 I get 75000000 which is the default value, not sure how to make the new timeout value persist

return 0;

Comment by Mark Nunberg [ 08/Jan/14 ]
The python-level APIs to expose these values are now present (see PYCBC-213 and PYCBC-218). I'm moving this to CCBC as it belongs there now.




[CCBC-336] observe operations may not be retried when NMV received Created: 24/Feb/14  Updated: 24/Feb/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.0.0, 2.1.0, 2.1.1, 2.1.2, 2.1.3, 2.2.0, 2.3.0-dp2
Fix Version/s: .future
Security Level: Public

Type: Bug Priority: Critical
Reporter: Matt Ingenthron Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency

 Description   
During investigation of an issue, Mark Nunberg found that observe replies with NMV may not be retried in libcouchbase. Further, the differentiation between NMV and -1 (i.e., no node in this position) isn't clear from the way the library currently handles things.

The correct behavior is that on any NMV, the library will retry using an updated configuration. This will happen until timeout.

As a workaround, check for the state with a get() or retry the observe() at an application level until successful. It's recommended to retry with some kind of rate limiting and a maximum.





[CCBC-233] Provide new version of arguments with common ABI header Created: 26/Jul/13  Updated: 25/Feb/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.0.7
Fix Version/s: None
Security Level: Public

Type: Task Priority: Critical
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   
Our current argument structure doesn't have a simple ABI for common fields. This results in duplicate code for almost all implementations using libcouchbase because they must make sure that common fields such as "key" and "nkey" (and possibly also "cas") are dereferenced correctly in each structure.

A new version of arguments should be added which would unify the common fields of all commands, and allow code to "cast" the command structure to a common base type.

This also ties in to the C++ wrappers in which I'm forced to currently either use templates or use virtual if I am going to properly deal with fields




[CCBC-347] Should saslPassword be removed from configuration? Created: 17/Mar/14  Updated: 19/Mar/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.2.0
Fix Version/s: None
Security Level: Public

Type: Task Priority: Critical
Reporter: Brent Woodruff Assignee: Mark Nunberg
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate

 Description   
Configuration information pulled from a Couchbase node contains "saslPassword": "password_in_plaintext". This occurs for every client, as far as I am aware, but I am raising this issue under libcouchbase specifically because of the configuraiton cache.

When the configuration cache is in use, the results of pulling the configuration from a node are stored on disk. This file is created according to the user's environment - the user creating it, their umask, setgid bits, ACLs, and so forth. Without careful attention to detail, it is likely that the bucket sasl password can become unintentionally exposed by default file security.

For example, on Linux, the default umask for users is usually 022, resulting in world readable files. While access to the file would require some level of shell access, this may still be less than desirable. Also, even though there may be suitable workarounds by applying filesystem level protections (setting umask, creating the cache file in a directory with reduced permissions), the presence of the sasl password in the response in plain text may not be at all necessary and should be removed.

Can we remove "saslPassword" from the response safely? Should it be hashed or otherwise protected in the response? If not, should we address the cache file security separately?




[CCBC-344] add support for SSL to libcouchbase in support of Couchbase Server 3.0 Created: 10/Mar/14  Updated: 27/Mar/14

Status: In Progress
Project: Couchbase C client library libcouchbase
Component/s: docs, library
Affects Version/s: None
Fix Version/s: .future
Security Level: Public

Type: New Feature Priority: Critical
Reporter: Matt Ingenthron Assignee: Brett Lawson
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks MB-10084 Sub-Task: Changes required for Data E... Open

 Description   
In support of Couchbase Server 3.0, please add SSL support to the client library. Check with the requirements repo and/or Aliaksey K. for pointers to information on this feature.

If the integration is complex, it may be useful to get an initial version for testing purposes and then get the integration complete for a future release.

Note this should include man page coverage of how to enable the feature.

 Comments   
Comment by Brett Lawson [ 20/Mar/14 ]
Due to the nature of the numerous IO paths within libcouchbase, this feature is non-trivial to implement. There is currently a significant amount of refactoring taking place in regards to the IO handling within the library by @mnunberg and because of this I have put this on hold temporarily until everything has stabilized. In the interim, I have however tested SSL support with my javascript-only client library written for Node.js, and the server itself appears to behave correctly in regards to handling SSL connections and performing operations across this connection.

Cheers, Brett




[CCBC-357] Authentication Errors during rebalance Created: 07/Apr/14  Updated: 09/Apr/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.0-dp2
Fix Version/s: .future
Security Level: Public

Type: Bug Priority: Critical
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   
Authentication errors may be delivered to the application during a rebalance and while CCCP is being employed. This is caused when the operation is forwarded to a new node before the asynchronous reconfiguration of the client has taken place.




[CCBC-365] Restore syncmode functionality (if needed) Created: 15/Apr/14  Updated: 16/Apr/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: .future
Fix Version/s: .future
Security Level: Public

Type: Task Priority: Critical
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: packet-ng
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Matt Ingenthron [ 16/Apr/14 ]
Curious, what does this one mean?
Comment by Mark Nunberg [ 16/Apr/14 ]
In the process of converting the operations to use an entirely different buffer and object system, much of the code has been isolated so far from the "Core" with the aim of creating isolated and well defined modules within the library itself.

The "Syncmode" was introduced in 1.x and its entire purpose is to implicitly call lcb_wait() after each operation. As such it provided a fairly intrusive and cumbersome internal API to be had.

It is optional behavior and the only thing that relies on it currently is the PHP extension - though it would be about 10 minutes work to adapt the PHP extension to call lcb_wait explicitly. We've removed/disabled this either temporarily or indefinitely (the bug is basically here to provide a reminder to restore it if needed) depending on how compatible packet-ng will end up being.
Comment by Matt Ingenthron [ 16/Apr/14 ]
Thanks for the description. It's only broken in .future I'll assume since that's what the bug says.




[CCBC-367] Couchbase::Error::Invalid: failed to schedule document request (key="/pools/default/buckets/default/ddocs", error=0x07) after upgrade to 2.3 Created: 16/Apr/14  Updated: 17/Apr/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: 2.3.0
Fix Version/s: 2.3.1
Security Level: Public

Type: Task Priority: Critical
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   
http://www.couchbase.com/communities/q-and-a/error-after-updating-libcouchbase-22-23

Assigning to sergey first to see if this is not a ruby issue. I've tried something similar on Python and have it working as expected.

 Comments   
Comment by Mark Nunberg [ 16/Apr/14 ]
This works similarly the same inside libcouchbase:

from couchbase.admin import Admin
Admin("Administrator", "123456").http_request("/pools/default/buckets/default/ddocs")


Sergey, are using the 'raw' request? Maybe that's the issue.
Comment by Sergey Avseyev [ 17/Apr/14 ]
This is libcouchbase bug.

https://github.com/couchbase/libcouchbase/blob/master/src/http.c#L475 lcb_confmon_get_rest_host(instance->confmon); returns NULL as host, therefore it will get invalid base ":" later in https://github.com/couchbase/libcouchbase/blob/master/src/http.c#L481
Comment by Sergey Avseyev [ 17/Apr/14 ]
and ruby uses management request to get list of design documents




[CCBC-364] cbc-pillowfight slow during topology changes Created: 15/Apr/14  Updated: 17/Apr/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.0
Fix Version/s: 2.3.1
Security Level: Public

Type: Task Priority: Critical
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   
When using CCCP, pillowfight exhibits a performance drop during a topology change. This may be related to not comparing the rev of various configurations received.



 Comments   
Comment by Mark Nunberg [ 15/Apr/14 ]
This _may_ be related to CCBC-332 - but I'm not sure at the moment.
Comment by Mark Nunberg [ 15/Apr/14 ]
Workaround is to use -C HTTP




[CCBC-370] lcb_get_host/lcb_get_port may not return host:port for same host Created: 17/Apr/14  Updated: 17/Apr/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.0
Fix Version/s: 2.3.1
Security Level: Public

Type: Task Priority: Critical
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   
These two API calls select a host at random if there is no current "Rest Host"




[CCBC-372] FORWARDPORT (2.4) - Couchbase::Error::Invalid: failed to schedule document request (key="/pools/default/buckets/default/ddocs", error=0x07) after upgrade to 2.3 Created: 17/Apr/14  Updated: 17/Apr/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: 2.3.0
Fix Version/s: 2.4.0
Security Level: Public

Type: Task Priority: Critical
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   
http://www.couchbase.com/communities/q-and-a/error-after-updating-libcouchbase-22-23

Assigning to sergey first to see if this is not a ruby issue. I've tried something similar on Python and have it working as expected.

 Comments   
Comment by Mark Nunberg [ 17/Apr/14 ]
CCBC-367




[CCBC-373] FORWARDPORT (2.4) - lcb_get_host/lcb_get_port may not return host:port for same host Created: 17/Apr/14  Updated: 17/Apr/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.0
Fix Version/s: 2.4.0
Security Level: Public

Type: Task Priority: Critical
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   
These two API calls select a host at random if there is no current "Rest Host"

 Comments   
Comment by Mark Nunberg [ 17/Apr/14 ]
CCBC-370




[CCBC-374] Implement SSL Transport For 3.0 Server Created: 17/Apr/14  Updated: 17/Apr/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: None
Fix Version/s: 2.4.0
Security Level: Public

Type: Task Priority: Critical
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-375] Migrate to Doxygen Created: 17/Apr/14  Updated: 17/Apr/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: docs
Affects Version/s: None
Fix Version/s: 2.4.0
Security Level: Public

Type: Task Priority: Critical
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





Handle API/ABI modifications from 2.x => 3.0/2.4 (CCBC-377)

[CCBC-378] lcb_socket_t is DWORD on Win32, not int Created: 20/Apr/14  Updated: 20/Apr/14

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: Critical
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-376] Memory leak in cJSON/VBucket config parsing Created: 20/Apr/14  Updated: 20/Apr/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.0
Fix Version/s: 2.3.1, 2.4.0
Security Level: Public

Type: Bug Priority: Critical
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-324] Core dump script analyser Created: 13/Feb/14  Updated: 13/Feb/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.2.0
Fix Version/s: None
Security Level: Public

Type: New Feature Priority: Major
Reporter: Patrick Varley Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: customer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Reading core dumps can be painful without access to the machine that created them.

On the server we have a script that allows a user to grab some useful information about the core dumps from memcached.

I think it would be useful to have the same thing for the library.




[CCBC-318] Allow support for keystats Created: 06/Feb/14  Updated: 06/Feb/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: None
Fix Version/s: .future
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


 Comments   
Comment by Mark Nunberg [ 06/Feb/14 ]
This would basically be a subset of 'stats' where each command would be directed only to its vbucket master (and replica?)




[CCBC-315] Place environment variables in public headers Created: 03/Feb/14  Updated: 03/Feb/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: None
Fix Version/s: .future
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


 Description   
Environment variables should be placed inside headers with documentation to provide more visibility to users




[CCBC-312] Add a public API to obtain replica status of a vbucket Created: 31/Jan/14  Updated: 09/Feb/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.2.0
Fix Version/s: None
Security Level: Public

Type: Improvement Priority: Major
Reporter: Dave Rigby Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on CCBC-319 expose vbucket symbols Resolved
Relates to
relates to CCBC-311 lcb_observe_poll: Unable to distingui... Resolved

 Description   
Customer wants to be able to find out the replica node(s) of a given key (i.e. vbucket). They can do this for *active* nodes using cv_cntl(LCB_CNTL_VBMAP), but there is currently no public API to get this information for replicas (from what I can tell).

This can be achieved using the internal libvbucket API, for example:

    VBUCKET_CONFIG_HANDLE config;
    lcb_cntl(instance, LCB_CNTL_GET, LCB_CNTL_VBCONFIG, &config);
                                                                                                                                                                                                                                                                                                                                                                
    int vbucket_id;
    int server_idx;
    int replica;
    vbucket_map(config, key, nkey, &vbucket_id, &server_idx);
    replica = vbucket_get_replica(config, vbucket_id, server_idx);
    fprintf(stdout, "Replica for '%.*s' is: %d.\n", nkey, key, replica);


However libvbucket isn't currently public.

 Comments   
Comment by Mark Nunberg [ 09/Feb/14 ]
We've just exposed the proper symbols for libvbucket, however the other half of the deal is to provide them inside the header files.




[CCBC-306] Assertion `c->cmd_log.nbytes' against 1.8 Created: 05/Dec/13  Updated: 14/Jan/14

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: Tommie McAfee Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: couchbase 1.8
threaded client

Attachments: Zip Archive 10.3.4.202-1252013-1122-diag.zip     Zip Archive 10.3.4.203-1252013-1124-diag.zip     Zip Archive 10.3.4.208-1252013-1121-diag.zip    

 Description   
System-test started using gcouchbase as it's loader.
(https://github.com/couchbase/testrunner/blob/master/pysystests/consumer.py)

During a run against 1.8 there was assert thrown during a create-only workload on the default bucket:

python: src/server.c:636: lcb_server_purge_implicit_responses: Assertion `c->cmd_log.nbytes' failed.
python: src/server.c:636: lcb_server_purge_implicit_responses: Assertion `c->cmd_log.nbytes' failed.
python: src/server.c:636: lcb_server_purge_implicit_responses: Assertion `c->cmd_log.nbytes' failed.

This may be an issue of incompatibility however the creates succeed against the saslbucket, but not the default bucket.

Aruna will attach additional server logs.

 Comments   
Comment by Aruna Piravi [ 05/Dec/13 ]
This behavior is not seen while loading to v2.0, v2.1.0 or v2.2.0. I will restart the same test and update on what I see. Thanks.
Comment by Aruna Piravi [ 05/Dec/13 ]
Attached cbcollect logs.
Comment by Mark Nunberg [ 05/Dec/13 ]
Thank you very much for the logs and the bug report. I'll get to it a bit later

What types of operations are you doing? It would seem that the client is getting an unsolicited response from the server; - or there's some other bug. This might be done during a multi operation?

Can you explain to me what the server is doing? I'll try to look at the code a bit later as well.
Comment by Tommie McAfee [ 05/Dec/13 ]
Ok, thanks Mark. More info here,

>What types of operations are you doing?
set_multi, 5k key/values per request
at 10k ops

You can run the client by checking out the testrunner repo:
git clone https://github.com/couchbase/testrunner.git
cd pysystests
python cbsystest.py run workload --create 100 --ops 10000 --standalone --hosts 10.20.331.21

deps:
pip install gevent
pip install argparse
pip install librabbitmq
pip install pyrabbit

@Aruna maybe you can see what happens when you run the client stand alone against 1.8?
Comment by Aruna Piravi [ 05/Dec/13 ]
The client stand alone against 1.8 with #python cbsystest.py run workload --create 100 --ops 10000 --standalone --hosts 10.20.331.21 yields 10k ops/sec on default bucket.

Ok, I did a fresh run, I ran into the same problem again. I see that when it starts loading, the ops are in the range ~16K for default and ~15K for sasl but when post-condition for load into sasl bucket is met (2M), load stops on default bucket as well, whose post-condition for loading is curr_items >3M. I see the same asserts again.
Comment by Tommie McAfee [ 05/Dec/13 ]
Mark,

I think this may be the most plausible -> "client is getting an unsolicited response"

This assert occurs when a 1.8 bucket is under very heavy load. We we're able to reproduce by setting a target of 160k ops ->
 python cbsystest.py run workload --create 100 --hosts 10.3.4.202 --standalone --ops 80000 &
 python cbsystest.py run workload --create 100 --hosts 10.3.4.202 --standalone --ops 80000 &

server is only able to handle say 60k, and sdks are catching lot's of network errors:
ERROR:root:<Key=u'23342FEC-62_67267', RC=0x10[Network error], Operational Error, Results=2500, C Source=(src/multiresult.c,286)>
 
within 10 seconds an assert is thrown and kills 1 of the processes. (there are 5 per command)


-Tommie
Comment by Aruna Piravi [ 06/Dec/13 ]
Anil tells me that we improved the time to persist in v2.0 so heavy ops are supported starting v2.0. Could this be the reason why we are seeing these asserts? We had set 80k ops on default bucket and 30k on sasl. When I bring the total ops to 50k, I don't see any issues.




[CCBC-276] Provide 'lcb_async_destroy' Created: 04/Oct/13  Updated: 27/Jan/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: None
Fix Version/s: .future
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   
While libcouchbase has lcb_destroy, this function is not safe to call within a callback. To fix this, we should provide an 'lcb_async_destroy'.

This is useful in situations when there's an actual async event loop running, and there is a possibility for the library to be destroyed upon the next invocation.

When lcb_async_destroy is called, libcouchbase will create a new event (it can be a timer) which shall be executed upon the next iteration. Upon the execution of the timer, the library itself shall be destroyed.

There of course remains the issue of destroying the IOPS structure itself..




[CCBC-271] create index files in package repositories Created: 18/Sep/13  Updated: 01/Nov/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: Matt Ingenthron Assignee: Matt Ingenthron
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File package-index.txt    

 Description   
Per recent discussion, the apt indexes have only the most recent versions in the index. This is normal.

Suggestion is to either create an index per directory or turn on auto-index generation.

This issue is to request creating indexes within the directory structure so archive files may be found.

 Comments   
Comment by Sergey Avseyev [ 18/Sep/13 ]
The list all releases. The early releases accessible as sources only.
Comment by Matt Ingenthron [ 18/Sep/13 ]
That's good to have for now, but what I mean to be asking for is that we update some kind of index up on the S3 bucket (or wherever, if we move it) every time we add packages. I think you got that, but just checking.
Comment by Sergey Avseyev [ 19/Sep/13 ]
I rather against of just indexing s3 bucket, because it contains some extra files and intermediate releases. What we need is the page like for server, where people could download any release




[CCBC-256] Enhance intelligence of client to know about all nodes of a cluster for making REST connection Created: 27/Aug/13  Updated: 10/Jan/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: docs
Affects Version/s: 2.1.1
Fix Version/s: None
Security Level: Public

Type: Improvement Priority: Major
Reporter: Perry Krug Assignee: Matt Ingenthron
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


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

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

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

 Comments   
Comment by Perry Krug [ 27/Aug/13 ]
And this would need integration with the higher level languages (php/python/ruby/etc)
Comment by Mark Nunberg [ 10/Jan/14 ]
The key issue of network programming when dealing with unresponsive servers is not knowing why a particular host is "unresponsive". A user-defined setting can tune between "Availability" and "Trying to reduce spinning", but those two criteria cannot be satisfied at the same time.
Comment by Perry Krug [ 10/Jan/14 ]
Matt, I believe CCCP/unibrow has taken care of this issue correct?




[CCBC-257] allow for setting bootstrap nodes via a configuration file, including dynamic updates Created: 27/Aug/13  Updated: 10/Jan/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.1.1
Fix Version/s: None
Security Level: Public

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


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

 Comments   
Comment by Perry Krug [ 27/Aug/13 ]
And this would need integration with the higher level languages (php/python/ruby/etc)
Comment by Sergey Avseyev [ 27/Aug/13 ]
Higher level languages have their own config systems. It isn't hard to pick any format you have in your application and initialize the instances. IMHO it isn't task of libcouchbase. We are trying to keep it simple and do not bloat with unnecessary features.

For example, you want to write command line utilities for couchbase, and you'd like to use libcouchbase to implement this task. Obviously having some rc file in home directory to configure these command line utilities will be awesome. And you must develop or integrate some solution for your particular project. We have done it for CBC, see man page cbcrc(4)
http://www.couchbase.com/autodocs/couchbase-c-client-2.1.1/cbcrc.4.html

We are building network library which will allow you to communicate you over couchbase protocols. There are better libraries for parsing configurations, I don't think we need to implement and maintain one in libcouchbase.

There is one place already, which used to keep configuration --the cluster itself, if we will bundle another one into libcouchbase, it will be be eventually out of sync with cluster configuration. And as soon as it will be our solution we will have to make it consistent and implement something which will keep it up to date
Comment by Perry Krug [ 27/Aug/13 ]
Thanks Sergey, but maybe we're not seeing the same thing here.

This bug is simply referring to the need for updating the internal list of bootstrap nodes in libcouchbase without updating the config string and restarting the application. Matt can provide more insight into the goal here.

My comment about the higher level languages was just to remind ourselves that whatever we build into libcouchbase needs a way of being controlled from those as well.
Comment by Mark Nunberg [ 10/Jan/14 ]
The idea here is to add another 'dynamic file' which would be used to contain the bootstrap nodes? I feel this would honestly be better managed by an external configuration system rather than in the library itself, as it would not be in sync with a common "properties" format for whatever HLL was wrapping LCB.
Comment by Perry Krug [ 10/Jan/14 ]
Mark, The problem we're trying to solve is the occasional need to update the "bootstrap" list of nodes without changing code or restarting the running instances of the library. Think about when the entire set of nodes of a cluster are removed and swapped with different IP's...the next time an instance starts up, it needs to get the updated list.

I don't think we're particularly tied to an extra file, but keep in mind that libcouchbase is sometimes used all by itself, so I believe it also needs to provide this facility as well as the higher level wrappers such as php/python/etc.

Does that make more sense?




[CCBC-116] Heavy errors during short network loss Created: 07/Nov/12  Updated: 04/Feb/14

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: Mark Nunberg
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.
Comment by Mark Nunberg [ 04/Feb/14 ]
Still valid




[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-100] Allow Incremental Row Callbacks Created: 11/Sep/12  Updated: 09/Aug/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: 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-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-289] Handle NOOP padding on GETQ relocation Created: 31/Oct/13  Updated: 20/Feb/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.0.7, 2.1.3, 2.2.0
Fix Version/s: .future
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   
Currently we blindly relocate packets to other servers, not keeping in mind that if a node is removed, some context-sensitive commands (for example GETQ) rely on terminal padding. It's possible for a GETQ packet to be moved to a new server, in which case it should be padded with a NOOP.

Maybe this isn't an issue, but I'm using JIRA as a TODO list in this case.

 Comments   
Comment by Mark Nunberg [ 20/Feb/14 ]
Will be fixed with packet-ng




[CCBC-332] libcouchbase does not compare revids before overwritting configs Created: 20/Feb/14  Updated: 20/Feb/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.0-dp2
Fix Version/s: None
Security Level: Public

Type: Task Priority: Major
Reporter: Brett Lawson Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
libcouchbase currently ignores the revid information attached to the bucket-config data potentially causing a stale configuration to be made active within libcouchbase.




[CCBC-329] "connectionTimeout" and "operationTimeout" passed as options to the Connexion class do not work as expected Created: 13/Feb/14  Updated: 20/Feb/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: None
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Major
Reporter: Xav M Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: connectionTimeout, couchnode, libcouchbase, operationTimeout
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: CenOS 6.4 X86_64
libcouchbase2-libevent: 2.2.0
libcouchbase-devel : 2.2.0
node.js: v0.10.24
couchnode: 1.2.1
couchbase: 2.1.1 CE


 Description   
# Pb 1 : "connectionTimeout"

No DNS resolution | Use /etc/hosts only
Create a couchnode "new Connexion" with options.host = couch1
Set options.connectionTimeout to anything > 2999
Set couch1 in /etc/hosts with an IP that is not assigned to any thing (No ping, nothing listening on 8091, etc )
Run the js code that initiate the "new Connexion"

---> The error that specifies the connexion failure occurs minutes after the "new Connexion" has been initiated

  - connectionTimeout: 1000 -> "Connection Error { [Error: Connection failure] code: 24 }" Occurs ~2Sec after "new Connexion"
  - connectionTimeout: 2000 -> "Connection Error { [Error: Connection failure] code: 24 }" Occurs ~4Sec after "new Connexion"
  - connectionTimeout: 2999 -> "Connection Error { [Error: Connection failure] code: 24 }" Occurs ~4Sec after "new Connexion"
  - connectionTimeout: 3000 -> "Connection Error { [Error: Connection failure] code: 24 }" Occurs ~1Min30Sec after "new Connexion"
  - connectionTimeout: 4000 -> "Connection Error { [Error: Connection failure] code: 24 }" Occurs ~4Min30Sec after "new Connexion"
  - connectionTimeout: 5000 -> "Connection Error { [Error: Connection failure] code: 24 }" Occurs ... I have no idea : I just never happened after 15 minutes

5000ms being the default for "connectionTimeout", when you do not specify it, operations are queued until your node.js blows up

---

# Pb 2 : "operationTimeout" :

No DNS resolution | Use /etc/hosts only
Identify couchbase nodes via a hostnames rather than IP address when you setup your cluster
Create a couchnode "new Connexion" with options.host = couch1
Do not set couch2 in /etc/hosts with any IP (So that resolution cannot happen)
Run the js code that initiate the "new Connexion" to couch1 and db.get a key you know being on couch2

---> No error is never emitted or called back (you should get a "[Error: Operation timed out] code: 23" after 2500ms)

---

Here is the dead simple code I am using to reproduce :

var couchbase = require('couchbase');

var options = {
  host: 'couch1:8091',
  bucket: 'bucket1',
  //connectionTimeout: 2999,
  //operationTimeout: 1000
}

console.log(new Date(), "Script init");

var db = new couchbase.Connection(options, function(err) {
  if (err) {
    console.log(new Date(), 'Connection Error', err);
  } else {
    console.log(new Date(), 'Connected!');

    var usr="myKey_on_couch2:bucket_1"

    console.log(new Date(), 'db.get');
    db.get(usr, function(err, res) {
      console.log(new Date(), err, res);
    });

  }
});


 Comments   
Comment by Brett Lawson [ 20/Feb/14 ]
This should be fixed in libcouchbase 2.3.0, I'll leave this open until a verification can be made.




[CCBC-334] support for DNS SRV record for bootstrap Created: 24/Feb/14  Updated: 24/Feb/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: docs, library
Affects Version/s: None
Fix Version/s: None
Security Level: Public

Type: New Feature Priority: Major
Reporter: Matt Ingenthron Assignee: Brett Lawson
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Add support and documentation for DNS SRV records, per discussed plans.

_cbmcd._tcp.example.com. 0 IN SRV 20 0 11210 node2.example.com.
_cbmcd._tcp.example.com. 0 IN SRV 10 0 11210 node1.example.com.
_cbmcd._tcp.example.com. 0 IN SRV 30 0 11210 node3.example.com.

_cbhttp._tcp.example.com. 0 IN SRV 20 0 8091 node2.example.com.
_cbhttp._tcp.example.com. 0 IN SRV 10 0 8091 node1.example.com.
_cbhttp._tcp.example.com. 0 IN SRV 30 0 8091 node3.example.com.

 Comments   
Comment by Matt Ingenthron [ 24/Feb/14 ]
See also MB-10285 which has more on the format.




[CCBC-337] Partial failures on vbucket mappings for multi ops should asynchronously fail unmapped keys Created: 24/Feb/14  Updated: 24/Feb/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.0
Fix Version/s: .future
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   
With the fix for CCBC-281 we fail out the entire command list (in the API). We should schedule the commands which are able to be mapped and then fail out the rest of the items asynchronously via some kind of queue.




Multi operations should never be partially scheduled (CCBC-281)

[CCBC-333] Multi get replica should not be partially scheduled Created: 22/Feb/14  Updated: 22/Feb/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: None
Fix Version/s: .future
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


 Description   
This is the same as CCBC-281 except that to implement this for get-replica would be more complex, so I'm deliberately filing a new bug so that this remains open




[CCBC-211] libcouchbase may touch a failed node after failover Created: 21/May/13  Updated: 25/Feb/14

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: Mark Nunberg
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.

 Comments   
Comment by Mark Nunberg [ 03/Feb/14 ]
Can you explain what you mean by "Touching" the node?

Failing over the node simply promotes its replica (if any) as master. If your cluster doesn't have a sufficient number of replicas, all data on the failed node is _lost_ and no node can replace ownership of the vbuckets for the failed node until you rebalance.




[CCBC-212] IO Enhancements Created: 21/May/13  Updated: 25/Feb/14

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: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on CCBC-216 Change 'lcb_wait' semantics Open
depends on CCBC-214 Re-design internal operations in a qu... Resolved
depends on CCBC-213 Unify internal connect() routines Closed
Epic Name: IO Enhancements
Epic Status: To Do

 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-186] Request to provide concrete examples in the documentation for OBSERVE functionality Created: 21/Feb/13  Updated: 25/Feb/14

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: Mark Nunberg
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-266] Unable to connect to second cluster while using same bucket name in PHP configuration cache Created: 04/Sep/13  Updated: 25/Feb/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.1.2
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Major
Reporter: Larry Liu Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Environment:
1. PHP SDK 1.1.5
2. CentOs 6.4
3. Set up the couchbase cache config path in php.ini.
4. Couchbase Enterprise 2.1.0

Test scenario:
1. Set up two separate clusters, representing two separate data centers.
2. Set up the cache config path in php.ini (from another location outside
the clusters)
3. Set up a bucket (any type), with the same name on both clusters.
4. Create a script that first loads some data on cluster one, then
immediately loads the same on cluster two.

Expected Results:
The data should be loaded to cluster two.

Actual Results:
The data never makes it to cluster two because the cache file is by bucket
name. In the cache file, there is the map of just the first cluster.
Subsequent sets and gets use the cache file no matter what hosts are used
in the connection (in code).

 Comments   
Comment by Mark Nunberg [ 10/Jan/14 ]
This is a limitation in the config_cache algorithm. The only way to actually solve this is to place the bucket and/or cluster UUID as part of the constructor parameters, which would not be possible in the first connection attempt anyway.




[CCBC-226] Support HTTP keepalive semantics for views Created: 15/Jul/13  Updated: 25/Feb/14

Status: Reopened
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: None
Fix Version/s: .future
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

Issue Links:
Dependency
blocks PYCBC-171 Too many open connections when runnin... Resolved

 Description   
Keep-Alive

 Comments   
Comment by Matt Ingenthron [ 20/Aug/13 ]
keepalive is hard btw mordy__ @ 2:30

no doubt ingenthr @ 2:31

yes, probably we will start it as the latest tas avsej @ 2:31

though, we have only one server implementation, so we may be able to cut some corners w.r.t. the actual HTTP spec ingenthr @ 2:31
if that's where the weird stuff is 2:31
 
ingenthr: the most difficult is stale connection tracking mordy__ @ 2:31

ah ingenthr @ 2:31
that makes sense 2:32
 
since tyou have no way to know if a connection is closed or not unless you try to use it mordy__ @ 2:32

that sounds familiar ingenthr @ 2:32

so then you need to keep state in knowing whether a "cached" connection was used and apply retry logic mordy__ @ 2:33




[CCBC-222] Ensure examples feature correct iops usage Created: 24/Jun/13  Updated: 25/Feb/14

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: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on CCBC-221 'minimal' example features leak in iops Closed




[CCBC-280] lcb_wait for infinitely after invoking lcb_get Created: 11/Oct/13  Updated: 25/Feb/14

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: jim.yefeng Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: 1. OS
CentOS release 6.3 (Final) 64bits

2. Couchbase SDK
[push@nfjd-jpush-pushtask-msgdb02-178 ~]$ rpm -qa | grep libcouchbase
libcouchbase-devel-2.0.6-1.x86_64
libcouchbase2-core-2.0.6-1.x86_64
libcouchbase2-libevent-2.0.6-1.x86_64
libcouchbase2-2.0.6-1.x86_64
[push@nfjd-jpush-pushtask-msgdb02-178 ~]$

3. Couchbase Server
8 nodes with default bucket and version is 2.1.1


 Description   
Set timeout to 5s
And our routine stop at lcb_wait(epoll_wait) infinitely

stack info:
#0 0x00000036a14e8f03 in epoll_wait () from /lib64/libc.so.6
No symbol table info available.
#1 0x00007fc5e201ae4b in ?? () from /usr/lib64/libevent-1.4.so.2
No symbol table info available.
#2 0x00007fc5e200e8c3 in event_base_loop () from /usr/lib64/libevent-1.4.so.2
No symbol table info available.
#3 0x00007fc748f92ce3 in lcb_wait () from /usr/lib64/libcouchbase.so.2
No symbol table info available.
#4 0x0000000000479221 in CSingleCouchbase::GetValue (this=0xfc6460, key=<value optimized out>, klen=<value optimized out>, val=<value optimized out>, vlen=<value optimized out>) at singleCouchbase.cpp:127
_FUNCTION_ = "GetValue"
cmd = {version = 0, v = {v0 = {key = 0x7fffd0a0ea1c, nkey = 4, exptime = 0, lock = 0, hashkey = 0x0, nhashkey = 0}}}
commands = {0x7fffd0a0e180}
#5 0x000000000043b026 in CDisonlineInterfaceSrv::HandleOnlineMsg (this=0x7fffd0a0ecc0, uUid=6915812) at /home/push/src/niehao/jpush-server/server/msgcenter/msgdb/MsgDBSvr.cpp:636
buf = '\000' <repeats 1999 times>

The CSingleCouchbase::GetValue function codes are,
lcb_get_cmd_t cmd;
const lcb_get_cmd_t *commands[1];
commands[0] = &cmd;
memset(&cmd, 0, sizeof(cmd));
cmd.v.v0.key = key;
cmd.v.v0.nkey = klen;
m_error = lcb_get(m_pInstance, this, 1, commands);
if (m_error != LCB_SUCCESS)
{
snprintf(m_strErrMsg, sizeof(m_strErrMsg) - 1,
"%s: get value error: %s", m_strClassName, lcb_strerror(
m_pInstance, m_error));
return -2;
}

(void) lcb_wait(m_pInstance); // ================== stop here
if (m_iError != 0)
{
return -3;
}

return 0;

 Comments   
Comment by Sergey Avseyev [ 11/Oct/13 ]
Could you compile and run this small program in your environment

https://github.com/couchbase/libcouchbase/blob/master/example/minimal/minimal.c#L21

It comes in source tarball and what it does is just to connect to the cluster, perform set and then get the same key.

With this example I want to see if it related to some misconfiguration/misuse of the wrapper code in your application.

Thank you
Comment by jim.yefeng [ 12/Oct/13 ]
The result is
[push@nfjd-jpush-compile-190 test]$ ./a.out 192.168.250.149:8091 tagaliascb tagaliascb
STORED "foo" CAS: 16977977983895798528
GOT "foo" CAS: 16977977983895798528 FLAGS:0x0 SIZE:3
bar
[push@nfjd-jpush-compile-190 test]$

it looks like work well.

This issue arised on our production environment after several days.
 




[CCBC-296] Implement an option to send GET requests instead of GETQ/NOOP Created: 21/Nov/13  Updated: 25/Feb/14

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: Sergey Avseyev Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
We're currently using getq followed by a noop whenever we want to request multiple keys in libcouchbase. In my eyes this is a cache-miss optimization, so that we'll implicit tell which entries we didn't find. For a cache that makes perfectly sense, but it might not be as "important" for a database. If all entries is found, using getq introduce an overhead with 24 bytes per server used in the request, whenever an entry isn't there it reduce the size with 24 bytes (which means you need at least to have one cache miss per server to avoid introducing an overhead).





[CCBC-174] Error handling documentation Created: 05/Feb/13  Updated: 25/Feb/14

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: Mark Nunberg
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-301] add method to receive callback as packets are received Created: 06/Dec/13  Updated: 25/Feb/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: None
Fix Version/s: .future
Security Level: Public

Type: New Feature Priority: Major
Reporter: Matt Ingenthron Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
There are some use cases where one would like to register a callback that receives notifications for each packet received. The recommendation, at the moment, is that this should have a return value that indicates if the responsibility of the buffer is transferred to the function of the callback. It would also indicate whether or not libcouchbase is going to continue the dispatch logic.




[CCBC-110] Implement lcb_reconnect() which will reconnect all dead sockets Created: 17/Oct/12  Updated: 25/Feb/14

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: Mark Nunberg
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-273] Increase granularity of timings below 9ms for pillowfight Created: 25/Sep/13  Updated: 25/Feb/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.1.3
Fix Version/s: None
Security Level: Public

Type: Improvement Priority: Major
Reporter: Perry Krug Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The current timings output from a pillowfight run groups 1-9ms together:
[1380106215.425126] Run
              +---------+---------+---------+---------+
[ 1 - 9]ms |######################################## - 102733
[ 10 - 19]ms | - 97
[ 20 - 29]ms | - 78
[ 30 - 39]ms | - 30
[ 40 - 49]ms | - 7
[ 50 - 59]ms | - 35
[ 60 - 69]ms | - 10
[ 70 - 79]ms | - 3
[ 80 - 89]ms | - 3
[ 90 - 99]ms | - 2
[180 - 189]ms | - 3
[190 - 199]ms | - 1
[200 - 209]ms | - 2
              +----------------------------------------

It would be very helpful to get much more granular below 9ms and even below 1ms.

Similar to what ./cbstats timings outputs, we want to measure 0-500us, 500us to 1ms, 1-2ms, and 2-3ms...and then can probably jump up to 9/19/29/etc ms




[CCBC-216] Change 'lcb_wait' semantics Created: 22/May/13  Updated: 25/Feb/14

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: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks CCBC-212 IO Enhancements Open

 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-277] Provide pause_http_request, resume_http_request Created: 07/Oct/13  Updated: 25/Feb/14

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: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
These functions will stop and resume the given request's activity on the event loop. It would be nice if we could implement something like this: https://twistedmatrix.com/documents/11.1.0/core/howto/producers.html#auto8




[CCBC-108] Allow per-command retries for not-my-vbucket and other transient errors Created: 04/Oct/12  Updated: 25/Feb/14

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: Mark Nunberg
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-251] replace the jira logo for CCBC with something modern Created: 20/Aug/13  Updated: 25/Feb/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: docs
Affects Version/s: None
Fix Version/s: None
Security Level: Public

Type: Task Priority: Major
Reporter: Matt Ingenthron Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[CCBC-341] ringbuffer_consumed: Assertion `n == nb' failed during write Created: 04/Mar/14  Updated: 04/Mar/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.2.0
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Major
Reporter: Dave Rigby Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency

 Description   
Customer reported a failed assertion during a write using libcouchbase 2.2:

    src/ringbuffer.c:266: ringbuffer_consumed: Assertion `n == nb' failed.

Re-running the write was sufficient to allow it to succeed. We run thousands of writes a day, and have (to my knowledge) only hit this once, so this looks like a very uncommon error case.




[CCBC-342] Default installation should use libevent plugin Created: 05/Mar/14  Updated: 05/Mar/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: None
Fix Version/s: .future
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   
10:11 < mnunberg> avsej: also. it's not using the libevent backend
10:11 <+avsej> it signs the repository during import
10:11 <+avsej> https://github.com/couchbaselabs/lcbpackage/blob/master/rakefiles/repositories.rake#L143
10:11 < mnunberg> cbc built from: libcouchbase 2.3.0 (rev. 7b11fe7e4f8f23f24861fe82287d7eb10de2c6b4) using libcouchbase: 2.3.0 (select)
10:12 <+avsej> did you install libcouchbase2-libevent?
10:12 < mnunberg> uhmm..
10:12 < mnunberg> i thought the default behavior was for it to pull in libevent
10:12 < mnunberg> no i didn't install it explicitly
10:12 <+avsej> there should be file like ubuntu/config/distributions
10:13 <+avsej> mnunberg, it won't install it implicitly either
10:13 < mnunberg> hrm, that's not good
10:13 <+avsej> so if you need libevent just install it
10:13 <+avsej> libcouchbase2-libevent
10:13 < mnunberg> but if that's hwo previous versions did it, then ok
10:13 < mnunberg> it doesn't matter to me now
10:13 <+avsej> it is documented http://www.couchbase.com/communities/c-client-library
10:14 < mnunberg> another thing i'd like to do in 3.0 is a blanket dependency on libevent. it's the most well tested and stable of our event loops
10:14 < mnunberg> if you don't want libevent, compile from source
10:17 <+avsej> what if people are using libevent1 in their libraries? they will end up having two versions in their app?
10:18 <+avsej> i don't see issue at all
10:18 <+avsej> it is always better to rely on the repository maintainer rather then us
10:18 <+avsej> are you sure we will push new libcouchbase for each new release of libevent?
10:18 < mnunberg> most people installing libcouchbase are using it as a dependency for ruby php python etc.
10:19 < mnunberg> so we should give the most optimal runtime defaults
10:19 <+avsej> right
10:19 <+avsej> in this case they won't use libcouchbase IO at all
10:19 <+avsej> this is why we have libcouchbase2-core package
10:19 <+avsej> without any dependencies and additional blobs
10:19 < mnunberg> not really. most folks are still using the default I/O plugin, whichever it is that ships
10:19 <+avsej> for ruby people just want libcouchbase
10:20 <+avsej> and for python they also have their own
10:20 < mnunberg> that's the "Most minimal packaging configuration", not "Most optimal runtime configuration" :)
10:20 < mnunberg> python optionally elts you use your own I/O but it's not the default
10:20 < mnunberg> for normal sycnrhonous operatin you want the fastest there is
10:20 < mnunberg> and that's what most use cases are
10:21 <+avsej> so you mean that select implementation is the slowest? it adds a little overhead, and we don't have c10k on the client
10:21 < mnunberg> avsej: it's also buggier
10:22 < mnunberg> 14
10:22 < mnunberg> err..
10:23 < mnunberg> mnunberg@mbp15 ~/Source/lcb-master $ git log 2.0.0..HEAD --pretty=oneline plugins/io/select/ | wc -l 14
10:23 < mnunberg> mnunberg@mbp15 ~/Source/lcb-master $ git log 2.0.0..HEAD --pretty=oneline plugins/io/libevent/ | wc -l 4
10:23 < mnunberg> mnunberg@mbp15 ~/Source/lcb-master $ git log 2.0.0..HEAD --pretty=oneline plugins/io/libev/ | wc -l 7
10:24 < mnunberg> on the other hand select is simpler to debug
10:24 < mnunberg> eh, i don't know
10:25 <+avsej> in any event people have easy what to substitute it, and so far select is good as minimal implementation
10:25 <+avsej> the recommended way to install libcouchbase is 'yum install libcouchbase-devel libcouchbase2-libevent'
10:26 <+avsej> so I don't see any issue
10:26 < mnunberg> that's not the most intuitive way of installing a package
10:26 < mnunberg> if my documentation says "I need dependency FOO" i'll go ahead and query my package manager and install "FOO"
10:26 < mnunberg> i'm not gonna jump to some other document telling me what to install
10:27 <+avsej> why not fix documentation then
10:27 < mnunberg> because people don't read documentation
10:27 < mnunberg> as a rule, people only read documentation enough to get them up and running
10:27 <+avsej> just recently i was compiling nginx with some module which has dependency on gd
10:27 <+avsej> and first thing I was tried is yum install libgd-devel which failed
10:28 <+avsej> the correct way was gd-devel
10:29 <+avsej> in any event libevent is not good enough as default for ruby and I against to have this as mandatory dependency
10:29 <+avsej> libevent doesn't allow to release GIL while it is doing IO
10:29 <+avsej> the ruby IO plugin does
10:30 <+avsej> you probably can rename the packages, but please leave ability to install libcouchbase2-core, i.e. without any plugins
10:30 < mnunberg> it's the default for python and php. i think the way i wanted this to begin with was a libcouchbase2 metapackage
10:30 < mnunberg> i.e. libcouchbase2 would install libcouchbase2 and libevent
10:31 < mnunberg> and for things that had "Special" requirements, they could use '-core'
10:31 <+avsej> why not remove libcouchbase2 package at all
10:31 < mnunberg> we don't have such a package afaict
10:31 <+avsej> and update docs to install libcouchbase2-libevent if they depend on it
10:32 <+avsej> right
10:32 <+avsej> no package no problem
10:32 < mnunberg> going back to my point
10:32 < mnunberg> people don't read docs
10:32 < mnunberg> especially if _not_ installing libevent doesn't actually give any kind of error or issues until much later when it's in production
10:32 < mnunberg> and then it's like "Oh, we're crashing"
10:32 <+avsej> https://github.com/couchbase/libcouchbase/blob/master/packaging/deb/control#L39 remove this line
10:32 < mnunberg> so then we ask "Ok, tell me what I/O plugin you're using"
10:32 < mnunberg> "Oh, you're using select. You should use libevent"
10:32 <+avsej> or rather move it to libcouchbase2-libevent sectio
10:33 <+avsej> https://github.com/couchbase/libcouchbase/blob/master/packaging/deb/control#L12 after this one
10:33 < mnunberg> avsej: not this release. these are just plans for a 3.0 or whatever
10:33 < mnunberg> i'd rather not touch or change behavior
10:34 <+avsej> rpm also has equivalent https://github.com/couchbase/libcouchbase/blob/master/packaging/rpm/libcouchbase.spec.in#L34
10:34 <+avsej> i'm okay with solution which is about moving alias 'libcouchbase2' from 'libcouchbase2-core' to 'libcouchbase2-libevent'
10:34 <+avsej> totally agree with it
10:35 <+avsej> seems like the easiest solution
10:35 < mnunberg> avsej: yeah, we'll need to schedule it for next release, like .future
10:35 < mnunberg> let me do this on JIRA
10:35 <+avsej> could you copy this log there?
10:35 <+avsej> or extract the main idea
10:35 < mnunberg> ok




[CCBC-331] memcached buckets may receive operation failures during rebalance Created: 20/Feb/14  Updated: 19/Mar/14

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: Subhashni Balakrishnan Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
When updating the config received on http stream, the client returns an error LCB_CLIENT_ETMPFAIL for memcached buckets. Please clarify if this design is intentional.

https://github.com/couchbase/libcouchbase/blob/master/src/bconf_provider.c#L183


 Comments   
Comment by Mark Nunberg [ 20/Feb/14 ]
I'd argue this is by design as a memcached bucket is usually intended for lightweight caching purposes. Rather than rescheduling all commands we just fail them all out. The error message might need to be a bit more helpful?
Comment by Matt Ingenthron [ 18/Mar/14 ]
This came up during a test of an upgrade. Usually during upgrade with memcached buckets, we just fire the request at the node we're aware of. That does mean that there is a possible lack of consistency between two actors on where to fire a request, based on the config they're using and the ketama hashing, but that's okay for a cache.

I don't think we'd expect failing out requests though in this case.

From reading the code, it looks like maybe we just need to do nothing during this replace_config() if it's for memcached buckets? Looking at that, right now if we have an add node case (which comes up in this test), we'll push a bunch of errors up to the app that would have otherwise been successful.
Comment by Mark Nunberg [ 18/Mar/14 ]
Because we support hashkey, we have no way to route requests to a server without that kind of context. With Couchbase buckets we already have the vbucket so we don't need to re-hash; however this isn't the case with memcached buckets as the destination bucket depends on the hash of the actual key which we forget about once the operation is scheduled.

In order to make this work, we'd either need to disable support for hashkey or keep the (hash)key around for future operations.
Comment by Matt Ingenthron [ 18/Mar/14 ]
I think the right thing to do here is to use the previously hashed location. Anything different would be a change over what we do in other clients and moxi. it'd also be a change over what we did in previous releases, I believe.

Looking at it from a cache perspective, when adding a node to the cluster the old node has a cached value, and the new node will eventually have a cached value. The old location would slowly LRU out and the requests would get to the new place eventually.

So if we don't rehash, we actually will likely get correct behavior, see what I mean? It's different than vbucket situations, but memcached buckets are different than couchbase buckets.
Comment by Mark Nunberg [ 18/Mar/14 ]
For storage, the stored data will never be read back out again - so it's pointless to send the data there.

For retrieval, a potentially stale version of the data may be retrieved (assuming it hasn't been updated on the "correct" node yet). I think the "Correct" behavior in that light is to retry retrieval operations but not storage operations. This would still "fail" operations, but I think it's the correct thing to do.

If you agree, please change the title of this ticket to reflect this - and we'll try to fix it -- maybe in this release or in the next.
Comment by Matt Ingenthron [ 18/Mar/14 ]
What was the behavior before the integration of confmon?

For storage, it may be pointless to send the data there, but it's more disruptive if we start returning errors to the caller when there was no error. There was a topology change which has a defined behavior.

For retrieval, the potentially stale is the expected behavior with memcached buckets. I believe that's the behavior in the current release too.

Is it a large change to just not do anything in that section of code? It doesn't seem like it. We'd just let the operations go to the node they're hashed for and then we'd have (approximately) the same behavior as in the current release, right?
Comment by Mark Nunberg [ 18/Mar/14 ]
2.3 has not changed the way we handle this. This has always been the behavior -- I'm just explaining why the behavior has been the way it has been.

See: https://github.com/mnunberg/libcouchbase/blob/2.2.0/src/bconf_provider.c#L320-339 (2.2.0)
See: https://github.com/mnunberg/libcouchbase/blob/2.0.7/src/instance.c#L734-744 (2.0.7)

You'd need a bit more code out there to relocate properly to a memcached bucket (we relocate currently based on the vbucket destination -- in this case we'd need to remember the _old_ destination). Also, this does not help if a server was _removed_ from the cluster (in which case the prior "Destination Index" may no longer exist).
Comment by Matt Ingenthron [ 19/Mar/14 ]
I didn't realize this was the behavior through release 2.2. We should definitely release note this.

I don't think we need to relocate, as previously mentioned. We don't do that elsewhere, but we don't have failures either. Also, not worried as much about the remove case.




[CCBC-314] new Connection() callback hangs if CB server process is not running Created: 06/Jan/14  Updated: 27/Mar/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.2.0
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Major
Reporter: Jonathon LeFaive Assignee: Brett Lawson
Resolution: Unresolved Votes: 0
Labels: connection-timeout
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Windows 7 64bit / node 0.10.24 / couchnode 1.2.0 / libcouchbase 2.2.0


 Description   
When instantiating a new connection, the callback to the constructor will hang forever if the physical server is running but CB Server is not listening on ports.

This situation would produce a "Network error" on 1.0.1. This only started to occur after upgrading to 1.2.0.

If the connection object is instantiated while CB Server IS running and then CB Server is shutdown afterwards, the operation calls will appropriately pass a "Network error".

This is fixed if connectionTimeout is set to 1000 on the return value from the constructor, but setting it to 2000 or greater will hang forever. When set to 1000, the error message is "Connection faliure"..

 Comments   
Comment by Brett Lawson [ 02/Feb/14 ]
I believe this should be fixed in libcouchbase 2.3.0, I will leave this ticket open until a verification can be made.
Comment by Mark Nunberg [ 27/Mar/14 ]
per your message, I believe this is fixed in 2.3 -- just verify that it works




[CCBC-356] operations stop for 12 seconds entirely during re-add test case Created: 27/Mar/14  Updated: 28/Mar/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.2.0
Fix Version/s: .future
Security Level: Public

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


 Description   
During testing of cluster 2.5.1, it was found that operations fail entirely for over 10 seconds.

See: http://sdk-testresults.couchbase.com.s3.amazonaws.com/SDK-SDK/CB-2.5.1-1083/ReAdd2-HYBRID/03-27-14/076505/1a810d18eee7145c7f1c175efb2287dc-MC.txt

 Comments   
Comment by Mark Nunberg [ 28/Mar/14 ]
This seems to be one or two operations taking 17-30s to complete. Why it's taking that long I do not know - there's potentially a bug inside 2.2.0. In any event we should be seeing if this same condition is present with 2.3 and if it is [typo in email, "if not"], investigate it further.

The mere fact that we're getting timeouts for this long however indicates an issue in the client and not the server.




[CCBC-335] Provide lcb_cluster_refresh to refetch configuration Created: 24/Feb/14  Updated: 31/Mar/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.2.0, 2.3.0-dp2
Fix Version/s: .future
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   
This API call should refresh the configuration and work in conjunction with lcb_wait

Currently if we get NO_MATCHING_SERVER on any API call, we have no way to re-fetch the configuration. This would allow us to do lcb_cluster_refresh in a loop for example.

 Comments   
Comment by Mark Nunberg [ 31/Mar/14 ]
This wouldn't integrate very nicely with lcb_wait until we have packet-ng worked out. Moving to .future




[CCBC-353] Add couchbase cluster compatibility to documentation Created: 25/Mar/14  Updated: 07/Apr/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: docs
Affects Version/s: None
Fix Version/s: .future
Security Level: Public

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

Issue Links:
Gantt: finish-start
has to be done after JCBC-438 Add table for 1.8, 2.x and 3.x compat... Open

 Description   
We should probably specify for this given major.minor of the SDK, one of three things for Couchbase Cluster releases:
- unsupported
- supported
- supports all features

These might be an 'x', '—' and "✓" in a table, or whatever Amy comes up with.

This is, in part, planning for 3.0 including beta.

This should be based on the work done in JCBC-438, so it's blocked by that issue.

 Comments   
Comment by Mark Nunberg [ 31/Mar/14 ]
Should we move this to .future, or should I just make my own list and see how ti works? Not a super complicated thing to do




[CCBC-359] add feature test ensuring that E2BIG is returned on append above 20MB Created: 07/Apr/14  Updated: 07/Apr/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.2.0, 2.3.0-dp2
Fix Version/s: None
Security Level: Public

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

Issue Links:
Dependency
depends on MB-10778 Append do not return the correct erro... Resolved

 Description   
When continuing to append beyond the maximum value of 20MByte, we should verify that applications receive the correct error response.




[CCBC-368] Incorrect error raised when using node_list: property Created: 11/Apr/14  Updated: 17/Apr/14

Status: In Progress
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.0, 2.4.0
Fix Version/s: 2.3.1
Security Level: Public

Type: Bug Priority: Major
Reporter: Jasdeep Jaitla Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
If you use the node_list property and try to connect to a cluster for a bucket that doesn't exist, you get:
Couchbase::Error::Timeout instead of Couchbase::Error::BucketNotFound

This can mess up scripts that rescue the BucketNotFound and create the bucket if it's not there. Timeout implies other problems (connectivity problems) which isn't the case.

gems/ruby-2.1.0/gems/couchbase-1.3.6/lib/couchbase.rb:63:in `initialize': No more bootstrap providers remain (error=0x17) (Couchbase::Error::Timeout)


 Comments   
Comment by Jasdeep Jaitla [ 11/Apr/14 ]
I tried it by connecting to a 2-node cluster and it was a script that creates a bucket if it doesn't exist, I had a rescue statement for BucketNotFound but not Timeout....
Comment by Sergey Avseyev [ 17/Apr/14 ]
$ cbc cat -b bucket_does_not_exist -h "localhos:8091;localhost:8091" foo
ERROR: Client-Side timeout exceeded for operation. Inspect network conditions or increase the timeout
"No more bootstrap providers remain"

$ cbc version
cbc built from: libcouchbase 2.3.0 (rev. a62ff57ff12ad46d619193a501b1aca337ad851a)
    using libcouchbase: 2.3.0 (libevent)
    using libyajl: 2.0.4
Comment by Mark Nunberg [ 17/Apr/14 ]
Note even with a fix, you'll still get an auth error from CCCP if a bucket is not found (assuming _only_ CCCP is enabled)
Comment by Sergey Avseyev [ 17/Apr/14 ]
http://review.couchbase.org/35979




[CCBC-369] lcb_create manpage does not mention v2 layout of struct lcb_create_st Created: 17/Apr/14  Updated: 17/Apr/14

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: Sergey Avseyev Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[CCBC-371] FORWARDPORT (2.4) - Incorrect error raised when using node_list: property Created: 17/Apr/14  Updated: 17/Apr/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.3.0, 2.4.0
Fix Version/s: 2.4.0
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   
If you use the node_list property and try to connect to a cluster for a bucket that doesn't exist, you get:
Couchbase::Error::Timeout instead of Couchbase::Error::BucketNotFound

This can mess up scripts that rescue the BucketNotFound and create the bucket if it's not there. Timeout implies other problems (connectivity problems) which isn't the case.

gems/ruby-2.1.0/gems/couchbase-1.3.6/lib/couchbase.rb:63:in `initialize': No more bootstrap providers remain (error=0x17) (Couchbase::Error::Timeout)


 Comments   
Comment by Mark Nunberg [ 17/Apr/14 ]
CCBC-368




[CCBC-259] libuv plugin does not track real work vs idle work. Created: 27/Aug/13  Updated: 28/Aug/13

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.1.2
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Minor
Reporter: Brett Lawson Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The libuv plugin for libcouchbase does not properly keep track of 'active work' vs 'idle work' when dispatching libuv watchers. This causes an issue where the libuv event loop will continue idling even though there is no real work to complete. This particularly affects the node.js driver as a script that no longer has any work left will never exit if a Couchbase connection is still open (even though the connection is idle).




[CCBC-206] Improve libcouchbase rpm instructions Created: 19/Feb/13  Updated: 25/Feb/14

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: Mark Nunberg
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 kzeller [ 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 kzeller [ 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-292] Documentation/blog on how to use cbc-pillowfight Created: 12/Nov/13  Updated: 25/Feb/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: docs
Affects Version/s: 2.2.0
Fix Version/s: None
Security Level: Public

Type: Task Priority: Minor
Reporter: Patrick Varley Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: customer, pillowfight, stats
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
There is no documentation on how to use and read the output of cbc-pillowfight.
An article explaining how to use pillowfight and cbstats timings together would be useful.

 Comments   
Comment by Matt Ingenthron [ 12/Nov/13 ]
Note that pillowfight is a subcommand to cbc, and thus it's in that man page:
http://www.couchbase.com/autodocs/couchbase-c-client-2.2.0/cbc.1.html

Agreed that the output could be better described.




[CCBC-101] allow google test suite to be preserved between invocations of make distclean and friends Created: 18/Sep/12  Updated: 25/Feb/14

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: Mark Nunberg
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-129] Add libevent support for win32 Created: 20/Nov/12  Updated: 25/Feb/14

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: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive 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-308] provide built artifacts for windows Created: 29/Jan/14  Updated: 15/Apr/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: None
Fix Version/s: .future
Security Level: Public

Type: Improvement Priority: Minor
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   
To facilitate easy software building for Windows users, we should provide a .zip file of artifacts.

 Comments   
Comment by Mark Nunberg [ 15/Apr/14 ]
I'm not sure what this means. We already provide builds for Windows and have done so since early on. If you meant something else, reassign back to me




[CCBC-302] cbc verify exit code Created: 12/Dec/13  Updated: 25/Feb/14

Status: Open
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.2.0
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Trivial
Reporter: Matt Ingenthron Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The exit value for cbc verify is 0 even when the files differ. For example...

ingenthr-mbp:~ ingenthr$ dd if=/dev/urandom of=afile count=1024 bs=1024
1024+0 records in
1024+0 records out
1048576 bytes transferred in 0.082984 secs (12635886 bytes/sec)
ingenthr-mbp:~ ingenthr$ cbc create -f 3735928559 afile < afile
Stored "afile" CAS:cae1d52a4f000000
ingenthr-mbp:~ ingenthr$ cbc verify afile
ingenthr-mbp:~ ingenthr$ dd if=/dev/urandom of=afile count=1024 bs=1024
1024+0 records in
1024+0 records out
1048576 bytes transferred in 0.084461 secs (12414917 bytes/sec)
ingenthr-mbp:~ ingenthr$ cbc verify afile
Content differ: "afile"
ingenthr-mbp:~ ingenthr$ echo $?
0


By the way, that should be "contents differ".




Generated at Sun Apr 20 22:07:03 CDT 2014 using JIRA 5.2.4#845-sha1:c9f4cc41abe72fb236945343a1f485c2c844dac9.