[TYPO3-core] RFC #15721: Bug: Memcache::delete() without timeout param causes loss of memcache server in pool

[Ernesto Baschny [cron IT]]

Steffen Gebert schrieb am 06.02.2011 12:58:

>> Bugtracker references:
>> http://bugs.typo3.org/view.php?id=15721
>>
>> Branches:
>> (all that have memcached capability)
>>
>> Problem:
>>     bool Memcache::delete ( string $key [, int $timeout = 0 ] )
>>
>> Different versions of memcache handle the missing time differently.
>> Prior to 1.4.3 a time wasn't required but 1.4.4+ requires a 0 for a
>> timeout.

> I'm pretty sure you already found
> http://brian.moonspot.net/php-memcached-issues
> He aimed to correct the documentation and instead write
>> DON'T USE THIS PARAMETER, IT HAS BEEN DEPRECATED IN THE MEMCACHED SERVER! 
> Version 1.4.4? Wow.. it's from 2004. So older Debians used < 1.4.4?

Squeeze comes with memcached v1.4.5, which is the latest stable
memcached released, according to http://memcached.org/

What you mean is the php5-memcache module:

- Squeeze comes with v3.0.4
- Lenny came with v3.0.1
- Etch came with v2.0.1

I wonder why Debian comes with this "beta version", which in the article
you mentioned was deemed to be buggy:

> A very problematic issue with this extension is with the 3.0 beta
> release. It needs to just die. It has huge bugs that, IMO, were
> introduced by the previous maintainers in an effort to bring it up to
> speed, but never saw them through to make sure the new code worked.
> In their defense, it is marked as beta on PECL.

I would trust the Debian maintainers to have checked that out and I
haven't had a problem with 3.0.1 (Lenny) until now, I must confess, so I
expect 3.0.4 to be ok too.

Other than that, the article mentioned that the "maintainance of the
package was abandonned", but it seems to have been taken over already,
because there has been a new release after that announcement (3.0.5).

> Can you imagine that it has sth. to do with this revision?
> http://svn.php.net/viewvc?view=revision&revision=271303
> Thy introduced a new setting default_timeout there.
> 
> I have no memcache setup, so I can't test it.. it REALLY sounds weird to
> have to pass a value for a deprecated parameter (and the mentioned blog
> also states that it should not be used).
> I trust you, Michiel, that it might solve problems, however I have the
> fear that it breaks other installations.
> 
> Have you searched for more information in the web? Otherwise I tend to
> ask the pecl-memcache developers directly, what they think of this option.

Another interesting fact:

  http://pecl.php.net/bugs/bug.php?id=17566

This was a bug in php5-memcache 3.0.4, fixed in 3.0.5 (not fixed in
Squeeze yet). Maybe this is the source of the problem Michiel found
after the Squeeze upgrade.

I did the following test (php script attached) with:

- Etch (memcached v1.1.12, php5-memcache v2.0.1)
- Lenny (memcached v1.2.2, php5-memcache v3.0.1)
- Squeeze (memcached v1.4.5, php5-memcache v3.0.4)

I could confirm that every variant worked as expected, only the Squeeze
variant *without* the "0" parameter gave this notice:

before:123
PHP Notice:  MemcachePool::delete(): Server localhost (tcp 11211, udp 0)
failed with: CLIENT_ERROR bad command line format.  Usage: delete <key>
[noreply]
 (0) in - on line 7
after:

Adding the "0" parameter made it work again and also worked as before in
older releases.

So I feel that the "0" parameter is the most "stable" choice to do here,
as it works with older versions and also with the (broken) newer versions.

So +1 on reading and testing.

Cheers,
Ernesto

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.typo3.org/pipermail/typo3-team-core/attachments/20110207/3e5d491f/attachment.htm>