Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Won't Fix
    • Affects Version/s: 1.0.2
    • Fix Version/s: None
    • Component/s: library
    • Security Level: Public
    • Labels:
      None

      Description

      So I've been able to put together a good test case...

      Here's what I did:
      1. switch back to SDK 1.0.3
      2. set a serialized array with 1.0.3
      3. switch back to SDK 1.0.5
      4. try to retrieve the serialized object with 1.0.5.
      5. notice the described behavior above.

      Here's a full break down:

          • REPLACE 1.0.5 with 1.0.3 and restart Apache ***

      MICHAEL'S MACBOOK PRO /usr/lib/php/extensions/no-debug-non-zts-20090626: ll
      total 2632
      drwxr-xr-x 13 root wheel 442 Sep 19 17:05 .
      drwxr-xr-x 4 root wheel 136 Jun 20 17:08 ..
      rw-rr- 1 mssteuer wheel 173216 Mar 12 2012 apc.so
      -rwxr-xr-x@ 1 mssteuer wheel 73520 Sep 19 17:06 couchbase.so
      -rwxr-xr-x 1 mssteuer wheel 62812 Apr 11 12:14 couchbase.so.101
      -rwxr-xr-x 1 mssteuer wheel 62836 Jul 2 15:43 couchbase.so.102
      -rwxr-xr-x@ 1 root wheel 62836 Sep 19 17:05 couchbase.so.103
      rw-rr- 1 mssteuer wheel 67428 Sep 12 2011 memcache.so
      rw-rr- 1 mssteuer wheel 64120 Sep 12 2011 memcached.so
      rw-rr- 1 mssteuer wheel 467912 Jan 7 2012 mongo.so
      -rwxr-xr-x 1 mssteuer wheel 57312 Jul 14 10:47 phpcups.so
      rw-rr- 1 mssteuer wheel 70148 Mar 23 17:47 ssh2.so
      -rwxr-xr-x 1 root wheel 202672 Sep 19 14:59 xdebug.so
      MICHAEL'S MACBOOK PRO /usr/lib/php/extensions/no-debug-non-zts-20090626: sudo cp couchbase.so couchbase.so.105
      Password:
      MICHAEL'S MACBOOK PRO /usr/lib/php/extensions/no-debug-non-zts-20090626: sudo cp couchbase.so.103 couchbase.so
      MICHAEL'S MACBOOK PRO /usr/lib/php/extensions/no-debug-non-zts-20090626: sudo apachectl restart

          • EXECUTE PHP BELOW TO SET SERIALIZED ARRAY WITH 1.0.3 ***

      echo "<pre>";
      $cb = Zend_Registry::get("couchbase");

      $testarray = array(
      "stringvalue" => "blabla",
      "intvalue" => 1234,
      "arrvalue" => array(
      "stringvalue" => "hello world",
      "intvalue" => 98765,
      ),
      "boolvalue" => true,
      "float" => 1.239393
      );

      try

      { $cb->set("cbtest", $testarray); echo "Result Code:\n"; print_r($cb->getResultCode()); }

      catch(Exception $e)

      { echo $e->getMessage(); }
          • THIS PRINTS OUT THE RESULT BELOW ***

      Result Code:
      0

          • TELNET TO COUCHBASE TO CONFIRM DATA IS SET ***

      MICHAEL'S MACBOOK PRO /usr/lib/php/extensions/no-debug-non-zts-20090626: telnet localhost 11211
      Trying ::1...
      Connected to localhost.
      Escape character is '^]'.
      get cbtest
      VALUE cbtest 31 185
      a:5:{s:11:"stringvalue";s:6:"blabla";s:8:"intvalue";i:1234;s:8:"arrvalue";a:2:

      {s:11:"stringvalue";s:11:"hello world";s:8:"intvalue";i:98765;}

      s:9:"boolvalue";b:1;s:5:"float";d:1.239393;}
      END
      quit
      Connection closed by foreign host.

          • REPLACE 1.0.3 with 1.0.5 and restart Apache ***

      MICHAEL'S MACBOOK PRO /usr/lib/php/extensions/no-debug-non-zts-20090626: sudo cp couchbase.so.105 couchbase.so
      MICHAEL'S MACBOOK PRO /usr/lib/php/extensions/no-debug-non-zts-20090626: sudo apachectl restart

          • EXECUTE PHP BELOW TO TRY AND RETRIEVE ARRAY FROM COUCHBASE, NOW USING 1.0.5 ***

      echo "<pre>";
      $cb = Zend_Registry::get("couchbase");

      $result = $cb->get("cbtest");
      print_r($result);

          • $result IS NULL AND THE "UNKNOWN PAYLOAD" AND "FAILED TO GET VALUE" WARNINGS ARE OBSERVED IN THE LOGS ***

      [Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP Warning: Couchbase::get(): unknown payload type in /Users/mssteuer/Documents/_Titan/XAPI/trunk/application/controllers/TestController.php on line 809
      [Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP Stack trace:
      [Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP 1.

      {main}() /Users/mssteuer/Documents/_Titan/XAPI/trunk/index.php:0
      [Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP 2. Zend_Application->run() /Users/mssteuer/Documents/_Titan/XAPI/trunk/index.php:6
      [Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP 3. Zend_Application_Bootstrap_Bootstrap->run() /Users/mssteuer/Documents/_Titan/XAPI/trunk/library/Zend/Application.php:366
      [Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP 4. Zend_Controller_Front->dispatch() /Users/mssteuer/Documents/_Titan/XAPI/trunk/library/Zend/Application/Bootstrap/Bootstrap.php:97
      [Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP 5. Zend_Controller_Dispatcher_Standard->dispatch() /Users/mssteuer/Documents/_Titan/XAPI/trunk/library/Zend/Controller/Front.php:954
      [Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP 6. Zend_Controller_Action->dispatch() /Users/mssteuer/Documents/_Titan/XAPI/trunk/library/Zend/Controller/Dispatcher/Standard.php:295
      [Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP 7. TestController->testcbAction() /Users/mssteuer/Documents/_Titan/XAPI/trunk/library/Zend/Controller/Action.php:513
      [Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP 8. Couchbase->get() /Users/mssteuer/Documents/_Titan/XAPI/trunk/application/controllers/TestController.php:809
      [Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP Warning: Couchbase::get(): Failed to get a value from server: Generic error in /Users/mssteuer/Documents/_Titan/XAPI/trunk/application/controllers/TestController.php on line 809
      [Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP Stack trace:
      [Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP 1. {main}

      () /Users/mssteuer/Documents/_Titan/XAPI/trunk/index.php:0
      [Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP 2. Zend_Application->run() /Users/mssteuer/Documents/_Titan/XAPI/trunk/index.php:6
      [Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP 3. Zend_Application_Bootstrap_Bootstrap->run() /Users/mssteuer/Documents/_Titan/XAPI/trunk/library/Zend/Application.php:366
      [Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP 4. Zend_Controller_Front->dispatch() /Users/mssteuer/Documents/_Titan/XAPI/trunk/library/Zend/Application/Bootstrap/Bootstrap.php:97
      [Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP 5. Zend_Controller_Dispatcher_Standard->dispatch() /Users/mssteuer/Documents/_Titan/XAPI/trunk/library/Zend/Controller/Front.php:954
      [Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP 6. Zend_Controller_Action->dispatch() /Users/mssteuer/Documents/_Titan/XAPI/trunk/library/Zend/Controller/Dispatcher/Standard.php:295
      [Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP 7. TestController->testcbAction() /Users/mssteuer/Documents/_Titan/XAPI/trunk/library/Zend/Controller/Action.php:513
      [Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP 8. Couchbase->get() /Users/mssteuer/Documents/_Titan/XAPI/trunk/application/controllers/TestController.php:809

          • TELNET INTO COUCHBASE AGAIN TO VERIFY DATA IS STILL PRESENT (IE. IT WASN'T A MISS) ***

      MICHAEL'S MACBOOK PRO /usr/lib/php/extensions/no-debug-non-zts-20090626: telnet localhost 11211
      Trying ::1...
      Connected to localhost.
      Escape character is '^]'.
      get cbtest
      VALUE cbtest 31 185
      a:5:{s:11:"stringvalue";s:6:"blabla";s:8:"intvalue";i:1234;s:8:"arrvalue";a:2:

      {s:11:"stringvalue";s:11:"hello world";s:8:"intvalue";i:98765;}

      s:9:"boolvalue";b:1;s:5:"float";d:1.239393;}
      END

          • THEN, I RE-SET THE SAME ARRAY USING 1.0.5 (SAME PHP CODE AS ABOVE) ***
          • GET VALUE FROM COUCHBASE TO COMPARE ***

      get cbtest
      VALUE cbtest 4 185
      a:5:{s:11:"stringvalue";s:6:"blabla";s:8:"intvalue";i:1234;s:8:"arrvalue";a:2:

      {s:11:"stringvalue";s:11:"hello world";s:8:"intvalue";i:98765;}

      s:9:"boolvalue";b:1;s:5:"float";d:1.239393;}
      END

          • CONCLUSION ***
            The value looks the same, however this one has a "4" flag instead of a "31" flag above... Not sure what that means, but likely the cause of the issue.
      No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

        Hide
        mnunberg Mark Nunberg added a comment -

        Then he is in fact using v1.0.2, not v1.0.3 as originally claimed.

        Quickly looking at the commit for 1.0.3 (i.e. changes between 1.0.2 and 1.0.3) I see significant modification of the flag values. Basically 1.0.3 will set the flag to PHP's internal type code, whereas 1.0.3 and onwards use pecl-memcached style extension flags. See PCBC-61.

        In short, the versions are incompatible, and 1.0.2 is broken. Unfortunately there is no nice way to have a mixed-mode client setting (i the user is daring enough, he can copy the old flag code from 1.0.2+ and paste it in the newer version..) and the design of the old flag mechanism was inherently flawed (and not compatible with memcached either).

        Show
        mnunberg Mark Nunberg added a comment - Then he is in fact using v1.0.2, not v1.0.3 as originally claimed. Quickly looking at the commit for 1.0.3 (i.e. changes between 1.0.2 and 1.0.3) I see significant modification of the flag values. Basically 1.0.3 will set the flag to PHP's internal type code, whereas 1.0.3 and onwards use pecl-memcached style extension flags. See PCBC-61 . In short, the versions are incompatible, and 1.0.2 is broken. Unfortunately there is no nice way to have a mixed-mode client setting (i the user is daring enough, he can copy the old flag code from 1.0.2+ and paste it in the newer version..) and the design of the old flag mechanism was inherently flawed (and not compatible with memcached either).
        Hide
        perry Perry Krug added a comment -

        Thanks Mordechai, I'm checking with the customer again. Is there any sort of addition we could make to 1.0.5+ to make it backwards compatible with 1.0.2?

        Show
        perry Perry Krug added a comment - Thanks Mordechai, I'm checking with the customer again. Is there any sort of addition we could make to 1.0.5+ to make it backwards compatible with 1.0.2?
        Hide
        perry Perry Krug added a comment -

        Okay, we can stand down on this...customer was only testing on a dev environment which was 1.0.2. All prod is 1.0.3 so we shouldn't have any issue.

        Thanks for everyone's help.

        Show
        perry Perry Krug added a comment - Okay, we can stand down on this...customer was only testing on a dev environment which was 1.0.2. All prod is 1.0.3 so we shouldn't have any issue. Thanks for everyone's help.
        Hide
        mnunberg Mark Nunberg added a comment -

        It can be possible to some extent. Let me write a simple patch against 1.0.5 and check it out. I'm not sure if we'd want to place it directly in 1.0.5.. but that is more a question for Matt.

        Show
        mnunberg Mark Nunberg added a comment - It can be possible to some extent. Let me write a simple patch against 1.0.5 and check it out. I'm not sure if we'd want to place it directly in 1.0.5.. but that is more a question for Matt.
        Hide
        ingenthr Matt Ingenthron added a comment -

        Closing this, as 1.0.2 is long ago and this affects primarily a dev environment which can (and should) upgrade.

        Show
        ingenthr Matt Ingenthron added a comment - Closing this, as 1.0.2 is long ago and this affects primarily a dev environment which can (and should) upgrade.

          People

          • Assignee:
            ingenthr Matt Ingenthron
            Reporter:
            perry Perry Krug
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Gerrit Reviews

              There are no open Gerrit changes