Couchbase

[PCBC-159] incorrect timeout exceptions during required-durability function tests Created: 05/Dec/12 Updated: 11/Dec/12 Resolved: 05/Dec/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	None
Affects Version/s:	1.1.0
Fix Version/s:	1.1.0
Security Level:	Public

Type:

Bug

Priority:

Blocker

Reporter:

Matt Ingenthron

Assignee:

Trond Norbye

Resolution:

Fixed

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Environment:

Mac OS 10.8
2.0 build 1971
1.1.0-dp4-76-g2f51ee9

Attachments:

packetdump-PCBC-159.pcapng

packetdump-PCBC-159_second-time.pcapng

php_test_results_20121205_0327.txt

php_test_results_20121205_0339.txt

php_test_results_20121205_0623.txt

php_test_results_20121205_0637.txt

Description

When running the tests with the build mentioned above, I relatively regularly receive timeouts during the sync tests. Given that the host is localhost and there is no active workload (and it's on ssd), these seem to indicate a problem with the implementation of the required-durability functions.

Comments

Comment by Matt Ingenthron [ 05/Dec/12 ]

logs showing the timeout exceptions. these don't have much data, but maybe there's something interesting?

Comment by Mark Nunberg [ 05/Dec/12 ]

I've seen this issue as well (but initially thought I was just having a slow cluster). I'm willing to bet the issue is in the timeout loop itself rather than in libcouchbase or in somewhere 'deeper', as the other Observe tests pass.

Additionally, they seem to take very long to complete (patch below does not).

What's odd is that I've run this through valgrind and it didn't show any particular errors, and the errors are not always reproducible.

fwiw, this seems to pass the tests

http://paste.scsys.co.uk/216801

Comment by Matt Ingenthron [ 05/Dec/12 ]

Attached a packet capture showing the same issues. I'm going to reconfigure the server and see if they go away, because I clearly see the polling, but I've not looked to see what's happening with the poll.

Comment by Matt Ingenthron [ 05/Dec/12 ]

Have a different failure under the remove scenario here. This isn't a timeout.

see:
packetdump-~~PCBC-159~~_second-time.pcapng
php_test_results_20121205_0637.txt

Comment by Trond Norbye [ 05/Dec/12 ]

http://review.couchbase.org/#/c/23103/1

[PCBC-158] assertion in removeOnePersist.phpt at Sync.inc:222 Created: 05/Dec/12 Updated: 11/Dec/12 Resolved: 05/Dec/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	library
Affects Version/s:	1.1.0
Fix Version/s:	1.1.0
Security Level:	Public

Type:

Bug

Priority:

Blocker

Reporter:

Matt Ingenthron

Assignee:

Trond Norbye

Resolution:

Duplicate

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Environment:

libcouchbase 2.0.0
Mac OS X 10.8

Attachments:

php_test_results_20121205_0403.txt

Description

Had reasons to run the tests to package things up. I ran into this failed assertion.

001+ Assertion failed.. dumping backtrace..
001- PHP_COUCHBASE_OK
002+ #0 CBTestFramework->dieCommon(Expected TRUE) called at [/Users/ingenthr/src/php-ext-couchbase/tests/cbtestframework/CBTestFramework.inc:113]
003+ #1 CBTestFramework->assertTrue(, The document was mutated) called at [/Users/ingenthr/src/php-ext-couchbase/tests/Sync.inc:222]
004+ #2 Sync->testRemoveOnePersist()
005+ #3 ReflectionMethod->invoke(Sync Object ([] => cbtestframework_error_handler,[handle] => Resource id #10,[oo] => Couchbase Object ([] => Resource id #11))) called at [/Users/ingenthr/src/php-ext-couchbase/tests/cbtestframework/CBTestFramework.inc:195]
006+ #4 CBTestFramework->runSingleTest(testRemoveOnePersist) called at [/Users/ingenthr/src/php-ext-couchbase/tests/cbtestframework/cbtest-phpt-loader.inc:19]
007+ #5 couchbase_phpt_runtest(Sync, testRemoveOnePersist) called at [/Users/ingenthr/src/php-ext-couchbase/tests/phpt/Sync/removeOnePersist.php:3]
008+ [CBTestFramework] Expected TRUE

Comments

Comment by Matt Ingenthron [ 05/Dec/12 ]

Setting this to a blocker until we know the nature of it.

Comment by Trond Norbye [ 05/Dec/12 ]

This is the same issue as ~~PCBC-159~~

[PCBC-153] move flush function to RESTful flush Created: 30/Nov/12 Updated: 11/Dec/12 Resolved: 04/Dec/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	None
Affects Version/s:	None
Fix Version/s:	1.1.0
Security Level:	Public

Type:

Improvement

Priority:

Critical

Reporter:

Matt Ingenthron

Assignee:

Trond Norbye

Resolution:

Fixed

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Flagged:

Release Note

Description

With Couchbase bucket types and memcached bucket types, the RESTful flush should always be used in Couchbase Server. Thus, the flush() function needs to be connected to the restful flush in libcouchbase:
https://github.com/couchbase/libcouchbase/blob/master/tools/cbc.cc#L947

Comments

Comment by Trond Norbye [ 30/Nov/12 ]

Is this really a _blocker_ and something we can't put in the release notes? I wouldn't assume a "non-working" flush for the couchbase buckets to be the biggest problem for people in production....

Comment by Trond Norbye [ 03/Dec/12 ]

http://review.couchbase.org/#/c/23014/

Comment by Jeff Minard [ 04/Dec/12 ]

I know this is already resolved, but I'd actually implement our own wrapper to detect "is bucket memcached? ok, flush as normal. else _alldocs, loop, delete(key)". It wasn't a big deal to implement, just annoying.

Comment by Matt Ingenthron [ 04/Dec/12 ]

Thanks Jeff

Use of _alldocs is not recommended or really supported in Couchbase Server 2.0. It works okay, but it can't walk the views in an optimal way and thus churns through disk.

The RESTful flush should be relatively speedy and will definitely be speedy in the long term and safe.

Comment by Trond Norbye [ 04/Dec/12 ]

The rest way should also work for me cached buckets

[PCBC-150] make default view timeout 75s Created: 21/Nov/12 Updated: 11/Dec/12 Resolved: 11/Dec/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	None
Affects Version/s:	1.1.0-dp1, 1.1.0-dp2, 1.1.0-dp3, 1.1.0-dp4, 1.1.0-dp5
Fix Version/s:	1.1.0
Security Level:	Public

Type:

Improvement

Priority:

Blocker

Reporter:

Matt Ingenthron

Assignee:

Trond Norbye

Resolution:

Fixed

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Description

Since the server side view timeout is 60s, we should raise the client side a bit higher. 75s seems like the right number.

It must also be tuneable through the constructor to the client or the .ini file or both.

Comments

Comment by Matt Ingenthron [ 26/Nov/12 ]

Per discussion with Trond, we don't currently do anything for timeout other than the default libcouchbase timeout. On this issue, we'll change the timeout to the 75s standard.

For what it's worth, it wouldn't hurt my feelings if we were to create a second timeout in libcouchbase for http requests. Maybe there is one already? The only problem with that is that the API/ABI in libcouchbase is required to be stable for now (since we hit Beta).

Comment by Trond Norbye [ 06/Dec/12 ]

http://review.couchbase.org/23118

[PCBC-149] persist_to should imply master when greater than zero Created: 19/Nov/12 Updated: 11/Dec/12 Resolved: 23/Nov/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	None
Affects Version/s:	1.1.0-dp5
Fix Version/s:	1.1.0
Security Level:	Public

Type:

Bug

Priority:

Blocker

Reporter:

Mark Nunberg

Assignee:

Mark Nunberg

Resolution:

Fixed

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Description

Currently persist_to in the observe array will consider the criteria satisfied when *any* combination of nodes say that the key is persisted. The client should ensure that at least one of those nodes is the master.

[PCBC-148] Key persistence checks wrong criterion Created: 19/Nov/12 Updated: 11/Dec/12 Resolved: 23/Nov/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	None
Affects Version/s:	1.1.0-dp5
Fix Version/s:	1.1.0
Security Level:	Public

Type:

Bug

Priority:

Blocker

Reporter:

Mark Nunberg

Assignee:

Mark Nunberg

Resolution:

Fixed

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Description

Derived from ~~MB-7161~~. I've got a fix for this, but just wanted to note it here.

[PCBC-147] Segmentation Fault (segfault) when querying view Created: 15/Nov/12 Updated: 19/Nov/12 Resolved: 19/Nov/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	library
Affects Version/s:	1.1.0-dp5
Fix Version/s:	1.1.0
Security Level:	Public

Type:

Bug

Priority:

Blocker

Reporter:

Jeff Minard

Assignee:

Mark Nunberg

Resolution:

Fixed

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Environment:

PHP 5.3.13 / 5.3.15, Redhat 5.6

Attachments:

cbt.php

gdb-bt-git.txt

gdb-bt.txt

gdb.txt

php-m-i.txt

strace.txt

Description

When doing a query against a view, the php application segfaults. Set/get/delete commands all work fine.

Attached is an strace, a stack trace from gdb, and various other support files, including the repro script.

Comments

Comment by Jeff Minard [ 15/Nov/12 ]

I was asked to run a gdb, but I don't really think it looks that helpful. I've attached it.

Comment by Jeff Minard [ 15/Nov/12 ]

gdb file, looks pretty useless without a php debug symbols version

Comment by Mark Nunberg [ 15/Nov/12 ]

My bad. Type 'bt' when you get the segfault :)

That'll show you the stack trace

Comment by Jeff Minard [ 15/Nov/12 ]

Yes, this looks much more helpful :)

Comment by Jeff Minard [ 15/Nov/12 ]

Here is the same segfault when using the latest couchbase.so compiled from the github master branch (so, cutting edge, I'd seen some lcb changes, so I figured I'd give ya both).

Comment by Mark Nunberg [ 15/Nov/12 ]

Can you try this patch?

diff --git a/views.c b/views.c
index 6c7bc30..7d03c5a 100644
--- a/views.c
+++ b/views.c
@@ -52,12 +52,13 @@ void php_couchbase_complete_callback(lcb_http_request_t request,
                return;
        }

+ /** We have one extra byte in 'data' */
        hti = emalloc(sizeof(*hti) + resp->v.v0.nbytes);
        hti->ndata = resp->v.v0.nbytes;
- memcpy(hti->data, resp->v.v0.bytes, hti->ndata + 1);
+
        if (hti->ndata) {
- hti->data[hti->ndata - 1] = '\0';
- hti->ndata--;
+ memcpy(hti->data, resp->v.v0.bytes, hti->ndata);
+ hti->data[hti->ndata] = '\0';
        }

        ctx->res->rc = error;

I'll make it as a gerrit changeset as well..

Comment by Mark Nunberg [ 15/Nov/12 ]

http://review.couchbase.org/22573

Comment by Jeff Minard [ 15/Nov/12 ]

That changed fixed the segfault, yes. The value assigned to the variable from the $cb->view() call is bool(false)

Comment by Matt Ingenthron [ 15/Nov/12 ]

Thanks for the quick work Mark! Looks like it'll be closeable after it's reviewed and in.

[PCBC-144] getVersion() returns memcached version, not couchbase version Created: 10/Nov/12 Updated: 11/Dec/12 Resolved: 06/Dec/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	library
Affects Version/s:	1.1.0-dp5
Fix Version/s:	1.1.0
Security Level:	Public

Type:

Improvement

Priority:

Minor

Reporter:

Michael Nitschinger

Assignee:

Trond Norbye

Resolution:

Won't Fix

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Description

For whatever reason, when doing getVersion() on the php ext the showed version is not the couchbase one. I assume its the memcached one, but I think this will only confuse people.

Is it possible to change this to the corresponding couchbase version?

array(2) {
  '192.168.56.101:11210' =>
  string(18) "1.4.4_600_g7ea975a"
  '192.168.56.102:11210' =>
  string(18) "1.4.4_600_g7ea975a"
}

Michael

Comments

Comment by Matt Ingenthron [ 11/Nov/12 ]

Unfortunately, this is a bit correct. The memcached protocol "version" command returns that string. We're simply returning what the server says. I know it's a bit confusing in this instance. I think I'd asked for this behavior, but maybe we need to reconsider it a bit.

Comment by Matt Ingenthron [ 11/Nov/12 ]

Trond: not assigning this to you to fix it, but rather just to get your opinion on what we should do here.

We have a getVersion() which maps to the memcached protocol version command. Given that our server returns this string, should we change the behavior of getVersion() on the client?

My current feeling is no. Besides, this issue has never been reported by a real user. We're staying true to the interface we intended to implement, it's not our fault that the string coming back is confusing.

What do you think?

Comment by Trond Norbye [ 12/Nov/12 ]

I don't have a printout of what the REST response from the server looks like, but I think we should add a call to the library we may use to retrieve that version. I don't think we should change the current getVersion() (in case someone use that already), but rather have something like getClusterVersion (or getNodeVersion). The cluster may be running multiple versions during an upgrade scenario...

Comment by Michael Nitschinger [ 12/Nov/12 ]

If this is easily achievable, I'd definitely vote for it. It could be done the same way as getVersion() that returns an array for each node with the corresponding version.

Comment by Trond Norbye [ 06/Dec/12 ]

This is easily achieved with something among the lines of:

<?php
$cb = new CouchbaseClusterManager("localhost", "Administrator", "asdasd");
$info = json_decode($cb->getInfo());
foreach ($info->{"nodes"} as $node) {
print $node->{"hostname"} . " is running " . $node->{"version"} . "\n";
}
?>

[PCBC-143] segfault during lcb handle-level error handler Created: 09/Nov/12 Updated: 11/Dec/12 Resolved: 15/Nov/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	None
Affects Version/s:	1.0.4, 1.1.0-dp5
Fix Version/s:	1.1.0
Security Level:	Public

Type:

Bug

Priority:

Blocker

Reporter:

Mark Nunberg

