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

[Ernesto Baschny [cron IT]]

Ernesto Baschny [cron IT] schrieb am 07.02.2011 11:42:
> 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.

REMINDER...

I've been hitting on this issue on more and more upgrades to Debian
Squeeze we are facing these days.

So I would ask you to read the arguments and see if it's ok if we could
fix it in the proposed way.

Cheers,
Ernesto