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

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

Type: Bug Priority: Major
Reporter: Xav M Assignee: Mark Nunberg
Resolution: Fixed 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.




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

[CCBC-111] Make iops functions 'private', and discourage calls to run_event_loop/stop_event_loop Created: 22/Oct/12  Updated: 24/Apr/14  Resolved: 24/Apr/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.0.0beta2
Fix Version/s: 2.4.0
Security Level: Public

Type: Technical task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks CCBC-222 Ensure examples feature correct iops ... In Progress

 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

 Comments   
Comment by Mark Nunberg [ 24/Apr/14 ]
This is private. Depending on the plugin implementation, run_event_loop/stop_event_loop will crash or do random things. Don't use it anymore




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

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

Type: Bug Priority: Major
Reporter: Tommie McAfee Assignee: Mark Nunberg
Resolution: Fixed 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.
Comment by Mark Nunberg [ 24/Apr/14 ]
I'm not _sure_ this is fixed in 2.3, but the purge_implicit_responses has been fixed in that version, so I'm assuming anything related to it is also fixed. Reopen if still having this issue.




[CCBC-382] Retry throttle queue Created: 21/Apr/14  Updated: 23/Apr/14  Resolved: 23/Apr/14

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

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


 Description   
This feature allows retries to be performed in a throttled fashion rather than immediately routing the failed item to a new node. This decreases network load and makes the retry handling nicer from a code level as well.




[CCBC-384] It is needed to handle WSAETIMEDOUT in iocp_w32err_2errno Created: 22/Apr/14  Updated: 23/Apr/14  Resolved: 23/Apr/14

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

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


 Description   
I have got WSAETIMEDOUT error when I libcouchbase with iocp plugin on Win32.

And because iocp_w32err_2errno doesn't handle WSAETIMEDOUT the default case was choosen and as
result my application was terminated by abort();

 Comments   
Comment by Haster [ 22/Apr/14 ]
I fixed it in my app by adding lines:

case WSAETIMEDOUT:
   return ETIMEDOUT;
Comment by Mark Nunberg [ 22/Apr/14 ]
http://review.couchbase.org/#/c/36140/

This will be fixed in 2.4.0 (not _next_ release, the one after that); for 2.3.1 it's sufficient to not abort.
Comment by Mark Nunberg [ 23/Apr/14 ]
http://review.couchbase.org/#/c/36140/




[CCBC-388] Release Notes are missing defects. Created: 23/Apr/14  Updated: 23/Apr/14  Resolved: 23/Apr/14

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

Type: Task Priority: Critical
Reporter: Patrick Varley Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: releasenote
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
I believe these 3 defect have also been fixed in 2.3.0 can you please update the release notes

http://www.couchbase.com/issues/browse/CCBC-321
http://www.couchbase.com/issues/browse/CCBC-320
http://www.couchbase.com/issues/browse/CCBC-281

Might be good to run your eye down this list incase any other bugs were missed of the release notes.

http://www.couchbase.com/issues/issues/?jql=project%20%3D%20CCBC%20AND%20fixVersion%20%3D%20%222.3.0%22

Thanks,
Patrick

 Comments   
Comment by Patrick Varley [ 23/Apr/14 ]
I just came across this:

http://www.couchbase.com/issues/secure/ReleaseNote.jspa?projectId=10070&version=11406
Comment by Mark Nunberg [ 23/Apr/14 ]
https://github.com/couchbaselabs/docs-ng/pull/114




[CCBC-385] It is needed to handle CMD_GET_REPLICA in failout_single_request function Created: 22/Apr/14  Updated: 22/Apr/14  Resolved: 22/Apr/14

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

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


 Description   
I tried to get data from replica. but some error was happend and because CMD_GET_REPLICA isn't handled in
failout_single_request function the lcb_assert("unexpected opcode while purging the server" && 0); was called
and my application was terminated.

I think it is needed to add CMD_GET_REPLICA handling like this:
static void failout_single_request(lcb_server_t *server,
                                   protocol_binary_request_header *req,
                                   struct lcb_command_data_st *ct,
                                   lcb_error_t error,
                                   const void *keyptr,
                                   lcb_size_t nkey,
                                   const void *packet)
...
    switch (req->request.opcode) {
    case PROTOCOL_BINARY_CMD_NOOP:
        break;
    case CMD_GET_LOCKED:
    case PROTOCOL_BINARY_CMD_GAT:
    case PROTOCOL_BINARY_CMD_GATQ:
    case PROTOCOL_BINARY_CMD_GET:
    case PROTOCOL_BINARY_CMD_GETQ:
    case CMD_GET_REPLICA: <- add this line!!!!
...


 Comments   
Comment by Mark Nunberg [ 22/Apr/14 ]
http://review.couchbase.org/#/c/36139/




[CCBC-379] lcb_cntl API to change LCB_DEFAULT_NODECONFIG_TIMEOUT Created: 21/Apr/14  Updated: 22/Apr/14  Resolved: 22/Apr/14

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

Type: Task Priority: Major
Reporter: Sergey Avseyev Assignee: Mark Nunberg
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Mark Nunberg [ 21/Apr/14 ]
https://github.com/couchbase/libcouchbase/blob/master/include/libcouchbase/cntl.h#L380-395
Comment by Sergey Avseyev [ 21/Apr/14 ]
Thank you
Comment by Mark Nunberg [ 22/Apr/14 ]
Not a duplicate per-se, but this already exists and is implemented.




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

Status: Resolved
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: Fixed 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 [ 22/Apr/14 ]
http://review.couchbase.org/#/c/35980/




[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: 22/Apr/14  Resolved: 22/Apr/14

Status: Resolved
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: Fixed 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
Comment by Sergey Avseyev [ 22/Apr/14 ]
http://review.couchbase.org/35981




[CCBC-289] Handle NOOP padding on GETQ relocation Created: 31/Oct/13  Updated: 21/Apr/14  Resolved: 21/Apr/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: library
Affects Version/s: 2.0.7, 2.1.3, 2.2.0
Fix Version/s: 2.4.0
Security Level: Public

Type: Task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Fixed 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
Comment by Mark Nunberg [ 21/Apr/14 ]
GETQ Is removed in 2.4.0




[CCBC-304] mystery query time out and views_timeout Created: 30/Dec/13  Updated: 21/Apr/14  Resolved: 21/Apr/14

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

Type: New Feature Priority: Critical
Reporter: Tao Wei Assignee: Mark Nunberg
Resolution: Fixed 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.
Comment by Mark Nunberg [ 21/Apr/14 ]
Closing this due to inactivity, the inability to reproduce, and the general belief that this has been fixed in 2.3.0




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

Status: Closed
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: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Mark Nunberg [ 21/Apr/14 ]
CCBC-344




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

Status: Resolved
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: Fixed 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




Generated at Thu Apr 24 19:29:03 CDT 2014 using JIRA 5.2.4#845-sha1:c9f4cc41abe72fb236945343a1f485c2c844dac9.