Assignee:

Mark Nunberg

Resolution:

Fixed

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Issue Links:

Dependency
depends on	~~CCBC-120~~	Unhandled opcode=92	Closed

Description

This is related to ~~CCBC-120~~ (stack trace there). Will fix accordingly soon.

Basically the error handler checks for the 'ctx' which is not reset in-between calls.

The ideal solution should be for start_loop to accept a cookie argument and call lcb_set_cookie on it. This way there is always a valid cookie.

Otherwise the cookie remains a stale pointer and when the global error handler is called, it crashes.

Comments

Comment by Mark Nunberg [ 12/Nov/12 ]

http://review.couchbase.org/#/c/22426/

[PCBC-142] Plug leaks reported by debug-mode php/zts Created: 09/Nov/12 Updated: 11/Dec/12 Resolved: 12/Nov/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	None
Affects Version/s:	None
Fix Version/s:	1.1.0
Security Level:	Public

Type:

Bug

Priority:

Major

Reporter:

Mark Nunberg

Assignee:

Trond Norbye

Resolution:

Fixed

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Description

PHP_COUCHBASE_OK
[Fri Nov 9 14:45:38 2012] Script: '/sources/lcb2.0-repo/php/tests/phpt/Serialization/MixedSerializationErrors.php'
/sources/php-5.3.17/Zend/zend_execute_API.c(987) : Freeing 0x018EF248 (32 bytes), script=/sources/lcb2.0-repo/php/tests/phpt/Serialization/MixedSerializationErrors.php
=== Total 1 memory leaks detected ===PHP_COUCHBASE_OK
[Fri Nov 9 14:45:39 2012] Script: '/sources/lcb2.0-repo/php/tests/phpt/Serialization/SerializeJsonArrayMixed.php'
/sources/php-5.3.17/Zend/zend_execute_API.c(987) : Freeing 0x018086E0 (32 bytes), script=/sources/lcb2.0-repo/php/tests/phpt/Serialization/SerializeJsonArrayMixed.php
=== Total 1 memory leaks detected ===PHP_COUCHBASE_OK
[Fri Nov 9 14:45:39 2012] Script: '/sources/lcb2.0-repo/php/tests/phpt/Serialization/SerializeJsonObjectMixed.php'
/sources/php-5.3.17/Zend/zend_execute_API.c(987) : Freeing 0x026C65F8 (32 bytes), script=/sources/lcb2.0-repo/php/tests/phpt/Serialization/SerializeJsonObjectMixed.php
=== Total 1 memory leaks detected ===mnunberg@csure:/sources/lcb2.0-repo/php$

Comments

Comment by Mark Nunberg [ 12/Nov/12 ]

This should've been closed (fixed, merged), sorry :)

[PCBC-141] 1.1 dp releases not working on phps which do not export the symbol php_json_encode Created: 07/Nov/12 Updated: 10/May/13 Resolved: 10/May/13
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	library
Affects Version/s:	1.1.0-dp5
Fix Version/s:	1.1.0
Security Level:	Public

Type:

Bug

Priority:

Blocker

Reporter:

Mark Nunberg

Assignee:

Matt Ingenthron

Resolution:

Duplicate

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Description

This affects all php binaries which do not have the symbol "php_json_encode". This includes EL5 and EL6 based linux distributions

The library cannot load because the symbol is not found. Disabling using this symbol also means preventing views from functioning (as well as JSON serialization).

I'd like to note that this is not our bug and not our fault. We are probably not the only extension relying on php_json* functions, and package creators (specifically redhat) should expose this symbol.

Additionally, our configure script checks to see if the PHP_JSON_* constants are defined (and if not, compiles out the relevant code from views - this would make views not work, but not prevent the library from loading).

In any event, we should find a way to work around this, as this bug has been seen quite a bit.

One possible solution would be to call the php-level json encoding function. It may incur a bit of overhead from calling into php, but the function itself is more likely to be there.

Comments

Comment by Mark Nunberg [ 07/Nov/12 ]

Currently the only workaround is to compile your own php

Comment by Matt Ingenthron [ 07/Nov/12 ]

One other solution that I'd be okay with is to simply uplevel our minimum version of CentOS/RHEL. Unless there's significant pushback, I really don't see any reason to keep people living with ancient code for longer and longer periods of time.

Dissenting opinions accepted, but at some point you have to say "we don't support that because it's broken", right?

Do you think it's likely that some minimum 5.x EL is fixed enough? Or there's some patchlevel that is fixed enough?

If on the other hand, it's just conscious decision to not expose that symbol and it's only supported through PHP land, then calling up there as a workaround seems okay by me.

Comment by Matt Ingenthron [ 07/Nov/12 ]

Assigning this to the subject matter expert for now. Will hopefully pick it back up soon.

Comment by Matt Ingenthron [ 07/Nov/12 ]

One other question, I don't think so, but is this possibly related to need to put the ini for loading the extension after the php_json as an extension?

Another possible workaround is that if the license is permissive enough, we could just suck in the parts we need? Possible API/ABI issues here I guess, but hard to say.

Comment by Matt Ingenthron [ 07/Nov/12 ]

Duh, I see you proactively addressed the "which release" in the original description. Thanks for that.

Comment by Mark Nunberg [ 07/Nov/12 ]

I've explored that possibility. The problem is that on rhel and centos don't export that symbol. EPEL actually contains a json.so (php-pecl-json), but much to our my chagrin, it does not export that symbol either.

I was thinking about sticking the significant bits inside our own code.. it'd probably be easier to just call the php level function though..

This does seem to be a conscious decision by redhat - as this happens in CentOS 6.3 (EL6) as well. So this is obviously not fixed anywhere.

Comment by Mark Nunberg [ 10/Nov/12 ]

http://review.couchbase.org/#/c/22425/

Comment by Mark Nunberg [ 10/Nov/12 ]

The problem is a bit more intricate it seems :)

Apparently some of the json.so modules I've seen *do* export the php_json_* functions. HOWEVER, apparently php loads these modules with a line similar to dlopen(mod, RTLD_LOCAL..) making their symbols unavailable for other modules to use.

A more complex workaround:

static void (*_json_encode)(smart_str*, zval*, int TSRMLS_DC) = NULL;
static void (*_json_decode)(zval*, char*, int, zend_bool, long TSRMLS_DC) = NULL;

static void _init_json_symbols(void)
{
        zend_module_entry *m_ent;
        int ret;
        if (_json_encode) {
                return;
        }

        ret = zend_hash_find(&module_registry, "json", sizeof("json"), (void**)&m_ent);

        if (ret == FAILURE) {
                fprintf(stderr, "Couldn't load extension..\n");
                abort();
        }

        _json_encode = DL_FETCH_SYMBOL(m_ent->handle, "php_json_encode");
        _json_decode = DL_FETCH_SYMBOL(m_ent->handle, "php_json_decode");

        if (_json_encode == NULL || _json_decode == NULL) {
                fprintf(stderr, "Coudln't find JSON handles!: %s\n", dlerror());
                abort();
        }
}

void php_json_encode(smart_str *buf, zval *value, int options TSRMLS_DC)
{
        _init_json_symbols();
        _json_encode(buf, value, options TSRMLS_CC);
}

void php_json_decode(zval *out, char *buf, int len, zend_bool assoc, long depth TSRMLS_DC)
{
        _init_json_symbols();
        _json_decode(out, buf, len, assoc, depth TSRMLS_CC);
}

Comment by Matt Ingenthron [ 11/Nov/12 ]

Very interesting. Why is this done only on RHEL/CentOS? We should check with some PHP internals folks before we go too far here. Maybe there's some subtlety we don't understand.

Comment by Pierre Joye [ 11/Nov/12 ]

hi!

Not sure what RHEL5/6 does but PHP 5.3.2 has these APIs exported since the very 1st day:

https://github.com/php/php-src/blob/php-5.3.2/ext/json/php_json.h

Also json has always been a default extension in PHP, again something wrong at RHEL.

I would suggest to add a configure check to see if it is exposed and refused to compile if it is missing. To me it is a bug in RHEL (not the 1st weird one :) and would not begin to duplicate code around (especially not for json, to ensure 100% compatibility and get all fixes in time).

Comment by Mark Nunberg [ 11/Nov/12 ]

The real problem is in the first line I mentioned; and it might be a change in the arguments of dlopen. If the json extension is truly loaded before the couchbase one, then the couchbase ext *should* find the appropriate symbols to use.

However it seems that for RHEL (I haven't checked on debian.. debian builds the json ext into the php executable itself, rhel provides it as a loadable module) even though the json extension is already loaded, because there is something weird with either the way it uses dlopen (default php header macro for DL_LOAD uses RTLD_GLOBAL, i.e. make the symbols global to the entire app.. but it might be that RHEL uses RTLD_LOCAL...).

But we're not duplicating code here and I personally like the call-to-php solution (even though it's not the most elegant, it's the most predictable/reliable. For example, I don't know how the snippet in my last post would work on a php that doesn't have json as a DSO)

Comment by Mark Nunberg [ 11/Nov/12 ]

So it seems we're (or is it only me) looking at it from multiply wrong ways :)

(1) RHEL (and debian) modify the default php DL_LOAD from using RTLD_LAZY (which would have avoided giving us this error) to RTLD_NOW

(2) On Debian this is not a problem (at least not for JSON) since it's compiled into the php binary

(3) Even on RHEL, placing extension=json.so before extension=couchbase.so seems to do the trick. This is mentioned in the documentation

(4) For tests, run-tests.php will not work. Unless a specifically crafted ini file is written, run-tests.php will not load the json extension at all. Defining an extra -d parameter will load the json extension; however the script counter-intuitively *appends* this option to the commandline, so one thus effectively has:

-d extension=couchbase.so -d extension=json.so

Coupled with RTLD_NOW, this fails.

I'd still like to fix this in code; as this is a fairly confusing matter; if only to be able to print out a more meaningful user message.

Comment by Pierre Joye [ 11/Nov/12 ]

1) Not sure that should cause this error, as long as the loading order is respected.

2) Debian does it right. JSON is a default builtin extension and should always be available, not optionally.

3) Yes, loading order, that should be documented as such in the couchbase install documentation

4) yes, it is expected, also using a php.ini is always a good thing, to avoid tests failure due to random php.ini being caught

There is nothing to fix in couchbase, calling user land function is horribly slow and should really not be done for such thing.

Comment by Mark Nunberg [ 11/Nov/12 ]

The fix here would be to make users understand this a bit better.

The point isn't that something is broken, but rather that something is confusing. This issue is hinted in the couchbase ext documentation, but seems to be passed over by quite a few people who have run into this.

This seems like a very subtle configuration aspect which users shouldn't have to encounter; or at least something in which we'd be able to show the user an error message.

So without going into a debate of terminology about what's "broken" and whose "fault" it is, this is something that lots of users are seeing, and shouldn't. Such fine minutiae really isn't easy to pick up.

