Bug #23545
closed
Memcache::delete() without timeout param causes loss of memcache server in pool
0%
Description
I found this problem in typo3 v. 4.3.x in combination with the PECL Memcache extension v.1.4.4
(this bug doesn't seem to occur in all Memcache versions)
The problem is that Memcache::getServerStatus() return 0 after a call to Memcache::delete() without the 2nd timeout param. This means the Memcache server is not available anymore so all the following get()/set() calls will return false.
In TYPO3 v. 4.3.5 this will result in a 't3lib_cache_Exception' wich causes typo3 to crash. So the bug itself is not in the TYPO3 core but it's better to use the 2nd timout param (default value of 0) in Memcache::delete() calls to prevent people from getting these exceptions.
People who use an older TYPO3 version don't get these exception, but since half of the Memcache::set() calls will fail it's not very effective..
Memcache::delete() calls occur in file:
t3lib/cache/backend/class.t3lib_cache_backend_memcachedbackend.php
in the methods:
remove() & removeIdentifierFromAllTags(),
(issue imported from #M15721)
Files
Updated by Michiel Roos almost 14 years ago
http://www.php.net/manual/en/memcache.delete.php
bool Memcache::delete ( string $key [, int $timeout = 0 ] )
It's not recommended to use the timeout parameter. The behavior differs between memcached versions, but setting to 0 is safe. Other values for this deprecated feature may cause the memcache delete to fail.
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.
Updated by Christian Kuhn almost 14 years ago
- trunk rev. 10438
- 4.5 rev. 10439
- 4.4 rev. 10440
- 4.3 rev. 10441
Updated by