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

[netz-haut - stephan seitz]

Ernesto,

the issue in debian squeeze is a lower level incompatibility between the php5-memcache and memcached (each from the squeeze repository).
I've already filed a bugreport to the php5-memcache maintainer. He's currently aware of this, but due to a version freeze, he needs to backport.

The problem is not only faced by TYPO3, it comes up with any php application utilizing the memcache framework.

To get rid of this issue, do:

# apt-get remove php5-memcache
# apt-get install php5-dev
# pecl install memcache

Cheers,

Stephan


 
> 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
> _______________________________________________
> Before posting to this list, please have a look to the posting rules
> on the following websites:
> 
> http://typo3.org/teams/core/core-mailinglist-rules/
> http://typo3.org/development/bug-fixing/diff-and-patch/
> _______________________________________________
> TYPO3-team-core mailing list
> TYPO3-team-core at lists.typo3.org
> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-team-core