Another option would have been to load the symbols dynamically from either the binary or from the loaded library (depending on the configuration) - however 'php_json_decode' is now no longer an exported symbol (it's defined in the header as an inline wrapper around php_json_decode_ex) in some versions.

Comment by Pierre Joye [ 11/Nov/12 ]

ext dependencies are a very common issue in php, this is well documented. I won't change anything in the code (causing more arms) and clearly document that the json ext, for old broken (it is broken, as it must be builtin and always enabled) distribution packages.

Comment by Matt Ingenthron [ 11/Nov/12 ]

Thanks for all the help here Pierre.

According to Mark, this doesn't affect only old, broken distribution packages. It's even in recent RHEL6*.

Just to fix this with the simplest, most supportable solution perhaps we should test the function at startup time and if it's not there log and exit appropriately? If the distro is loading that lazily, and people want to use that distro, then they need to configure their PHP .ini's correctly, right?

Our log message can be explicit even, saying "make sure json whatever is loaded first with your php.ini".

Thoughts?

* which maybe is arguably old, broken, but it's also arguably not since it's the most recent thing shipped on this particular distro fork

Comment by Matt Ingenthron [ 11/Nov/12 ]

Pierre: one other question-- any 'prior art' here? In other words, surely some other extension must rely on json and has an approach?

Comment by Mark Nunberg [ 11/Nov/12 ]

Unfortunately there is no way to configure RHEL's php to load things lazily.

RHEL Specifically mangles this.

I know the patch says 5.0.4, but this is still in php-5.3.3-14.el6_3.src.rpm:

--- php-5.0.4/Zend/zend.h.dlopen
+++ php-5.0.4/Zend/zend.h
@@ -102,11 +102,11 @@
# endif

# if defined(RTLD_GROUP) && defined(RTLD_WORLD) && defined(RTLD_PARENT)
-# define DL_LOAD(libname) dlopen(libname, RTLD_LAZY | RTLD_GLOBAL | RTLD_GROUP | RTLD_WORLD | RTLD_PARENT)
+# define DL_LOAD(libname) dlopen(libname, RTLD_NOW | RTLD_GLOBAL | RTLD_GROUP | RTLD_WORLD | RTLD_PARENT)
# elif defined(RTLD_DEEPBIND)
-# define DL_LOAD(libname) dlopen(libname, RTLD_LAZY | RTLD_GLOBAL | RTLD_DEEPBIND)
+# define DL_LOAD(libname) dlopen(libname, RTLD_NOW | RTLD_GLOBAL | RTLD_DEEPBIND)
# else
-# define DL_LOAD(libname) dlopen(libname, RTLD_LAZY | RTLD_GLOBAL)
+# define DL_LOAD(libname) dlopen(libname, RTLD_NOW | RTLD_GLOBAL)
# endif
# define DL_UNLOAD dlclose
# if defined(DLSYM_NEEDS_UNDERSCORE)
~

So basically by the time our library loads, if it utilizes a bare 'json_decode' that reference is resolved immediately; our module has no chance to warn.

Comment by Matt Ingenthron [ 12/Nov/12 ]

Given there is no good solution, for now we'll need to document this one very, very well.

Comment by Karen Zeller [ 12/Nov/12 ]

I don't do the release notes for individual SDK libraries.

Comment by Matt Ingenthron [ 12/Nov/12 ]

This isn't a release note item, this is a PHP documentation item. This needs to be added to the getting started guide with a really clear description of what the issue is and how to work around it for RHEL/CentOS.

I think you're still able to help us with PHP documentation, right?

Comment by Karen Zeller [ 12/Nov/12 ]

I see. Do you want this to go as a note during the platform-specific install section under RHEL/Centos?

Comment by Matt Ingenthron [ 12/Nov/12 ]

I'll follow the docs team's guidance on how best to present the info.

Just be aware that it's something we've frequently hit and nearly every CentOS/RHEL user will hit it too. It's not our bug really that we can't make it simpler. It's a limitation in current PHP extension loading.

That's why I think it needs to be covered in the appropriate section of the getting started guide, which is both on the web site (http://www.couchbase.com/develop/php/next) and in our documentation (http://www.couchbase.com/docs/couchbase-sdk-php-1.1/download.html and http://www.couchbase.com/docs/couchbase-sdk-php-1.1/installation-verification.html). Most people will hit it when following either of those.

Our web pages currently have the following note:
Note: With the PHP packages on many Red Hat/CentOS distributions (and possibly others), PHP's JSON encoding is not available to other extensions by default. As a result, you may see an error resolving the php_json_encode symbol. The solution is to edit ini file that loads the JSON extension (typically /etc/php.d/json.ini) to add the Couchbase extension after the JSON extension.

Something along these lines (but improved, if you think need be) should be added to the getting started guide in the documentation.

Comment by Matt Ingenthron [ 12/Nov/12 ]

Note, Pierre replied via email to my 'prior art' question:

No, ext dep manager is a long due todo but much easier to document than to implement.

Other core exts have this, exif and mbstring, pdo exts and the sin pdo ext (which should be builtin but rhel and defiant made it wrong 1st)

Comment by Karen Zeller [ 14/Nov/12 ]

Hi,

I'm adding this. Do we have an example of the php_json_encode error that you will get? Need to add this to the section.

Comment by Karen Zeller [ 14/Nov/12 ]

Added to getting started/install as:

"If you are using the PHP SDK on a Linux distribution such as Red Hat/CentOS, be aware that JSON encoding for PHP is by default not available to other extensions. As a result you will receive an error resolving the php_json_encode symbol. The solution is to edit the .ini file that loads the JSON extension to add the Couchbase extension after the JSON extension. For instance, if your JSON extension is at /etc/php.d/json.ini, add the following line to the file under extensions:

extension=/path/to/couchbase.so"

Comment by Karen Zeller [ 14/Nov/12 ]

Added to getting started and install for PHP 1.1:

If you are using the PHP SDK on a Linux distribution such as Red Hat/CentOS, be aware that JSON encoding for PHP is by default not available to other extensions. As a result you will receive an error resolving the php_json_encode symbol. The solution is to edit the .ini file that loads the JSON extension to add the Couchbase extension after the JSON extension. For instance, if your JSON extension is at /etc/php.d/json.ini, add the following line to the file under extensions:

extension=/path/to/couchbase.so

Comment by Matt Ingenthron [ 28/Nov/12 ]

Karen: per the email thread with Mark Nunberg the other day, can we update this to have the two line recommendation? Perhaps that's what you've already done?

Comment by Karen Zeller [ 28/Nov/12 ]

Oh yes, I did update per Mark's email several days ago. It is now:

Depending on the platform you are using, you may also need to reference the JSON library in your PHP configuration file.

If you are using the Couchbase PHP SDK on Red Hat/CentOS or their derivatives, be aware that JSON encoding for PHP is by default not available to other extensions. As a result you will receive an error resolving the php_json_encode symbol. The solution is to edit the php.ini file to load the JSON library and also load the Couchbase library. For instance, if your extensions are at /etc/php.ini, add the following two lines to the file:

extension=/path/to/json.so
extension=/path/to/couchbase.so
The reference to the two extensions must be in this specific order.

You can see it here:

http://www.couchbase.com/docs/couchbase-sdk-php-1.1/download.html

Comment by Karen Zeller [ 28/Nov/12 ]

Comment by Andrey Nikishaev [ 17/Dec/12 ]

Use version 1.1.1 of client lib and still get this error even when couchbase.so loaded after json.so

CentOS 5.6, PHP 5.2.17, Couchbase 1.8

Comment by Karen Zeller [ 17/Dec/12 ]

Hi Matt,

This was reported as an technical issue still with PHP SDK:

[ http://www.couchbase.com/issues/browse/PCBC-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=46067#comment-46067 ]

Andrey Nikishaev commented on ~~PCBC-141~~:
---------------------------------------

Use version 1.1.1 of client lib and still get this error even when couchbase.so loaded after json.so

Comment by Mark Nunberg [ 17/Dec/12 ]

what's the exact error you're getting?

Maybe the json module needs to be installed as well? (I'll need to check this) --

Comment by Matt Ingenthron [ 17/Dec/12 ]

Andrey: We do not support PHP 5.2, so you'll want to try 5.3 or later. CentOS 5.6 does have, if I recall correctly, a "php53" package.

Comment by Trond Norbye [ 10/May/13 ]

There are multiple bugs reported for this issue

[PCBC-139] PHP client needs fastlz compression to be compatible with legacy memcached clients Created: 01/Nov/12 Updated: 11/Dec/12 Resolved: 16/Nov/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	library
Affects Version/s:	1.0.4
Fix Version/s:	1.0.6, 1.1.0
Security Level:	Public

Type:

Bug

Priority:

Blocker

Reporter:

Tim Smith

Assignee:

Trond Norbye

Resolution:

Fixed

Votes:

Labels:

customer

Remaining Estimate:

16h

Time Spent:

Not Specified

Original Estimate:

16h

Environment:

With both php-ext-couchbase-1.0.5-centos55-x86_64.tar.gz and php-ext-couchbase-1.0.6b23_centos-5.5-x64.tar.gz. I will attach php -i output as a separate comment. Using php-pecl-memcached extension 1.0.0. libmemcached 1.0.4.

Attachments:

couchbase.so.gz

Issue Links:

Dependency

Description

The existing memcached clients for PHP (pecl-memcached and memcache) both default to using fastlz compression for values >= 2000 bytes.

The couchbase client library doesn't have fastlz compression included. It doesn't provide a useful error message when it runs into this problem. Instead, it misinterprets the stored value, tries to allocate a huge block of memory and fails. The error it gives (look, e.g., in the PHP-FPM web-access.log) is:

[01-Nov-2012 20:45:49 UTC] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 8460104323416721361 bytes) in /usr/share/nginx/html/cb.php on line 32

To reproduce, just set a value >= 2000 bytes with pecl-memcached client, and try to read it with Couchbase client. Here's a sample:

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Couchbase Server PHP Test</title>
</head>
<body>


<?php

$host = "10.4.2.15";
$user = "Administrator";
$password = "password";
$bucketName = "default";
$persistConnection = false;
$cb = new Couchbase($host . ":8091",
 $user, $password, $bucketName, $persistConnection);

$mc = new Memcached('Pool-1');
if (count($mc->getServerList()) == 0) {
 // No servers, this pool needs to be configured
 $mc->addServer($host, 11211);
 //$mc->addServer("other host", 11211);
}

// Change this to 1999 and it will work
$valLength = 2000;
date_default_timezone_set('UTC');
$val = date(DateTime::RFC2822) . ' ';
$val .= str_repeat('X', $valLength - strlen($val));

$mc->set("a", $val);
echo("The value for 'a' is: ");
var_dump($cb->get("a"));

?>

</body>
</html>

The correct behavior is for the Couchbase client to ship, out of the box, compatible with existing Memcached client implementations. It should include fastlz support directly, or else clearly document how to add such support without requiring any unusual compilations or other hoops. The fastlz code is very small and portable, and hasn't changed since 2007, so it should present a minimal maintenance issue.

In addition, the PHP client documentation should clearly indicate what changes are needed in order for the client to be compatible with the other Couchbase clients (Java, .NET, etc.). Again, without requiring recompilation or extra hoops to jump through.

Comments

Comment by Tim Smith [ 01/Nov/12 ]

phpinfo()
PHP Version => 5.3.15

System => Linux localhost.localdomain 2.6.18-308.16.1.el5 #1 SMP Tue Oct 2 22:01:43 EDT 2012 x86_64
Build Date => Jul 20 2012 13:07:19
Configure Command => './configure' '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--cache-file=../config.cache' '--with-libdir=lib64' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--disable-debug' '--with-pic' '--disable-rpath' '--without-pear' '--with-bz2' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-xpm-dir=/usr' '--enable-gd-native-ttf' '--with-t1lib=/usr' '--without-gdbm' '--with-gettext' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-zlib' '--with-layout=GNU' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-sockets' '--with-kerberos' '--enable-ucd-snmp-hack' '--enable-shmop' '--enable-calendar' '--with-libxml-dir=/usr' '--enable-xml' '--with-system-tzdata' '--with-mhash' '--enable-force-cgi-redirect' '--libdir=/usr/lib64/php' '--enable-pcntl' '--with-imap=shared' '--with-imap-ssl' '--enable-mbstring=shared' '--enable-mbregex' '--with-gd=shared' '--enable-bcmath=shared' '--enable-dba=shared' '--with-db4=/usr' '--with-xmlrpc=shared' '--with-ldap=shared' '--with-ldap-sasl' '--enable-mysqlnd=shared' '--with-mysql=shared,mysqlnd' '--with-mysqli=shared,mysqlnd' '--with-mysql-sock=/var/lib/mysql/mysql.sock' '--with-oci8=shared,instantclient,/usr/lib64/oracle/11.2/client64/lib,11.2' '--with-pdo-oci=shared,instantclient,/usr,11.2' '--with-interbase=shared,/usr/lib64/firebird' '--with-pdo-firebird=shared,/usr/lib64/firebird' '--enable-dom=shared' '--with-pgsql=shared' '--enable-wddx=shared' '--with-snmp=shared,/usr' '--enable-soap=shared' '--with-xsl=shared,/usr' '--enable-xmlreader=shared' '--enable-xmlwriter=shared' '--with-curl=shared,/usr' '--enable-fastcgi' '--enable-pdo=shared' '--with-pdo-odbc=shared,unixODBC,/usr' '--with-pdo-mysql=shared,mysqlnd' '--with-pdo-pgsql=shared,/usr' '--with-pdo-sqlite=shared,/usr' '--with-pdo-dblib=shared,/usr' '--without-sqlite3' '--with-sqlite=shared,/usr' '--enable-json=shared' '--enable-zip=shared' '--without-readline' '--with-libedit' '--with-pspell=shared' '--enable-phar=shared' '--with-mcrypt=shared,/usr' '--with-tidy=shared,/usr' '--with-mssql=shared,/usr' '--enable-sysvmsg=shared' '--enable-sysvshm=shared' '--enable-sysvsem=shared' '--enable-posix=shared' '--with-unixODBC=shared,/usr' '--enable-fileinfo=shared' '--enable-intl=shared' '--with-icu-dir=/usr' '--with-enchant=shared,/usr' '--with-recode=shared,/usr'
Server API => Command Line Interface
Virtual Directory Support => disabled
Configuration File (php.ini) Path => /etc
Loaded Configuration File => /etc/php.ini
Scan this dir for additional .ini files => /etc/php.d
Additional .ini files parsed => /etc/php.d/curl.ini,
/etc/php.d/fileinfo.ini,
/etc/php.d/igbinary.ini,
/etc/php.d/json.ini,
/etc/php.d/memcached.ini,
/etc/php.d/phar.ini,
/etc/php.d/zip.ini,
/etc/php.d/zzz-couchbase.ini

PHP API => 20090626
PHP Extension => 20090626
Zend Extension => 220090626
Zend Extension Build => API220090626,NTS
PHP Extension Build => API20090626,NTS
Debug Build => no
Thread Safety => disabled
Zend Memory Manager => enabled
Zend Multibyte Support => disabled
IPv6 Support => enabled
Registered PHP Streams => https, ftps, compress.zlib, compress.bzip2, php, file, glob, data, http, ftp, phar, zip
Registered Stream Socket Transports => tcp, udp, unix, udg, ssl, sslv3, sslv2, tls
Registered Stream Filters => zlib.*, bzip2.*, convert.iconv.*, string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, dechunk

This program makes use of the Zend Scripting Language Engine:
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies

_______________________________________________________________________

Configuration

bz2

BZip2 Support => Enabled
Stream Wrapper support => compress.bzip2://
Stream Filter support => bzip2.decompress, bzip2.compress
BZip2 Version => 1.0.3, 15-Feb-2005

calendar

Calendar support => enabled

Core

PHP Version => 5.3.15

Directive => Local Value => Master Value
allow_call_time_pass_reference => Off => Off
allow_url_fopen => On => On
allow_url_include => Off => Off
always_populate_raw_post_data => Off => Off
arg_separator.input => & => &
arg_separator.output => & => &
asp_tags => Off => Off
auto_append_file => no value => no value
auto_globals_jit => On => On
auto_prepend_file => no value => no value
browscap => no value => no value
default_charset => no value => no value
default_mimetype => text/html => text/html
define_syslog_variables => Off => Off
disable_classes => no value => no value
disable_functions => no value => no value
display_errors => Off => Off
display_startup_errors => Off => Off
doc_root => no value => no value
docref_ext => no value => no value
docref_root => no value => no value
enable_dl => Off => Off
error_append_string => no value => no value
error_log => no value => no value
error_prepend_string => no value => no value
error_reporting => 22527 => 22527
exit_on_timeout => Off => Off
expose_php => On => On
extension_dir => /usr/lib64/php/modules => /usr/lib64/php/modules
file_uploads => On => On
highlight.bg => #FFFFFF => #FFFFFF
highlight.comment => #FF8000 => #FF8000
highlight.default => #0000BB => #0000BB
highlight.html => #000000 => #000000
highlight.keyword => #007700 => #007700
highlight.string => #DD0000 => #DD0000
html_errors => Off => Off
ignore_repeated_errors => Off => Off
ignore_repeated_source => Off => Off
ignore_user_abort => Off => Off
implicit_flush => On => On
include_path => .:/usr/share/pear:/usr/share/php => .:/usr/share/pear:/usr/share/php
log_errors => On => On
log_errors_max_len => 1024 => 1024
magic_quotes_gpc => Off => Off
magic_quotes_runtime => Off => Off
magic_quotes_sybase => Off => Off
mail.add_x_header => On => On
mail.force_extra_parameters => no value => no value
mail.log => no value => no value
max_execution_time => 0 => 0
max_file_uploads => 20 => 20
max_input_nesting_level => 64 => 64
max_input_time => -1 => -1
max_input_vars => 1000 => 1000
memory_limit => 128M => 128M
open_basedir => no value => no value
output_buffering => 0 => 0
output_handler => no value => no value
post_max_size => 8M => 8M
precision => 14 => 14
realpath_cache_size => 16K => 16K
realpath_cache_ttl => 120 => 120
register_argc_argv => On => On
register_globals => Off => Off
register_long_arrays => Off => Off
report_memleaks => On => On
report_zend_debug => Off => Off
request_order => GP => GP
safe_mode => Off => Off
safe_mode_exec_dir => no value => no value
safe_mode_gid => Off => Off
safe_mode_include_dir => no value => no value
sendmail_from => no value => no value
sendmail_path => /usr/sbin/sendmail -t -i => /usr/sbin/sendmail -t -i
serialize_precision => 100 => 100
short_open_tag => Off => Off
SMTP => localhost => localhost
smtp_port => 25 => 25
sql.safe_mode => Off => Off
track_errors => Off => Off
unserialize_callback_func => no value => no value
upload_max_filesize => 2M => 2M
upload_tmp_dir => no value => no value
user_dir => no value => no value
user_ini.cache_ttl => 300 => 300
user_ini.filename => .user.ini => .user.ini
variables_order => GPCS => GPCS
xmlrpc_error_number => 0 => 0
xmlrpc_errors => Off => Off
y2k_compliance => On => On
zend.enable_gc => On => On

couchbase

couchbase support => enabled
version => 1.0.5
json support => yes
fastlz support => no
zlib support => yes

Directive => Local Value => Master Value
couchbase.compression_factor => 1.3 => 1.3
couchbase.compression_threshold => 2000 => 2000
couchbase.compressor => none => none
couchbase.serializer => php => php

ctype

ctype functions => enabled

curl

cURL support => enabled
cURL Information => 7.15.5
Age => 2
Features
AsynchDNS => No
Debug => No
GSS-Negotiate => Yes
IDN => Yes
IPv6 => Yes
Largefile => Yes
NTLM => Yes
SPNEGO => No
SSL => Yes
SSPI => No
krb4 => No
libz => Yes
CharConv => No
Protocols => tftp, ftp, telnet, dict, ldap, http, file, https, ftps
Host => x86_64-redhat-linux-gnu
SSL Version => OpenSSL/0.9.8b
ZLib Version => 1.2.3

date

date/time support => enabled
"Olson" Timezone Database Version => 0.system
Timezone Database => internal
PHP Warning: Unknown: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in Unknown on line 0
Default timezone => America/Los_Angeles

Directive => Local Value => Master Value
date.default_latitude => 31.7667 => 31.7667
date.default_longitude => 35.2333 => 35.2333
date.sunrise_zenith => 90.583333 => 90.583333
date.sunset_zenith => 90.583333 => 90.583333
date.timezone => no value => no value

ereg

Regex Library => Bundled library enabled

exif

EXIF Support => enabled
EXIF Version => 1.4 $Id$
Supported EXIF Version => 0220
Supported filetypes => JPEG,TIFF

Directive => Local Value => Master Value
exif.decode_jis_intel => JIS => JIS
exif.decode_jis_motorola => JIS => JIS
exif.decode_unicode_intel => UCS-2LE => UCS-2LE
exif.decode_unicode_motorola => UCS-2BE => UCS-2BE
exif.encode_jis => no value => no value
exif.encode_unicode => ISO-8859-15 => ISO-8859-15

fileinfo

fileinfo support => enabled
version => 1.0.5-dev

filter

Input Validation and Filtering => enabled
Revision => $Id: 2b8c730d7dfaa8485d07cd792f0c82852ffe4113 $

Directive => Local Value => Master Value
filter.default => unsafe_raw => unsafe_raw
filter.default_flags => no value => no value

ftp

FTP support => enabled

gettext

GetText Support => enabled

gmp

gmp support => enabled
GMP version => 4.1.4

hash

hash support => enabled
Hashing Engines => md2 md4 md5 sha1 sha224 sha256 sha384 sha512 ripemd128 ripemd160 ripemd256 ripemd320 whirlpool tiger128,3 tiger160,3 tiger192,3 tiger128,4 tiger160,4 tiger192,4 snefru snefru256 gost adler32 crc32 crc32b salsa10 salsa20 haval128,3 haval160,3 haval192,3 haval224,3 haval256,3 haval128,4 haval160,4 haval192,4 haval224,4 haval256,4 haval128,5 haval160,5 haval192,5 haval224,5 haval256,5

iconv

iconv support => enabled
iconv implementation => glibc
iconv library version => 2.5

Directive => Local Value => Master Value
iconv.input_encoding => ISO-8859-1 => ISO-8859-1
iconv.internal_encoding => ISO-8859-1 => ISO-8859-1
iconv.output_encoding => ISO-8859-1 => ISO-8859-1

igbinary

igbinary support => enabled
igbinary version => 1.1.1
igbinary APC serializer ABI => 0

Directive => Local Value => Master Value
igbinary.compact_strings => On => On

json

json support => enabled
json version => 1.2.1

libxml

libXML support => active
libXML Compiled Version => 2.6.26
libXML Loaded Version => 20626
libXML streams => enabled

memcached

memcached support => enabled
Version => 2.1.0
libmemcached version => 1.0.4
Session support => yes
igbinary support => yes
json support => yes

Directive => Local Value => Master Value
memcached.compression_factor => 1.3 => 1.3
memcached.compression_threshold => 2000 => 2000
memcached.compression_type => fastlz => fastlz
memcached.serializer => igbinary => igbinary
memcached.sess_binary => 0 => 0
memcached.sess_lock_wait => 150000 => 150000
memcached.sess_locking => 1 => 1
memcached.sess_prefix => memc.sess.key. => memc.sess.key.

mhash

MHASH support => Enabled
MHASH API Version => Emulated Support

openssl

OpenSSL support => enabled
OpenSSL Library Version => OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
OpenSSL Header Version => OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008

pcntl

pcntl support => enabled

pcre

PCRE (Perl Compatible Regular Expressions) Support => enabled
PCRE Library Version => 8.12 2011-01-15

Directive => Local Value => Master Value
pcre.backtrack_limit => 1000000 => 1000000
pcre.recursion_limit => 100000 => 100000

Phar

Phar: PHP Archive support => enabled
Phar EXT version => 2.0.1
Phar API version => 1.1.1
SVN revision => $Id: f7d08da4ab9e515975840c28b830edc9437c3026 $
Phar-based phar archives => enabled
Tar-based phar archives => enabled
ZIP-based phar archives => enabled
gzip compression => enabled
bzip2 compression => enabled
Native OpenSSL support => enabled

Phar based on pear/PHP_Archive, original concept by Davey Shafik.
Phar fully realized by Gregory Beaver and Marcus Boerger.
Portions of tar implementation Copyright (c) 2003-2009 Tim Kientzle.
Directive => Local Value => Master Value
phar.cache_list => no value => no value
phar.readonly => On => On
phar.require_hash => On => On

Reflection

Reflection => enabled
Version => $Id: e98652ba2326bd9391b730afdaf96c017d9fab48 $

session

Session Support => enabled
Registered save handlers => files user memcached
Registered serializer handlers => php php_binary igbinary

Directive => Local Value => Master Value
session.auto_start => Off => Off
session.bug_compat_42 => Off => Off
session.bug_compat_warn => Off => Off
session.cache_expire => 180 => 180
session.cache_limiter => nocache => nocache
session.cookie_domain => no value => no value
session.cookie_httponly => Off => Off
session.cookie_lifetime => 0 => 0
session.cookie_path => / => /
session.cookie_secure => Off => Off
session.entropy_file => no value => no value
session.entropy_length => 0 => 0
session.gc_divisor => 1000 => 1000
session.gc_maxlifetime => 1440 => 1440
session.gc_probability => 1 => 1
session.hash_bits_per_character => 5 => 5
session.hash_function => 0 => 0
session.name => PHPSESSID => PHPSESSID
session.referer_check => no value => no value
session.save_handler => files => files
session.save_path => /var/lib/php/session => /var/lib/php/session
session.serialize_handler => php => php
session.use_cookies => On => On
session.use_only_cookies => On => On
session.use_trans_sid => 0 => 0

shmop

shmop support => enabled

SimpleXML

Simplexml support => enabled
Revision => $Id: a379111021e24ef020a2eefd8ca830cb1ab5b280 $
Schema support => enabled

sockets

Sockets Support => enabled

SPL

SPL support => enabled
Interfaces => Countable, OuterIterator, RecursiveIterator, SeekableIterator, SplObserver, SplSubject
Classes => AppendIterator, ArrayIterator, ArrayObject, BadFunctionCallException, BadMethodCallException, CachingIterator, DirectoryIterator, DomainException, EmptyIterator, FilesystemIterator, FilterIterator, GlobIterator, InfiniteIterator, InvalidArgumentException, IteratorIterator, LengthException, LimitIterator, LogicException, MultipleIterator, NoRewindIterator, OutOfBoundsException, OutOfRangeException, OverflowException, ParentIterator, RangeException, RecursiveArrayIterator, RecursiveCachingIterator, RecursiveDirectoryIterator, RecursiveFilterIterator, RecursiveIteratorIterator, RecursiveRegexIterator, RecursiveTreeIterator, RegexIterator, RuntimeException, SplDoublyLinkedList, SplFileInfo, SplFileObject, SplFixedArray, SplHeap, SplMinHeap, SplMaxHeap, SplObjectStorage, SplPriorityQueue, SplQueue, SplStack, SplTempFileObject, UnderflowException, UnexpectedValueException

standard

Dynamic Library Support => enabled
Path to sendmail => /usr/sbin/sendmail -t -i

Directive => Local Value => Master Value
assert.active => 1 => 1
assert.bail => 0 => 0
assert.callback => no value => no value
assert.quiet_eval => 0 => 0
assert.warning => 1 => 1
auto_detect_line_endings => 0 => 0
default_socket_timeout => 60 => 60
from => no value => no value
safe_mode_allowed_env_vars => PHP_ => PHP_
safe_mode_protected_env_vars => LD_LIBRARY_PATH => LD_LIBRARY_PATH
url_rewriter.tags => a=href,area=href,frame=src,input=src,form=fakeentry => a=href,area=href,frame=src,input=src,form=fakeentry
user_agent => no value => no value

tokenizer

Tokenizer Support => enabled

xml

XML Support => active
XML Namespace Support => active
libxml2 Version => 2.6.26

zip

Zip => enabled
Extension Version => $Id$
Zip version => 1.11.0
Libzip version => 0.10.1

zlib

ZLib Support => enabled
Stream Wrapper support => compress.zlib://
Stream Filter support => zlib.inflate, zlib.deflate
Compiled Version => 1.2.3
Linked Version => 1.2.3

Directive => Local Value => Master Value
zlib.output_compression => Off => Off
zlib.output_compression_level => -1 => -1
zlib.output_handler => no value => no value

Additional Modules

Module Name
readline

Environment

Variable => Value
HOSTNAME => localhost.localdomain
TERM => xterm-256color
SHELL => /bin/bash
HISTSIZE => 1000
SSH_CLIENT => 10.32.16.37 62308 22
SSH_TTY => /dev/pts/1
USER => root
LS_COLORS =>
SSH_AUTH_SOCK => /tmp/ssh-RpQDiY3683/agent.3683
MAIL => /var/spool/mail/root
PATH => /usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
PWD => /usr/share/nginx/html
LANG => en_US.UTF-8
SSH_ASKPASS => /usr/libexec/openssh/gnome-ssh-askpass
SHLVL => 1
HOME => /root
LOGNAME => root
SSH_CONNECTION => 10.32.16.37 62308 10.4.2.14 22
LESSOPEN => |/usr/bin/lesspipe.sh %s
G_BROKEN_FILENAMES => 1
_ => /usr/bin/php
OLDPWD => /root/php-lib

PHP Variables

Variable => Value
_SERVER["HOSTNAME"] => localhost.localdomain
_SERVER["TERM"] => xterm-256color
_SERVER["SHELL"] => /bin/bash
_SERVER["HISTSIZE"] => 1000
_SERVER["SSH_CLIENT"] => 10.32.16.37 62308 22
_SERVER["SSH_TTY"] => /dev/pts/1
_SERVER["USER"] => root
_SERVER["LS_COLORS"] =>
_SERVER["SSH_AUTH_SOCK"] => /tmp/ssh-RpQDiY3683/agent.3683
_SERVER["MAIL"] => /var/spool/mail/root
_SERVER["PATH"] => /usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
_SERVER["PWD"] => /usr/share/nginx/html
_SERVER["LANG"] => en_US.UTF-8
_SERVER["SSH_ASKPASS"] => /usr/libexec/openssh/gnome-ssh-askpass
_SERVER["SHLVL"] => 1
_SERVER["HOME"] => /root
_SERVER["LOGNAME"] => root
_SERVER["SSH_CONNECTION"] => 10.32.16.37 62308 10.4.2.14 22
_SERVER["LESSOPEN"] => |/usr/bin/lesspipe.sh %s
_SERVER["G_BROKEN_FILENAMES"] => 1
_SERVER["_"] => /usr/bin/php
_SERVER["OLDPWD"] => /root/php-lib
_SERVER["PHP_SELF"] =>
_SERVER["SCRIPT_NAME"] =>
_SERVER["SCRIPT_FILENAME"] =>
_SERVER["PATH_TRANSLATED"] =>
_SERVER["DOCUMENT_ROOT"] =>
_SERVER["REQUEST_TIME"] => 1351803847
_SERVER["argv"] => Array
(
)

_SERVER["argc"] => 0

PHP License
This program is free software; you can redistribute it and/or modify
it under the terms of the PHP License as published by the PHP Group
and included in the distribution in the file: LICENSE

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

If you did not receive a copy of the PHP license, or have any
questions about PHP licensing, please contact license@php.net.

Comment by Tim Smith [ 02/Nov/12 ]

It doesn't work even when the extension is compiled to use fastlz compression.

I recompiled php-ext-couchbase from git with current libcouchbase code, and configured to include fastlz support. I set couchbase.compressor=fastlz in php.ini. And the couchbase.compression_threshold is at 2000, same as the memcached extension setting.

Excerpt of phpinfo() for the couchbase extension:

couchbase support enabled
version 1.1.0-dp5
json support yes
fastlz support yes
zlib support yes

Directive Local Value Master Value
couchbase.compression_factor 1.3 1.3
couchbase.compression_threshold 2000 2000
couchbase.compressor fastlz fastlz
couchbase.serializer php php

The same test case fails in the same way:

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 7598212603105511377 bytes) in /usr/share/nginx/html/cb.php on line 35

Comment by Tim Smith [ 02/Nov/12 ]

By the way, in order to compile with fastlz support, the following patch is needed:

diff --git a/couchbase.c b/couchbase.c
index 240ba3e..f4c14e5 100644
--- a/couchbase.c
+++ b/couchbase.c
@@ -41,6 +41,8 @@
#include <libcouchbase/couchbase.h>
#include "php_couchbase.h"
#ifdef HAVE_COMPRESSION_FASTLZ
+# include "fastlz.h"
+/* Any other code that uses fastlz_* should only include the header */
# include "fastlz.c"
#endif
#ifdef HAVE_COMPRESSION_ZLIB
diff --git a/views.c b/views.c
index 395cc2b..e818473 100644
--- a/views.c
+++ b/views.c
@@ -19,7 +19,7 @@
#include <libcouchbase/couchbase.h>
#include "php_couchbase.h"
#ifdef HAVE_COMPRESSION_FASTLZ
-# include "fastlz.c"
+# include "fastlz.h"
#endif
#ifdef HAVE_COMPRESSION_ZLIB
# include "zlib.h"

Otherwise linking couchbase.so fails because the fastlz functions are defined in more than one place.

Comment by Mark Nunberg [ 02/Nov/12 ]

Fixes for this are in progress.

http://review.couchbase.org/#/c/20604/ (in progress) fixes some of the crazy allocation attempts you've seen.

As for fastlz support, it shouldn't be too difficult to add it on.

Comment by Mark Nunberg [ 06/Nov/12 ]

A binary is attached. It's not compiled against the exact same version of php, but the zend api versions remain the same.

If the binary release doesn't work, I'd be happy to walk someone through building it from source (it's a very simple process -- much simpler than getting this binary built).

Comment by Mark Nunberg [ 06/Nov/12 ]

Note this is for the 1.1-dp php-ext branch. I've yet to backport this to the 1.0 branch

Comment by Matt Ingenthron [ 07/Nov/12 ]

Mark: Please determine if this issue is still valid and help me triage it into the appropriate release. I've assigned it to you for triage, not necessarily to fix it.

Comment by Mark Nunberg [ 07/Nov/12 ]

Awaiting approval on http://review.couchbase.com/22340

The is fixed in the code. Still needs backport to 1.0.x

Assigning back to you

Comment by Mark Nunberg [ 07/Nov/12 ]

http://review.couchbase.org/#/c/22340/ (1.1)

Comment by Matt Ingenthron [ 12/Nov/12 ]

Awaiting verification fix from customer.

Comment by Matt Ingenthron [ 14/Nov/12 ]

Trond: can you take care of backporting this to 1.0.x please?

Comment by Tim Smith [ 15/Nov/12 ]

More detail. I was personally unable to get the build of the latest PHP code to work with the beta2 release. I was hitting the error that is reported on http://www.couchbase.com/issues/browse/CCBC-126 :

Warning: Couchbase::__construct() [couchbase.--construct]: failed to create IO instance in /usr/share/nginx/html/cb.php on line 18

Building from sources let me get past that and actually test the build that the customer was trying. And following from that was a need to deal with LD_LIBRARY_PATH and symlink hacks.

A backport of the fastlz compression fix to 1.0.x, with an official release of that, would be best for this particular user's needs. Can we get an ETA on when that will be available?

Thanks,

Tim

Comment by Trond Norbye [ 16/Nov/12 ]

For 1.0.x: http://review.couchbase.org/#/c/22590/

Comment by Tim Smith [ 16/Nov/12 ]

I've confirmed it to work (using the current 1.0.x branch from github.com/couchbase/php-ext-couchbase).

I had to create a fake /usr/lib64/libvbucket.la to get it to compile: http://www.couchbase.com/issues/browse/CCBC-127

I noticed that compress.c has this redundant (unused) definition:

92 /* headers which claim an uncompressed size above this figure are bad */
93 #define DECOMP_SANITY_LIMIT 0x40000000

And this inaccurate comment:

172 /**
173 * sanity check, don't allocate over a GB, we should make this number
174 * smaller though
175 */

Obviously minor cleanup stuff, nothing significant that I can spot.

Would be great to get a 1.0.x package built and available for download with this (and other critical fixes, like ~~PCBC-75~~) available to customers. Is there an ETA on when that can be done?

Tim

Comment by Matt Ingenthron [ 16/Nov/12 ]

Packages are being uploaded to the site right now. Web page update to follow. Release notes will go up on Monday.

[PCBC-137] view querying needs to be more straightforward; e.g. character strings of decimal digits are serialised over the REST API as integers in view requests Created: 25/Oct/12 Updated: 11/Dec/12 Resolved: 23/Nov/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	None
Affects Version/s:	1.1.0-dp5
Fix Version/s:	1.1.0
Security Level:	Public

Type:

Bug

Priority:

Blocker

Reporter:

Michael Robinson

Assignee:

Matt Ingenthron

Resolution:

Fixed

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Description

Given this code:

$key = "1";
$result = $cb->view("design", "view", array("key"=>$key));

The PHP library will serialize this to a REST request as follows:

GET /bucket/_design/design/_view/view?key=1

This will be deserialized by couchbase as the integer value 1, not as the string value "1". Consequently, any key that is a string of decimal digits cannot be retrieved from a view with the PHP library.

This workaround can be used:

$key = "1";
$result = $cb->view("design", "view", array("key"=>'"'.$key.'"'));

The library will serialize this to a REST request as follows:

GET /bucket/_design/design/_view/view?key="1"

And couchbase will deserialize this as the string value "1".

Comments

Comment by Matt Ingenthron [ 25/Oct/12 ]

Mark: I saw you mention this earlier. Can you provide an assessment on this?

Comment by Mark Nunberg [ 25/Oct/12 ]

This is a more generalized bug or task of making php aware of the view parameters it passes.

Currently it only serializes the key-value pairs in the array as is. Having php know about where to place quotes would mean making the client aware abotu the variations in the view parameters, or in other words, implementing all of the view logic in the client library.

For now the user should be aware of this, and if something clearly mandates "quotes" then it should be quoted already when passed to the array.

While it's not the most elegant solution the fix to this is by far not surgical, and thus i recommend changing the name of this bug

Comment by Michael Robinson [ 25/Oct/12 ]

Would logic equivalent to this not solve the problem?

if (is_string($params["key"])) {
$paramString += 'key="'.$params["key"].'"';
}
else {
$paramString += 'key='.$params["key"];
}

Comment by Mark Nunberg [ 25/Oct/12 ]

No, because there are some parameters which do need actual integers.

Maybe the server can tolerate numeric parameters even fi they are enclosed in quotes, but I am not sure about that.

See

http://www.couchbase.com/docs/couchbase-manual-2.0/couchbase-views-querying-rest-api.html - and for example, group_level

Basically, the php client needs more logic to know the appropriate type for each parameter and perform the necessary coercion. i.e. numeric values for keys are not the same as numeric values for pagination

Comment by Michael Robinson [ 26/Oct/12 ]

Ok, it seems there are two problems at issue:

Problem 1: As a general case, type coercions across all parameters in the REST query string are not being handled as intelligently as they could be by the PHP library.

Problem 2: As a special case of problem 1, the PHP library will silently fail to retrieve records from a view if the key happens to be a string of decimal digits.

Without addressing the technical or architectural challenges of problem 1, it seems that, with respect to problem 2, as a general principle, silently failing to retrieve valid records for which a valid request was submitted is generally recognized as undesirable behavior for a database system.

This undesirable behavior could be rectified by the following (and as far as I can see, trivial) change to the serialization logic:

  If the parameter is in the set ("key", "startkey", "startkey_docid", "endkey", "endkey_docid"),
     and if the PHP type of the corresponding parameter value is "string",
       then serialize the parameter value in quotation marks in the REST query string,
     otherwise serialize the parameter value according to current implementation.

Yes?

Comment by Matt Ingenthron [ 26/Oct/12 ]

That does seem to make sense to me Michael. That's roughly what we evolved to on the other clients (Java && .NET), but there things are a bit different because of the types.

Comment by Matt Ingenthron [ 12/Nov/12 ]

Michael: can you take the lead on documenting a reasonable view query API. You have been through this once before, so I think you'd be the best person here. Simply document it here in this issue and then let's schedule a quick design review.

Comment by Michael Nitschinger [ 13/Nov/12 ]

Here is my proposal.

I've been thinking through and working around this while hacking on Basement (https://github.com/daschl/Basement) and also while extending the Java API. You may see similarities because of this (and you'll hopefully see why and how it makes sense).

At the lowest level, I think we should provide two ways of passing in queries in there.

1) A plain array as it is now. This way users can work around possible bugs and also have the flexibility if they know what they're doing. We should clearly state though that they are "on their own" when going down this route.

