[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





[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-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-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-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-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-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-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-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-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-362] OS X Homebrew script for C-SDK points at a downlevel version ... Created: 13/Apr/14  Updated: 16/Apr/14  Resolved: 16/Apr/14

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

Type: Bug Priority: Major
Reporter: adonoho Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: install
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: OS X v10.9.2


 Description   
Gentlefolk,

The Homebrew script for the C SDK on OS X still points at libcouchbase-2.2.0. As of this morning:

astraeus:~ awd$ brew install https://github.com/couchbase/homebrew/raw/stable/Library/Formula/libcouchbase.rb
######################################################################## 100.0%
Warning: libcouchbase-2.2.0 already installed
astraeus:~ awd$ brew upgrade https://github.com/couchbase/homebrew/raw/stable/Library/Formula/libcouchbase.rb
######################################################################## 100.0%
Error: libcouchbase-2.2.0 already installed

Please upgrade the script as part of your release process.

Anon,
Andrew


 Comments   
Comment by Mark Nunberg [ 13/Apr/14 ]
We've submitted a pull request to the main homebrew repo. Assigning to Sergey
Comment by Sergey Avseyev [ 13/Apr/14 ]
brew update?

it should be there https://github.com/Homebrew/homebrew/pull/28287
Comment by Matt Ingenthron [ 16/Apr/14 ]
It looks like it's up to date now:

ingenthr-mbp:~ ingenthr$ brew install libcouchbase
==> Downloading http://packages.couchbase.com/clients/c/libcouchbase-2.3.0.tar.g
######################################################################## 100.0%
==> ./configure --prefix=/usr/local/Cellar/libcouchbase/2.3.0 --disable-examples
==> make install
🍺 /usr/local/Cellar/libcouchbase/2.3.0: 118 files, 1.2M, built in 17 seconds




[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-366] download links in tutorial are redirecting to page with 404 status Created: 07/Apr/14  Updated: 16/Apr/14  Resolved: 16/Apr/14

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

Type: Bug Priority: Major
Reporter: Iryna Mironava Assignee: Amy Kurtzman
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: http://docs.couchbase.com/couchbase-sdk-c-1.0/


 Description   
http://docs.couchbase.com/couchbase-sdk-c-1.0/
Link from section Downloading the Couchbase Client Library is redirecting to http://files.couchbase.com/developer-previews/clients/couchbase-server-2.0.0-compatible/c/ with 404 error

 Comments   
Comment by Wayne Siu [ 16/Apr/14 ]
Amy,
Can you please check if the URL is correct? http://files.couchbase.com/developer-previews/clients/couchbase-server-2.0.0-compatible/c/
Comment by Amy Kurtzman [ 16/Apr/14 ]
This document is for the 1.0 version of the software, which is very old. Unless you have a specific reason to use such an old version, please refer to the documentation for the current release at http://docs.couchbase.com/couchbase-sdk-c-2.3/.

The current download page for the C library is at http://www.couchbase.com/communities/c-client-library.
Comment by Amy Kurtzman [ 16/Apr/14 ]
Updated link in the version 1.0 documentation.




[CCBC-363] Documentation for homebrew install points to unmaintained repository Created: 15/Apr/14  Updated: 15/Apr/14  Resolved: 15/Apr/14

Status: Resolved
Project: Couchbase C client library libcouchbase
Component/s: None
Affects Version/s: 2.3.0
Fix Version/s: .next
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://docs.couchbase.com/couchbase-sdk-c-2.3/index.html#installing-using-packages-on-mac-os-x

 Comments   
Comment by Mark Nunberg [ 15/Apr/14 ]
Fixed:

http://docs.couchbase.com/couchbase-sdk-c-2.3/#installing-using-packages-on-mac-os-x




[CCBC-214] Re-design internal operations in a queue/linked list structure Created: 21/May/13  Updated: 15/Apr/14  Resolved: 15/Apr/14

Status: Resolved
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: Fixed Votes: 0
Labels: packet-ng
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks CCBC-212 IO Enhancements Open




[CCBC-298] Transition from ringbuffers to separate packet structs Created: 27/Nov/13  Updated: 15/Apr/14  Resolved: 15/Apr/14

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

Type: Improvement Priority: Major
Reporter: Sergey Avseyev Assignee: Mark Nunberg
Resolution: Fixed Votes: 0
Labels: packet-ng
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
On Mon, Nov 25, 2013 at 1:25 PM, Trond Norbye <trond.norbye@couchbase.com> wrote:
> We should probably stop using the ringbuffers, and rather use a
> "buffer allocator" and allow the client to specify the allocator to
> use. Each packet sent / received would then belong in a separate
> buffer. The send stream would then consist of a chain of such buffer
> structures. The returned buffer should have some meta-data for the
> allocator (possibly a "destructor") and probably an IO vector for
> libcouchbase to use.


 Comments   
Comment by Sergey Avseyev [ 27/Nov/13 ]
The last release of libcouchbase fork for nginx is using packets instead of ringbuffers. The patch isn't compatible with current master, but might be re-implemented there.
https://github.com/avsej/libcouchbase/commits/nginx
Comment by Trond Norbye [ 02/Jan/14 ]
We may use something like https://github.com/trondn/libcouchbase/commit/62d2e3f3d62f7a8ec23a332e2d7654b161330f43 (it needs to be extended to have a method to call in order to let the allocator know that it is done with the object)
Comment by Matt Ingenthron [ 03/Jan/14 ]
Mark and Brett have been working on this change most recently. Changing the assignment to reflect that.
Comment by Brett Lawson [ 03/Jan/14 ]
Mark and I have been working on restructuring the handling of this such that all packets are composed of buffer objects which are allocated from a special sort of `pool allocator` which ensures contiguous allocations as often as possible, and excellent reuse of buffer space without negatively affecting performance in any serious way (internally it is still using ringbuffers, or more accurately, a group of ringbuffers) . The solution we have come up with also allows a couple of other useful 'features'. Such as the ability to pass user keys and values directly through to the IO layer without requiring any copying to be performed (though the user must ensure that the memory they allocated for the key/value stays alive until they receive the operation callback), additionally, the new allocation system allows us to store the same allocated buffer into the command log in case a retry or relocation of the packet must be made. Lastly, the allocator is vaguely generic and can be used for other kinds of allocations within libcouchbase which will permit us to take advantage of cacheing of memory loads in some of our hot paths.
Comment by Trond Norbye [ 03/Jan/14 ]
For the desired usecase here it is a requirement that the buffers may be moved between libcouchbase instances
Comment by Brett Lawson [ 03/Jan/14 ]
Thats fair, in that case, why is libcouchbase going to be the one in charge of handling the memory if the memory is no longer specific to libcouchbase then? The end-user can simply allocate their own memory however they wish, and pass it as-is to couchbase. If the operation fails, or needs to be dispatched to another libcouchbase instance, that same memory can be used to perform the second operation.
Comment by Trond Norbye [ 03/Jan/14 ]
It would be desirable to be able to get the entire packet (completely built up with headers) in callbacks when the packet is received from the network, and inject that in the stream to be sent in another libcouchbase instance (to avoid memory copying etc). That is part of the motivation driving this request.
Comment by Brett Lawson [ 03/Jan/14 ]
What of the opaque values? Additionally, I guess these are slightly different goals. The work Mark and I have been doing is primarily in relation to sending packets, however what your actually looking for is the ability to have user-allocated receive buffers. Are you sure that the cost of copying the packet from one `lcb pool` to the other is actually more than what will be necessary for having user-allocated receive buffers? I can see 2 ways of that working, one being that the user provides an allocator, and prior to a read, we allocate a `large` buffer to read contents into, however, because we are passing parts of this large buffer to the other libcouchbase instance, there are going to be a lot of allocations made, and a large amount of wasted space for `non-forwarded packets` that were received. The alternative method is to make a small allocation for the packet header, then receive that header into that buffer, then follow that up with an allocation for the rest of the packet, and receive into that, then set up a new header allocation, etc... This would also be a lot of allocations, and additionally would mean a `stall` in reading while the packet header is processed, slowing down the overall process significantly. I'm not at all saying your wrong, I just don't quite understand the purpose of the tradeoff here, I'm fairly certain that the whole read-stall process would be significantly slower than an aligned memory move.
Comment by Trond Norbye [ 03/Jan/14 ]
In the intended usecase the opaque values would actually map. In a multiplexer scenario you just want to fan out the packets to more nodes, and upon receiving the packets you just want to sort them before shipping them the other direction (but on that side you're not using libcouchbase, but another layer that have its own packet structure). Being able to specify the buffers you would be able to supply a sub-part of the buffer used in the other mechanism..
Comment by Brett Lawson [ 03/Jan/14 ]
So, the expected flow is essentially, lib-custom-protocol -> libcouchbase request, libcouchbase response -> lib-custom-protocol. In the case of the request side of that, the customers library can just 'give us' their memory that they want us to send, and we can put that directly into a send buffer and send it off without any further processing (this would be like a 10 line function). The point of our contention on this side is on receiving. What I was saying above is that our receive buffer implementation is incredibly fast, and sticking any sort of long-lived custom user-allocated receive buffer in there is going to be more of a performance hit than just doing a memcpy (which is remarkably fast anyways). Again though, I'm a bit confused which 'side' of travel we are talking about here. Also worth mentioning is if `lib-custom-protocol` just indiscriminately sends off the packet, you don't even need to copy the packet at all, just immediately pass off the packet while its still in the libcouchbase receive buffers and send it immediately before returning from the callback (although, this is probably unlikely, since the lib-custom-protocol would need to handle the case where the kernel send buffer is free, though they could just perform their own allocation at this point and do the copy here).
Comment by Mark Nunberg [ 03/Jan/14 ]
The opaque handling is a bit concerning to me. Recently we had a discussion about out-of-order response handling and came to the conclusion that we should not rely on the ordering of requests to match responses, but rather rely on the opaque field to uniquely identify a specific response for the request.

If incoming packets have a globally unique opaque then we can simply copy it; if they don't, however, then they must store the opaque inside their cookie structure and re-stamp the header as they send it back with the proper opaque.
Comment by Matt Ingenthron [ 03/Jan/14 ]
I'm not sure you need a globally unique opaque. The tuple of the source IP/port and the opaque can work here. Those could be mapped to our unique opaque for that downstream. Of course, I'm saying all of that without considering how the data lays out, but I'm just saying this could be lcb's responsibility instead of the caller's. We'd just need the caller to provide that additional unique requester information.
Comment by Mark Nunberg [ 15/Apr/14 ]
Done in packet-ng




[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-346] No errors emited when trying to cluster connect to invalid hosts Created: 13/Mar/14  Updated: 15/Apr/14  Resolved: 15/Apr/14

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

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


 Description   
When attempting to connect to an invalid host such as "999.99.99.99:8091", no errors are emitted, lcb_wait blocks after lcb_connect for an abnormal period of time, however no error is emitted from any calls or callbacks.

 Comments   
Comment by Mark Nunberg [ 20/Mar/14 ]
We can't actually "Connect" to the host unfortunately :( -- there's nothing to connect to when dealing with the "Cluster Manager"
Comment by Mark Nunberg [ 27/Mar/14 ]
http://review.couchbase.org/35005




[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




Generated at Sun Apr 20 00:58:46 CDT 2014 using JIRA 5.2.4#845-sha1:c9f4cc41abe72fb236945343a1f485c2c844dac9.