php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #77056 with memcache pool, on a session key miss, other servers not checked
Submitted: 2018-10-25 09:56 UTC Modified: 2021-06-08 13:51 UTC
From: aleksandar dot kuktin at infostud dot com Assigned:
Status: Open Package: memcache (PECL)
PHP Version: 7.3.0RC3 OS: Ubuntu
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: aleksandar dot kuktin at infostud dot com
New email:
PHP Version: OS:

 

 [2018-10-25 09:56 UTC] aleksandar dot kuktin at infostud dot com
Description:
------------
Using memcache extension with failover.

Regression first discovered on upgrade from PHP-5.6 to PHP-7.0, still persists in PHP-7.3.0RC3.

When using a memcache pool for HA storage of session data, as memcache does not have replication, a workaround is used. First, PHP stores the identical session data to all members of a pool. Second, reads are iterated over all members of a pool until either one is found with session data or all members are found to not contain data - which means data doesn't exist. Thus, in the event of a failure and loss of data on a subset of nodes, they are slowly repopulated as a side-effect of normal application operation, preventing data loss in all but most extreme circumstances.

This feature fails to materialize since PHP-7.0.

It may be important to note this feature also fails to materialize if using the memcached extension; it only works if using the (very old) memcache extension.

Since PHP-7.0, reads are attempted only once, and if the first node in a pool does not contain data, this is treated as if data doesn't exist - yet it does on other nodes in the pool.

As for the specifics, we believe we have excluded the memcache extension itself. We are using Ondrej's PPA repo for PHP, and with it we are using the exact same deb package (SHA256 match) for php-memcache on both PHP-5.6 and PHP-7. Issue present on both Ubuntu-14.04 and Ubuntu-16.04 (18.04 not test as of yet).

Test script:
---------------
<?php
session_start();
if (array_key_exists("opennum", $_SESSION)) {
  $myses = $_SESSION["opennum"];
} else {
  $myses = 0;
}
$_SESSION["opennum"] = $myses + 1;
echo "success? myses = ${myses}\n";


// wget it repeatedly

Expected result:
----------------
Commands issued (>), responses sent (<) to/from memcache servers by PHP-5.6:

SERVER 0
> incr mbbh79abrh9758v87pbjj012k3.lock 1
< NOT_FOUND
> add mbbh79abrh9758v87pbjj012k3.lock 768 15 1
> 1
< STORED
> get mbbh79abrh9758v87pbjj012k3
< END
> set mbbh79abrh9758v87pbjj012k3 0 86400 12
> opennum|i:1;
< STORED
> set mbbh79abrh9758v87pbjj012k3.lock 768 15 1
> 0
< STORED

SERVER 1
> incr mbbh79abrh9758v87pbjj012k3.lock 1
< NOT_FOUND
> add mbbh79abrh9758v87pbjj012k3.lock 768 15 1
> 1
< STORED
> get mbbh79abrh9758v87pbjj012k3
< END
> set mbbh79abrh9758v87pbjj012k3 0 86400 12
> opennum|i:1;
< STORED
> set mbbh79abrh9758v87pbjj012k3.lock 768 15 1
> 0
< STORED


Actual result:
--------------
Commands issued (>), responses sent (<) to/from memcache servers by PHP-7.0, PHP-7.1, PHP-7.2 and PHP-7.3.0RC3:

SERVER 0
> incr a4126f4585d5fc35dcff6b21c6fddabb.lock 1
< NOT_FOUND
> add a4126f4585d5fc35dcff6b21c6fddabb.lock 768 15 1
> 1
< STORED
> get a4126f4585d5fc35dcff6b21c6fddabb
< END
> set a4126f4585d5fc35dcff6b21c6fddabb 0 86400 12
> opennum|i:1;
< STORED
> set a4126f4585d5fc35dcff6b21c6fddabb.lock 768 15 1
> 0
< STORED

SERVER 1
> set a4126f4585d5fc35dcff6b21c6fddabb 0 86400 12
> opennum|i:1;
< STORED
> set a4126f4585d5fc35dcff6b21c6fddabb.lock 768 15 1
> 0
< STORED


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2021-06-02 10:34 UTC] cmb@php.net
-Status: Open +Status: Feedback -Package: Session related +Package: memcache -Assigned To: +Assigned To: cmb
 [2021-06-02 10:34 UTC] cmb@php.net
Is this still an issue with any of the actively supported PHP
versions[1] and latest memcache (4.0.5.2 or 8.0)?

[1] <https://www.php.net/supported-versions.php>
 [2021-06-08 08:51 UTC] aleksandar dot kuktin at infostud dot com
-Status: Feedback +Status: Assigned
 [2021-06-08 08:51 UTC] aleksandar dot kuktin at infostud dot com
Yes, I can replicate the bug with PHP-8.0.7 and memcache extension 4.0.5.2 . The communication with memcache servers is identical to the one reported here before.

I have a hunch that, way back in the day, when someone was implementing sessions with the memcache extension (but not with the memcached extension), they added logic for this failover. But it was probably implemented in some glue code between the main PHP session code and the memcache extension. And then when you guys rewrote PHP for PHP-7.0, you simply bulldozed over this bit of oddly placed but vital logic.
 [2021-06-08 13:51 UTC] cmb@php.net
-Status: Assigned +Status: Open -Assigned To: cmb +Assigned To:
 [2021-06-08 13:51 UTC] cmb@php.net
Thanks for checking with current versions.  While the issue might
be caused by something in php-src, I nonetheless suggest that you
file an issue with the memcache extension[1]; they may not look at
this bugtracker, and PHP devs may not be familiar with memcache
(at least I am not). 

[1] <https://github.com/websupport-sk/pecl-memcache/issues>
 [2024-01-24 20:33 UTC] aleksandar dot kuktin at becomingbelte dot rs
Hi, since first reporting this bug, I've left my old job and hence lost access to the email that was used to report it. My new email is the one that's associated with this comment.

At some point this or next month, I'll begin excavating the memcache extension and php, so as to move this bug along.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Nov 24 05:01:32 2024 UTC