2) A CouchbaseViewQuery object (sorry, since we don't support namespaces in the extension). This works nearly similar to the Java-one, with the main difference that we need to care about working out the appropriate result type on our own (since you can pass in everything as a variable).

All further discussion (except noted) refers to the new object and how it should behave.

The construct should either take no params or an array to be initialized with. If it gets an array, it doesn't set the params directly but calls each setter for the given key to make sure that all rules are properly enforced.

Here is a simplified example. It assumes that all setter methods have the name as the param (like key() when setting/getting the key). If we want bean-style setters the method names need to be changed of course.

class CouchbaseViewQuery {

// holds the params to be exported
private $params = array();

// iterate over the given object an call setters.
public function __construct($params = array()) {
foreach($params as $key => $value) {
if($value !== null) {
$this->{$key}($value);
}
}
}

public function reduce($reduce = null) {
// getter/setter functionality in each method makes it condensed.
if($reduce == null) {
return $this->params['reduce'];
}

// do appropriate type checking for each param depending on whats
// supported.
if($reduce === 'true' || $reduce === true) {
$this->params['reduce'] = true;
}

// return object to let chain setters.
return $this;
}

}

Depending on how much we want to change the underlying interface, this query object can have either a toArray() or toString() export method that handles either only exporting it to an array, a string or also handle JSON serialization or encoding (don't know what of this parts is handled by libcouchbase itself).

Here is a possible usage example:

$query = new CouchbaseViewQuery();
$query->setReduce(true); // equally to $query->setReduce('true'); then
$cb->view('design', 'view', $query);

Also, all checks and conversions can then be handled transparently and securely by their appropriate setter methods. PHP also provides is_string() and so on to further determine what is passed into the variable.

Also, the export method is then in the position to do semantical checks like throw a warning/exception when reduce is false (or not set) and a group param is passed on. This could also be done in the setter but I'd like to see it done on exporting to reduce the coupling between setters.

The query handling object could look similar to this: https://github.com/daschl/Basement/blob/master/README.md#working-with-views (of course the method signature for view querying is differently, but the Query object would be nearly the same).

Let me know what you think guys,
Michael

Comment by Michael Nitschinger [ 13/Nov/12 ]

For design review.

[PCBC-135] Wrong parameter description for delete() Created: 08/Oct/12 Updated: 11/Dec/12 Resolved: 27/Nov/12
Status:	Closed
Project:	Couchbase PHP client library
Component/s:	docs
Affects Version/s:	1.0, 1.1.0-dp4
Fix Version/s:	1.0.5, 1.1.0
Security Level:	Public

Type:

Bug

Priority:

Minor

Reporter:

Dan Andersen

Assignee:

Karen Zeller

Resolution:

Fixed

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Description

The docs API for the delete method says: ( http://www.couchbase.com/docs/couchbase-sdk-php-1.1/api-reference-update.html#table-couchbase-sdk_php_delete )

$object->delete($key [, $expiry ])

But the expire should actually be cas, as in the source https://github.com/couchbase/php-ext-couchbase/blob/master/couchbase.c#L401

Comments

Comment by Matt Ingenthron [ 08/Oct/12 ]

Please update this in both the 1.0 and 1.1 SDK docs.

Comment by Karen Zeller [ 27/Nov/12 ]

Should be fixed with this change, I think:

<argument inherit="cas" optional="yes"/>

Comment by Karen Zeller [ 27/Nov/12 ]

should be the fix:

<argument inherit="cas" optional="yes"/>

[PCBC-134] Provide more information on connection failure Created: 08/Oct/12 Updated: 11/Feb/13 Resolved: 26/Oct/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	library
Affects Version/s:	1.0.5, 1.1.0-dp4
Fix Version/s:	1.0.6, 1.1.0
Security Level:	Public

Type:

Bug

Priority:

Major

Reporter:

Dan Andersen

Assignee:

Michael Jackson

Resolution:

Fixed

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Issue Links:

Duplicate
duplicates	~~PCBC-58~~	Couchbase.so - constructing Couchbase...	Resolved

Description

When you connect via the new Couchbase(...) is not a direct way to check for whether the connection failed.

It is not possible to check getResultCode()/getResultMessage() since this provides a unintilized couchbase

Comments

Comment by Mark Nunberg [ 08/Oct/12 ]

For this we'd probably need to change the ext code to return a valid couchbase object so that getResultCode can be called on it (to check for connection failures).

For the non-oo variant (couchbase_connect) behavior should remain the same (?)

Additionally, all the code which now checks for the couchbase object to simply exist should be changed to check that the couchbase object is indeed connected (I believe lcb has a function for that, but if not we can set our own little flag in our php_couchbase_ctx structure).

One workaround is to call set_error_handler and make it throw an ErrorException right before instantiation. Then the connection can be done in a try/catch block, with any message being found in $ex->getMessage().

I believe there may be ther workarounds as well

Comment by Michael Jackson [ 09/Oct/12 ]

patch set in progress: http://review.couchbase.org/#/c/21433/

Comment by Michael Jackson [ 09/Oct/12 ]

As a side note, I have a 1.0.x backport of the changes above ready to roll once the master branch changes are approved/merged.

Comment by Michael Jackson [ 10/Oct/12 ]

master branch changeset is merged in. 1.0.x changeset is here: http://review.couchbase.org/#/c/21487/

Comment by Michael Jackson [ 19/Oct/12 ]

(I believe all this needs for resolution is the 1.0.x changeset mentioned above to be merged into 1.0.x branch.)

Comment by Michael Jackson [ 26/Oct/12 ]

1.0.x merged in just now, 1.1 has been in for a bit. Should be present in next released versions.

[PCBC-132] Document testing procedures Created: 05/Oct/12 Updated: 11/Dec/12 Resolved: 12/Nov/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	library
Affects Version/s:	1.1.0-dp5
Fix Version/s:	1.1.0
Security Level:	Public

Type:

Task

Priority:

Major

Reporter:

Mark Nunberg

Assignee:

Mark Nunberg

Resolution:

Fixed

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Comments

Comment by Mark Nunberg [ 06/Nov/12 ]

http://review.couchbase.org/22320

[PCBC-119] Expose timeout setting Created: 26/Sep/12 Updated: 11/Dec/12 Resolved: 14/Nov/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	library
Affects Version/s:	None
Fix Version/s:	1.1.0
Security Level:	Public

Type:

New Feature

Priority:

Major

Reporter:

Mark Nunberg

Assignee:

Trond Norbye

Resolution:

Duplicate

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Description

libcouchbase has a timeout setting for connection responsiveness. This should be exposed in the php library.

The basic idea is that at libcouchbase initialization time, the PHP extension should set up the per-operation timeout to something the user specifies.

By the way, while in there, see if there are other tuneables that should be exposed.

Comments

Comment by Matt Ingenthron [ 10/Oct/12 ]

This should come toward the end of your scope, but hopefully we'll have time for it.

Comment by Trond Norbye [ 14/Nov/12 ]

THis is a duplicate of ~~PCBC-100~~

[PCBC-108] version() returns the library version, not server version Created: 02/Sep/12 Updated: 18/Sep/12 Resolved: 17/Sep/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	docs
Affects Version/s:	1.1.0-dp2
Fix Version/s:	1.0.6, 1.1.0-dp4, 1.1.0
Security Level:	Public

Type:

Bug

Priority:

Major

Reporter:

Mark Nunberg

Assignee:

Michael Jackson

Resolution:

Fixed

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Description

Documentation wrongly states that version returns the version of the server; this in fact returns the version of the library

Comments

Comment by Michael Jackson [ 14/Sep/12 ]

Fix in http://review.couchbase.org/#/c/20862/

Comment by Michael Jackson [ 14/Sep/12 ]

(Note: the above is for 1.0.x, a port to 1.1 is forthcoming.)

Comment by Michael Jackson [ 17/Sep/12 ]

1.1 branch fix in http://review.couchbase.org/#/c/20875/

Comment by Michael Jackson [ 17/Sep/12 ]

Change merged into 1.0.x and 1.1 branches.

[PCBC-104] PHP Client Need to Catch and Process "Object Too Large"errors from libcouchbase Created: 25/Aug/12 Updated: 04/Dec/12 Resolved: 03/Dec/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	None
Affects Version/s:	None
Fix Version/s:	1.1.0
Security Level:	Public

Type:

Bug

Priority:

Major

Reporter:

xing

Assignee:

Trond Norbye

Resolution:

Fixed

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Environment:

PHP client DP3

Description

Problem Summary:

When writing more than 1MB of data using php libcouch client, the client itself does not process the object too large error and the libcouchbase library logs a PHP warning as "PHP Warning: Couchbase::set(): Failed to store a value to server: Object too big in.....".

As result, it's impossible to write a strict warning free high performance php app using the current setup when we can't control what data is attempted to be cached.

1) We cannot catch this error before passing data in since more >1MB data might be compressible to less than <1MB so we have to rely on the PHP Client to do this for us.
2) We cannot catch this on the client site since it's not an exception but a PHP error/warning.
3) We can use set_error_handler() in php to catch this but it is extremely slow and negates the performance advantage of having libcouchbase in the first place.

Recommendation:

1) Return FALSE from PHP Client if post-compressed data is more than 1MB.

/* INSERT CODE test for payload_len size here before calling line below, if more, than return FALSE */

if (!(payload = php_couchbase_zval_to_payload(value, &payload_len, &flags, couchbase_res->serializer, couchbase_res->compressor TSRMLS_CC))) {
RETURN_FALSE;
}

Notes: pecl-memcached using libmemcached lib does not throw PHP warnings when object size is over limit. Error is logged internally and is up to the programmer to read the error post-fail to determine what happened.

Comments

Comment by xing [ 25/Aug/12 ]

1) Typos. The test code should happen after, not before, the zval_to_payload conversion which is when we know exactly is data is over limit.

2) Since libcouchbase supports I believe 10MB for disk based buckets, my report only deals with ram buckets. Perhaps there is a test somewhere for bucket type before size compare.

Comment by Michael Nitschinger [ 25/Aug/12 ]

Hi xing,

thanks for taking the time to open an issue!

Just to recap - you are using the following setup:

- PHP SDK 1.1-dp3
- Couchbase 2.0-dp4 (am I right?)

Are you using a couchbase bucket or a memcached bucket? The couchbase bucket is definitely capable of handling files larger than 1MB.

There is some restructuring going on regarding the warning/exception handling in the PHP SDK, but let's first sort out your particular issue here.

Thanks, Michael

Comment by Matt Ingenthron [ 07/Nov/12 ]

Trond: assigning to you to determine if still an issue and triage.

Comment by Trond Norbye [ 03/Dec/12 ]

This is no longer a problem. You can either catch the exception thrown by the object oriented interface, or you can call couchbase_get_result_code() and it'll contain e2big

Comment by Karen Zeller [ 04/Dec/12 ]

PHP Client now catches and processes 'object too larger' errors
Added to RN coming from underlying C library.

[PCBC-100] timeouts need to be tunable and consistent with other SDKs Created: 24/Aug/12 Updated: 26/Nov/12 Resolved: 26/Nov/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	None
Affects Version/s:	None
Fix Version/s:	1.1.0
Security Level:	Public

Type:

Improvement

Priority:

Blocker

Reporter:

Karen Zeller

Assignee:

Matt Ingenthron

Resolution:

Fixed

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Description

Provides the consistent level of time outs with other SDKs. Provide ability to set timeouts at: 1) connection, 2) authentication, and 3) ops level.

Comments

Comment by Trond Norbye [ 13/Nov/12 ]

http://review.couchbase.org/#/c/22474

Comment by Trond Norbye [ 13/Nov/12 ]

The php is built on top of libcouchbase which don't expose multiple timeouts. From an operational point of view one may also question why one would want a different set of timeouts. Most applications want to have a predictable latency for the various operations, and given the distributed nature of couchbase we never know when we're going to connect to a new host (or do an auth)..

Comment by Trond Norbye [ 13/Nov/12 ]

The timeout values are specified in usec (just like the C library)

Comment by Matt Ingenthron [ 15/Nov/12 ]

Sorry for reopening, but I have two points:

1) how does someone change the timeout in libcouchbase through PHP? This is about making it reconfigurable. Maybe it is, but I don't know that we have that documented and I've not seen it.
2) The HTTP timeout for views should be 75 sec, since they can take 10s of seconds to service. Regular memcached/CRUD requests should continue with the 2.5sec timeout. Is the PHP client doing this already?

Comment by Karen Zeller [ 15/Nov/12 ]

My understanding is that at the C library level, there is a single timeout of 2.5 seconds. That is what I documented for PHP and C at this point for all types of server interactions (connect, CRUD, etc.)

Comment by Trond Norbye [ 19/Nov/12 ]

For 1:

In the object oriented interface you can use:
$cb->getTimeout()
$cb->setTimeout(value);

in the non-oo you would use:
couchbase_get_timeout($cb);
couchbase_set_timeout($cb, value)

2) libcouchbase don't have separate timers... if we would like different default timeouts for views we would have to add support for that...

Comment by Matt Ingenthron [ 26/Nov/12 ]

The view timeout is tracked in ~~PCBC-150~~, so this is closeable. See that issue for view timeout related changes on PCBC.

[PCBC-99] Provide Error Handling Consistent with Other SDKs Created: 24/Aug/12 Updated: 11/Dec/12 Resolved: 11/Dec/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	None
Affects Version/s:	None
Fix Version/s:	1.1.0
Security Level:	Public

Type:

Improvement

Priority:

Minor

Reporter:

Karen Zeller

Assignee:

Matt Ingenthron

Resolution:

Fixed

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Description

Need to provides consistent error messages and error handling. Needs to be more consistent with other SDKS, and underlying memcached protocol

Comments

Comment by Matt Ingenthron [ 11/Dec/12 ]

Given this is much, much better, going to close this item. Need more specifics for future "consistent".

[PCBC-95] new() function docs is missing the $bucket parameter: Created: 10/Aug/12 Updated: 11/Dec/12 Resolved: 15/Nov/12
Status:	Closed
Project:	Couchbase PHP client library
Component/s:	docs
Affects Version/s:	None
Fix Version/s:	1.1.0
Security Level:	Public

Type:

Bug

Priority:

Critical

Reporter:

Tim Smith

Assignee:

Karen Zeller

Resolution:

Fixed

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Environment:

Couchbase lib 1.0.4

Issue Links:

Duplicate
is duplicated by	~~PCBC-94~~	new() function docs is missing the $b...	Resolved

Description

These docs are incorrect: http://www.couchbase.com/docs/couchbase-sdk-php-1.0/api-reference-summary.html

It says: "$object->new Couchbase($url, $username, $password [, $persistent ])"

It should say

Comments

Comment by Tim Smith [ 10/Aug/12 ]

Sorry, it got submitted accidentally. It should say:

$object->new Couchbase($url [ , $username, $password, $bucket, $persistent ])

That is, all the parameters are optional after $url. And the $bucket parameter is missing in the current docs.

Comment by Karen Zeller [ 15/Nov/12 ]

So I think this is the fix that should be applied to both 1.0 and 1.1:

 <derivative lang="php">

 <dcall call="new Couchbase" id="new_couchbase">

 <args>

 <argument inherit="url"/>

 <argument inherit="username" optional="yes"/>

 <argument inherit="password" optional="yes"/>

 <argument inherit="bucket" optional="yes"/>

 <argument inherit="persistent" optional="yes"/>

 </args>

 </dcall>

 </derivative>

So here is the added bucket option and the three parameters are now optional.

Comment by Karen Zeller [ 15/Nov/12 ]

I think this is the fix for both 1.0 and 1.1:

 <derivative lang="php">

 <dcall call="new Couchbase" id="new_couchbase">

 <args>

 <argument inherit="url"/>

 <argument inherit="username" optional="yes"/>

 <argument inherit="password" optional="yes"/>

 <argument inherit="bucket" optional="yes"/>

 <argument inherit="persistent" optional="yes"/>

 </args>

 </dcall>

 </derivative>

So here is the added bucket option and the three parameters are now optional.

[PCBC-92] Completely document constants and result codes. Created: 31/Jul/12 Updated: 06/Dec/12 Resolved: 03/Dec/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	docs, library
Affects Version/s:	None
Fix Version/s:	1.1.0
Security Level:	Public

Type:

Bug

Priority:

Critical

Reporter:

Tim Smith

Assignee:

MC Brown

Resolution:

Fixed

Votes:

Labels:

None

Remaining Estimate:

24h

Time Spent:

Not Specified

Original Estimate:

24h

Environment:

PHP 1.1 branch

Attachments:

CouchbasePHPAPIdocumentation.pdf

Description

There is no documentation in the PHP Couchbase Client for the constants used as options (e.g., COUCHBASE_OPT_COMPRESSOR, Couchbase::GET_PRESERVE_ORDER) and result codes (e.g., COUCHBASE_KEY_EEXISTS). This documentation is critical for usability of the library.

Also, it would be very nice to have IDE support for these things, via a PHP file that could require_once() into the app so the IDE will find these symbols, shipped as part of the package.

Comments

Comment by Mark Nunberg [ 06/Sep/12 ]

I might give a hack at this (I personally think this is very important..).. can someone show me an example of a PHP/C extension which does this?

Comment by Karen Zeller [ 06/Sep/12 ]

Not that I am aware of (at the source/comment, wiki, or email-level of info.) Let me know if you find out.

Comment by Matt Ingenthron [ 07/Nov/12 ]

Trond: assigning to you to determine if still an issue and triage.

Comment by Trond Norbye [ 08/Nov/12 ]

Pierre pointed me to an example at line 1552 in http://svn.php.net/viewvc/pecl/zip/trunk/php_zip.c?revision=326243&view=markup

Comment by Tim Smith [ 14/Nov/12 ]

The most important part of this bug report is getting something in our documentation that spells out all the configuration options that exist in our Couchbase client, what range of values they accept, what they mean, etc.

To the extent that all our clients have analogous settings, these can be put into a common section in the developers' guide docs.

To the extent that they're specific to a particular SDK (PHP, in this case), they should be in that SDK's docs.

For example, the getOption and setOption methods are mentioned here, but no info or link to what values to specify:

http://www.couchbase.com/docs/couchbase-sdk-php-1.0/api-reference-connection.html

A secondary and nice-to-have bit is the IDE integration. The original user requested a single source file that lists the symbols that could be required into the PHP code, so the IDE would be able to find all those symbols and do autocompletion. Perhaps Trond has tracked down a solid way to do this.

Tim

Comment by Matt Ingenthron [ 26/Nov/12 ]

Trond and I discussed this one just now.

Action required here is to decide what needs to be done. If there are undocumented options in the creating a connection reference, then we should file bugs appropriately (to Karen, who is helping with PHP docs at the moment). Other than that, Trond will research the best way to expose the constants and result codes.

Tim: if there are other specific doc issues you spot, please file them appropriately so they don't get lost. This project does have a documentation component.

Comment by Trond Norbye [ 28/Nov/12 ]

I talked to dsop and pierre on IRC and they told me that php stopped generating the documentation off the php sources, and use docbook instead. there are some tools that use reflection on the module to generate a skeleton. I think it is beyond the scope of a bug report to implement a full doocbook documentation for our plugin (that should be treated as a new task), so I'll just write up a small API documentation describing all of our methods with the parameter list and the return value (and all tunables) and hand that off to Karen?

Comment by Tim Smith [ 28/Nov/12 ]

Trond,

Yes, the *values* that those parameters can take, and what they mean, are the most opaque parts of the API right now. If you can do a quick write-up and give to Karen, that's perfect.

The other request was to just have some dummy php file that can be included in a source project that won't do anything useful but will define every symbol, to enable an IDE to auto-complete stuff. It's a minor thing compared to getting the docs to Karen, so I'd say just ignore that request and focus on getting info to the docs team.

Thanks!

Tim

Comment by Trond Norbye [ 03/Dec/12 ]

Tim: is this what you need?

Comment by Trond Norbye [ 03/Dec/12 ]

I guess there isn't much more I can do on this issue now?

Comment by Matt Ingenthron [ 03/Dec/12 ]

I think MC is actually taking this on. Assigning it his way.

Comment by MC Brown [ 03/Dec/12 ]

I've added the option and result codes to the PHP material:

http://www.couchbase.com/docs/couchbase-sdk-php-1.1/api-reference-summary-options.html
http://www.couchbase.com/docs/couchbase-sdk-php-1.1/api-reference-summary-errors.html

Comment by Matt Ingenthron [ 03/Dec/12 ]

Apologies MC, a bit more has happened here. I'll leave it to you, but I think this needs to be reopened with a changed description, or another issue opened.

In addressing this issue, Trond went beyond the constants and documented the whole API. I think the attached PDF is more of a base for the API reference. For example, the new class CouchbaseClusterManager is covered.

Should we open a new issue related to the API reference?

Comment by MC Brown [ 03/Dec/12 ]

No, it's fine.

I've been using the material Trond has written to mark up this, but we already have another (http://www.couchbase.com/issues/browse/PCBC-105) which covers the wider API.

I just wanted to close this one based on the core of the request; I'll continue to fill out the rest using the material from Trond this week.

Comment by Matt Ingenthron [ 06/Dec/12 ]

Updated the summary to reflect what was actually done.

Note that in the process of fixing this, the previous method of documenting functions (which some IDEs have support for) is no longer supported by the PHP project. All API will be documented at couchbase.com/docs in the API reference for PHP.

We're open to other directions on how to work well with IDEs. I'm just repeating what we've heard from PHP core contributors.

[PCBC-89] Update the getting started to match the Beer sample DB Created: 12/Jul/12 Updated: 11/Dec/12 Resolved: 11/Dec/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	None
Affects Version/s:	None
Fix Version/s:	1.1.0
Security Level:	Public

Type:

Improvement

Priority:

Major

Reporter:

Matt Ingenthron

Assignee:

Karen Zeller

Resolution:

Fixed

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Description

Once the sample DB has been integrated into the server, update the getting started (both on the web page and in the documentation) to use the sample database.

Comments

Comment by Matt Ingenthron [ 06/Dec/12 ]

Assigning this back to Karen.

Just talked with Trond and he'd mistakenly assigned it to himself as he'd had it confused with the tutorial. Just for clarification, Karen's working on the 'getting started guide' and Trond is working on the 'tutorial'.

Comment by Matt Ingenthron [ 11/Dec/12 ]

Reviewed and done!

[PCBC-88] Add a unit/integration test validation of OBSERVE + view stale=false Created: 12/Jul/12 Updated: 11/Dec/12 Resolved: 12/Nov/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	None
Affects Version/s:	None
Fix Version/s:	1.1.0
Security Level:	Public

Type:

Improvement

Priority:

Major

Reporter:

Matt Ingenthron

Assignee:

Trond Norbye

Resolution:

Fixed

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Description

Ensure that when a synchronous set is used with the new low-level observe, the index is fully updated when querying with view=false.

Comments

Comment by Mark Nunberg [ 12/Nov/12 ]

Effectively done in ViewSimple.inc

[PCBC-87] View error options at query time Created: 12/Jul/12 Updated: 11/Dec/12 Resolved: 23/Nov/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	None
Affects Version/s:	None
Fix Version/s:	1.1.0
Security Level:	Public

Type:

Improvement

Priority:

Major

Reporter:

Matt Ingenthron

Assignee:

Trond Norbye

Resolution:

Fixed

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Description

At view query time, we need to ensure the developer has the ability to add an "on_error" parameter with values of either "stop" or "continue".

Comments

Comment by Mark Nunberg [ 11/Sep/12 ]

There is a suggested API for this in ~~PCBC-110~~ (in the php attachment)

[PCBC-86] Bucket management Created: 12/Jul/12 Updated: 11/Dec/12 Resolved: 03/Dec/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	None
Affects Version/s:	None
Fix Version/s:	1.1.0
Security Level:	Public

Type:

Improvement

Priority:

Major

Reporter:

Matt Ingenthron

Assignee:

Trond Norbye

Resolution:

Fixed

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Description

Add the necessary features to create and remove buckets. Also, add the ability to call the RESTful bucket flush.

Comments

Comment by Trond Norbye [ 08/Nov/12 ]

http://review.couchbase.org/#/c/22014/

[PCBC-83] Highlevel synchronous mutation operations atop observe Created: 12/Jul/12 Updated: 11/Dec/12 Resolved: 03/Dec/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	None
Affects Version/s:	None
Fix Version/s:	1.1.0
Security Level:	Public

Type:

Improvement

Priority:

Blocker

Reporter:

Matt Ingenthron

Assignee:

Trond Norbye

Resolution:

Fixed

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Description

After ~~PCBC-81~~ is implemented, the idea here is to implement synchronous mutation and deletion operations. They would, for example take the key/cas returned from the set and then poll in a loop until the desired state in the observe is reached.

There are additional examples here:
http://www.couchbase.com/wiki/display/couchbase/Observe

Comments

Comment by Michael Jackson [ 19/Oct/12 ]

WIP under review http://review.couchbase.org/#/c/21677 (this changeset includes both 82 and 83 changes are they are closely related)

Comment by Trond Norbye [ 26/Nov/12 ]

http://review.couchbase.org/#/c/22712

[PCBC-79] Tarball releases for PHP clients Created: 28/Jun/12 Updated: 13/Nov/12 Resolved: 13/Nov/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	None
Affects Version/s:	None
Fix Version/s:	1.1.0
Security Level:	Public

Type:

Bug

Priority:

Critical

Reporter:

Sergey Avseyev

Assignee:

Matt Ingenthron

Resolution:

Fixed

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Description

It would be nice to have released tarballs to point for people having troubles with binary builds

Comments

Comment by Matt Ingenthron [ 07/Nov/12 ]

Trond: assigning to you to determine if still an issue and triage.

Comment by Trond Norbye [ 08/Nov/12 ]

This is a manual step we need to do as part of the release process (to upload the tarball).. Unfortunately we don't have a gmake dist target here, so it would just be to gtar cfz up the directory (without the .git* stuff)...

Comment by Trond Norbye [ 08/Nov/12 ]

I guess the bug should be assigned to our RE team?

Comment by Matt Ingenthron [ 12/Nov/12 ]

We don't have a RE team, so we're it for now.

Comment by Sergey Avseyev [ 13/Nov/12 ]

http://sdkbuilds.couchbase.com/job/sdk-repo/

artifacts are building by this job

[PCBC-73] get() method signature less optimal than it could be Created: 13/Jun/12 Updated: 05/Dec/12 Resolved: 05/Dec/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	library
Affects Version/s:	1.0.3
Fix Version/s:	1.1.0
Security Level:	Public

Type:

Improvement

Priority:

Minor

Reporter:

Benjamin Young

Assignee:

Trond Norbye

Resolution:

Fixed

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Flagged:

Release Note

Description

It'd be great to move the $cas_token parameter to the second place as $cas_token is more likely to be used with get() than $callback. At least it would seem that way given the existence of two callback-focused/requiring functions: getDelayed and getDelayedByKey.

Due to this already being in use, it may need some type detection so that the two parameters technically become interchangeable within the signature, but we throw a deprecation warning (starting with 1.1) that states that $cas_token should come second going forward.

Additionally in 1.0.3, the callback for get() does not seem to be called--erroneous variable name output doesn't throw any errors, and basic echo's don't ever "surface" into the buffer.

Thanks.

Comments

Comment by Matt Ingenthron [ 07/Nov/12 ]

Trond: assigning to you to determine if still an issue and triage.

[PCBC-72] getDelayed seems to return a Boolean not a "string (Binary object)" as the docs state Created: 13/Jun/12 Updated: 11/Dec/12 Resolved: 27/Nov/12
Status:	Closed
Project:	Couchbase PHP client library
Component/s:	docs, library
Affects Version/s:	1.0.3
Fix Version/s:	1.0.5, 1.1.0
Security Level:	Public

Type:

Bug

Priority:

Critical

Reporter:

Benjamin Young

Assignee:

Karen Zeller

Resolution:

Fixed

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Description

I'm not sure if this is a doc error or a code error, but the documentation for getDelayed [1] states it returns a "string (Binary object)" when in fact it returns a Boolean.

The return of a Boolean is likely the intended response as getDelayed implies the use of a callback.

I've marked this issue as being related to both docs & library, though, in case I've missed something.

[1] http://www.couchbase.com/docs/couchbase-sdk-php-1.0/api-reference-retrieve.html#table-couchbase-sdk_php_get-delayed

Comments

Comment by Matt Ingenthron [ 07/Nov/12 ]

Mark: Please determine if this issue is still valid and help me triage it into the appropriate release. I've assigned it to you for triage, not necessarily to fix it.

Comment by Matt Ingenthron [ 12/Nov/12 ]

Trond: Since this may be just a matter of getting correct documentation, I've bumped the priority so we try to triage it and decide where it belongs. Please allocate just a few minutes to it when you can.

If it's a documentation fix that's needed, let's pass it along to Karen.

If you're unsure what was originally intended, it may make sense to look at pecl-memcached.

Comment by Trond Norbye [ 27/Nov/12 ]

According to the code (and the documentation for pecl::memcached:getDelayed) it should return a boolean value.

Comment by Karen Zeller [ 27/Nov/12 ]

I think this fixes it:

 <dcall id="get-delayed" call="getDelayed" inherit="none">

 <m_title>
 Get a key to be fetched later
 </m_title>

 <args>

 <argument inherit="keyn"/>

 <argument inherit="with_cas" optional="yes"/>

 <argument inherit="callback" optional="yes"/>

 </args>
 <return inherit="boolean"/>
 </dcall>

Comment by Karen Zeller [ 27/Nov/12 ]

<dcall id="get-delayed" call="getDelayed" inherit="none">

 <m_title>
 Get a key to be fetched later
 </m_title>

 <args>

 <argument inherit="keyn"/>

 <argument inherit="with_cas" optional="yes"/>

 <argument inherit="callback" optional="yes"/>

 </args>
 <return inherit="boolean"/>
 </dcall>

[PCBC-57] support errors on views Created: 22/Mar/12 Updated: 11/Dec/12 Resolved: 23/Nov/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	None
Affects Version/s:	None
Fix Version/s:	1.1.0
Security Level:	Public

Type:

New Feature

Priority:

Major

Reporter:

Matt Ingenthron

Assignee:

Mark Nunberg

Resolution:

Fixed

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Description

Views now have some options on capturing errors and stopping on errors as documented here:
http://www.couchbase.com/docs/couchbase-manual-2.0/couchbase-views-writing-errors.html

The client needs to support these.

Comments

Comment by Matt Ingenthron [ 07/Nov/12 ]

Mark: Please determine if this issue is still valid and help me triage it into the appropriate release. I've assigned it to you for triage, not necessarily to fix it.

Comment by Mark Nunberg [ 20/Nov/12 ]

We sort of have support for this. Not sure what the correct behavior should be for various view errors .. (and there is one test failing because of this...)

Comment by Mark Nunberg [ 20/Nov/12 ]

Assign to someone who can figure out what we should do here :)

Basically, we don't know if we should raise an exception (technically requesting a non-existent view is a Bad Thing, almost like a malformed SQL query, but not quite), or just return it within the JSON..

Comment by Matt Ingenthron [ 21/Nov/12 ]

Well, the question is whether or not we can specify the on_error. If we can, then this is closeable.

Comment by Mark Nunberg [ 23/Nov/12 ]

Fixed in commit cb41beb0e20be348436e5171b3bb2ba730c3063c
Author: Mark Nunberg <mnunberg@haskalah.org>
Date: Sat Nov 17 09:45:17 2012 -0800

~~PCBC-87~~, ~~PCBC-13~~, ~~PCBC-137~~, ~~PCBC-57~~ - View Option Handling

[PCBC-52] add support for unlock command Created: 11/Mar/12 Updated: 04/Dec/12 Resolved: 04/Dec/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	library
Affects Version/s:	None
Fix Version/s:	1.1.0
Security Level:	Public

Type:

New Feature

Priority:

Major

Reporter:

Matt Ingenthron

Assignee:

Trond Norbye

Resolution:

Fixed

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Description

Couchbase server has a keyed unlock command, which goes along with the getl command. The PHP client needs to add support for this command. Support is being added to libcouchbase.

Comments

Comment by Sergey Avseyev [ 08/Jun/12 ]

Unlock command already available in libcouchbase https://github.com/couchbase/libcouchbase/blob/1.1.0dp5/include/libcouchbase/couchbase.h#L305-L346

Comment by Trond Norbye [ 04/Dec/12 ]

http://review.couchbase.org/23028

[PCBC-51] Thoroughly unit-test API arguments Created: 05/Mar/12 Updated: 08/Oct/12 Resolved: 08/Oct/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	None
Affects Version/s:	1.0
Fix Version/s:	1.1.0
Security Level:	Public

Type:

Task

Priority:

Major

Reporter:

Jan Lehnardt

Assignee:

Michael Jackson

Resolution:

Fixed

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Description

Make sure the procedural and OO interfaces work as advertise to avoid the ::increment() issue where a procedural resource was still expected.

Comments

Comment by Michael Jackson [ 26/Sep/12 ]

Mark has a changeset that will serve as a good foundation for this (http://review.couchbase.org/#/c/21119/ [edit: fixed link]) I think; my plan is to begin extending from that base once it is merged in.

Comment by Michael Jackson [ 03/Oct/12 ]

http://review.couchbase.org/#/c/21320/ contains the changes to extend and relocate the new tests (they are now the default tests, as the old tests have been completely replaced)

Comment by Michael Jackson [ 08/Oct/12 ]

Merged to master. Seems like for now we're not going to backport this to 1.0.x.

[PCBC-47] Allow to make non-persistent connections in new-style constructor Created: 01/Mar/12 Updated: 07/Nov/12 Resolved: 07/Nov/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	None
Affects Version/s:	1.1.0
Fix Version/s:	1.1.0
Security Level:	Public

Type:

New Feature

Priority:

Major

Reporter:

Jan Lehnardt

Assignee:

Mark Nunberg

Resolution:

Cannot Reproduce

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Description

with new Couchbase("http://server:port/bucket") you have no way of specifying that you don't want a persistent connection. You can do so with new Couchbase($server, $user, $pass, $bucket, $persistent), but it'd be nice to allow new Couchbase($url[, persistent = true]);

Comments

Comment by Xinchen Hui [ 18/Jun/12 ]

yes, it should. sorry for missed that.

I will work on it soon..

thanks :)

Comment by Matt Ingenthron [ 07/Nov/12 ]

Mark: Please determine if this issue is still valid and help me triage it into the appropriate release. I've assigned it to you for triage, not necessarily to fix it.

Comment by Mark Nunberg [ 07/Nov/12 ]

This is either fixed or not reproducible. Connections are non-persistent by default unless otherwise specified.

[PCBC-35] Add automated cluster tests Created: 03/Feb/12 Updated: 12/Nov/12 Resolved: 12/Nov/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	None
Affects Version/s:	None
Fix Version/s:	1.0.5, 1.1.0
Security Level:	Public

Type:

Improvement

Priority:

Major

Reporter:

Jan Lehnardt

Assignee:

Mark Nunberg

Resolution:

Fixed

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Comments

Comment by Matt Ingenthron [ 07/Nov/12 ]

I believe this is closeable with the new testing framework you've built, correct? If you agree, please close. Let's look more at the roadmap on this one sometime soon.

Comment by Mark Nunberg [ 12/Nov/12 ]

Yes. We might want to make automated tests (i.e. 'make test'), but there's not much which is php-specific.. I'm imagining trond's build server is sufficient as far as these things go..

[PCBC-22] running integration tests under CI Created: 12/Jan/12 Updated: 07/Nov/12 Resolved: 07/Nov/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	None
Affects Version/s:	None
Fix Version/s:	1.1.0
Security Level:	Public

Type:

Task

Priority:

Minor

Reporter:

Matt Ingenthron

Assignee:

Matt Ingenthron

Resolution:

Won't Fix

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Comments

Comment by Matt Ingenthron [ 07/Nov/12 ]

we've changed strategy on this.

[PCBC-19] generating shippable artifacts Created: 12/Jan/12 Updated: 11/Dec/12 Resolved: 11/Dec/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	library
Affects Version/s:	None
Fix Version/s:	1.1.0
Security Level:	Public

Type:

Task

Priority:

Minor

Reporter:

Matt Ingenthron

Assignee:

Matt Ingenthron

Resolution:

Fixed

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Comments

Comment by Matt Ingenthron [ 11/Sep/12 ]

This is mostly fixed through sdkbuilds jira, but there is one outstanding issue. The generation of the build needs to install official packages or trigger the appropriate libcouchbase build first.

Assigning to Sergey as low priority.

Comment by Sergey Avseyev [ 11/Sep/12 ]

Assigning to mordy__ because he knows how to cook pecl extensions

Comment by Matt Ingenthron [ 12/Nov/12 ]

Assigning back to Sergey (sorry) :). I know how to cook PHP extensions which is all that's needed here. Need to integrate this with our build environment, where Sergey is the benevolent dictator (as assigned by me).

Comment by Sergey Avseyev [ 14/Nov/12 ]

http://sdkbuilds.couchbase.com/job/sdk-repo/

this job is making tarballs with binary PHP extension

Comment by Matt Ingenthron [ 11/Dec/12 ]

Done for now, but needs a bit of release management review.

[PCBC-13] Warn for illogic view parameters Created: 27/Oct/11 Updated: 15/Dec/12 Resolved: 23/Nov/12
Status:	Resolved
Project:	Couchbase PHP client library
Component/s:	None
Affects Version/s:	1.0
Fix Version/s:	1.1.0
Security Level:	Public

Type:

New Feature

Priority:

Minor

Reporter:

Jan Lehnardt

Assignee:

Trond Norbye

Resolution:

Fixed

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Description

Some combinations of view parameters do not make sense e.g. group=true and group_level=N, the SDK should warn if an illogic combination is specified.

Comments

Comment by Matt Ingenthron [ 07/Nov/12 ]

Trond: assigning to you to determine if still an issue and triage.

[PCBC-10] Enable SASL Created: 13/Oct/11 Updated: 01/Mar/12 Resolved: 01/Mar/12
Status:	Closed
Project:	Couchbase PHP client library
Component/s:	None
Affects Version/s:	None
Fix Version/s:	1.1.0
Security Level:	Public

Type:

Improvement

Priority:

Major

Reporter:

Jan Lehnardt

Assignee:

Jan Lehnardt

Resolution:

Won't Fix

Votes:

Labels:

None

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified

Description

we currently explicitly build without SASL bindings. We should look into enabling them, at least optionally.

Comments

Comment by Matt Ingenthron [ 27/Oct/11 ]

Primary approach for right now is to use client side moxi configured for SASL.

Comment by Jan Lehnardt [ 01/Mar/12 ]

with ext/couchbase we are already there.

Generated at Wed May 22 04:59:46 CDT 2013 using JIRA 5.2.4#845-sha1:c9f4cc41abe72fb236945343a1f485c2c844dac9.

[PCBC-159] incorrect timeout exceptions during required-durability function tests Created: 05/Dec/12 Updated: 11/Dec/12 Resolved: 05/Dec/12

[PCBC-158] assertion in removeOnePersist.phpt at Sync.inc:222 Created: 05/Dec/12 Updated: 11/Dec/12 Resolved: 05/Dec/12

[PCBC-153] move flush function to RESTful flush Created: 30/Nov/12 Updated: 11/Dec/12 Resolved: 04/Dec/12

[PCBC-150] make default view timeout 75s Created: 21/Nov/12 Updated: 11/Dec/12 Resolved: 11/Dec/12

[PCBC-149] persist_to should imply master when greater than zero Created: 19/Nov/12 Updated: 11/Dec/12 Resolved: 23/Nov/12

[PCBC-148] Key persistence checks wrong criterion Created: 19/Nov/12 Updated: 11/Dec/12 Resolved: 23/Nov/12

[PCBC-147] Segmentation Fault (segfault) when querying view Created: 15/Nov/12 Updated: 19/Nov/12 Resolved: 19/Nov/12

[PCBC-144] getVersion() returns memcached version, not couchbase version Created: 10/Nov/12 Updated: 11/Dec/12 Resolved: 06/Dec/12

[PCBC-143] segfault during lcb handle-level error handler Created: 09/Nov/12 Updated: 11/Dec/12 Resolved: 15/Nov/12

[PCBC-142] Plug leaks reported by debug-mode php/zts Created: 09/Nov/12 Updated: 11/Dec/12 Resolved: 12/Nov/12

[PCBC-141] 1.1 dp releases not working on phps which do not export the symbol php_json_encode Created: 07/Nov/12 Updated: 10/May/13 Resolved: 10/May/13

[PCBC-139] PHP client needs fastlz compression to be compatible with legacy memcached clients Created: 01/Nov/12 Updated: 11/Dec/12 Resolved: 16/Nov/12

[PCBC-137] view querying needs to be more straightforward; e.g. character strings of decimal digits are serialised over the REST API as integers in view requests Created: 25/Oct/12 Updated: 11/Dec/12 Resolved: 23/Nov/12

[PCBC-135] Wrong parameter description for delete() Created: 08/Oct/12 Updated: 11/Dec/12 Resolved: 27/Nov/12

[PCBC-134] Provide more information on connection failure Created: 08/Oct/12 Updated: 11/Feb/13 Resolved: 26/Oct/12

[PCBC-132] Document testing procedures Created: 05/Oct/12 Updated: 11/Dec/12 Resolved: 12/Nov/12

[PCBC-119] Expose timeout setting Created: 26/Sep/12 Updated: 11/Dec/12 Resolved: 14/Nov/12

[PCBC-108] version() returns the library version, not server version Created: 02/Sep/12 Updated: 18/Sep/12 Resolved: 17/Sep/12

[PCBC-104] PHP Client Need to Catch and Process "Object Too Large"errors from libcouchbase Created: 25/Aug/12 Updated: 04/Dec/12 Resolved: 03/Dec/12

[PCBC-100] timeouts need to be tunable and consistent with other SDKs Created: 24/Aug/12 Updated: 26/Nov/12 Resolved: 26/Nov/12

[PCBC-99] Provide Error Handling Consistent with Other SDKs Created: 24/Aug/12 Updated: 11/Dec/12 Resolved: 11/Dec/12

[PCBC-95] new() function docs is missing the $bucket parameter: Created: 10/Aug/12 Updated: 11/Dec/12 Resolved: 15/Nov/12

[PCBC-92] Completely document constants and result codes. Created: 31/Jul/12 Updated: 06/Dec/12 Resolved: 03/Dec/12

[PCBC-89] Update the getting started to match the Beer sample DB Created: 12/Jul/12 Updated: 11/Dec/12 Resolved: 11/Dec/12

[PCBC-88] Add a unit/integration test validation of OBSERVE + view stale=false Created: 12/Jul/12 Updated: 11/Dec/12 Resolved: 12/Nov/12

[PCBC-87] View error options at query time Created: 12/Jul/12 Updated: 11/Dec/12 Resolved: 23/Nov/12

[PCBC-86] Bucket management Created: 12/Jul/12 Updated: 11/Dec/12 Resolved: 03/Dec/12

[PCBC-83] Highlevel synchronous mutation operations atop observe Created: 12/Jul/12 Updated: 11/Dec/12 Resolved: 03/Dec/12

[PCBC-79] Tarball releases for PHP clients Created: 28/Jun/12 Updated: 13/Nov/12 Resolved: 13/Nov/12

[PCBC-73] get() method signature less optimal than it could be Created: 13/Jun/12 Updated: 05/Dec/12 Resolved: 05/Dec/12

[PCBC-72] getDelayed seems to return a Boolean not a "string (Binary object)" as the docs state Created: 13/Jun/12 Updated: 11/Dec/12 Resolved: 27/Nov/12

[PCBC-57] support errors on views Created: 22/Mar/12 Updated: 11/Dec/12 Resolved: 23/Nov/12

[PCBC-52] add support for unlock command Created: 11/Mar/12 Updated: 04/Dec/12 Resolved: 04/Dec/12

[PCBC-51] Thoroughly unit-test API arguments Created: 05/Mar/12 Updated: 08/Oct/12 Resolved: 08/Oct/12

[PCBC-47] Allow to make non-persistent connections in new-style constructor Created: 01/Mar/12 Updated: 07/Nov/12 Resolved: 07/Nov/12

[PCBC-35] Add automated cluster tests Created: 03/Feb/12 Updated: 12/Nov/12 Resolved: 12/Nov/12

[PCBC-22] running integration tests under CI Created: 12/Jan/12 Updated: 07/Nov/12 Resolved: 07/Nov/12

[PCBC-19] generating shippable artifacts Created: 12/Jan/12 Updated: 11/Dec/12 Resolved: 11/Dec/12

[PCBC-13] Warn for illogic view parameters Created: 27/Oct/11 Updated: 15/Dec/12 Resolved: 23/Nov/12

[PCBC-10] Enable SASL Created: 13/Oct/11 Updated: 01/Mar/12 Resolved: 01/Mar/12