[TYPO3-core] [OT] Could not acquire lock for ClassLoader cache creation

Peter Russ peter.russ at 4many.net
Thu May 8 09:13:49 CEST 2014


--- Original Nachricht ---
Absender: Markus Klein
Datum: 08.05.2014 00:40:
> Hi!
>
>> --- Original Nachricht ---
>> Absender: Markus Klein
>> Datum: 07.05.2014 22:19:
>>> Hi!
>>>
>>>>> Brian Lynch wrote:
>>>>>
>>>>>> Any thoughts on this?
>>>>> Well, this is how simple locking works. There is an empty file
>>>>> created to notice further processes that a critical operation is in progress.
>>>>> After that, the file should be deleted. Then the next process can
>>>>> take the lock and do a critical operation.
>>>>>
>>>>> The questions is why the file is not deleted.
>>>>>
>>>> Perhaps PHP execution time is limited to 30 secs and the process dies
>>>> before it can delete the file.
>>>> This would indicate that there is a feature missing after which time
>>>> an other process would get the lock...
>>> Actually this feature is present for ages and looks like this:
>>>
>>> if (file_exists($this->resource)) {
>>> 	$this->sysLog('Waiting for a different process to release the lock');
>>> 	$maxExecutionTime = (int)ini_get('max_execution_time');
>>> 	$maxAge = time() - ($maxExecutionTime ?: 120);
>>> 	if (@filectime($this->resource) < $maxAge) {
>>> 		@unlink($this->resource);
>>> 		$this->sysLog('Unlinking stale lockfile');
>>> 	}
>>> }
>>>
>>> So there is something wrong with the file. Either the filectime() is incorrect
>> (which I rather doubt) or the unlink() does not work.
>>> I suggest to go into this file:
>>> typo3/sysext/core/Classes/Locking/Locker.php
>>> Line 275: Remove the @ there and watch the error log and/or the output.
>> Locking like this is ideal for raise conditions is a multi-server environment with
>> NFS. NFS has "some" delay to synch between different machines.
>> So under heavy load it happens that different processes can get the lock.
>> Something a single place developer will never experience.
>> But happena on enterprise solutions.
>> To avoid this memcache is a better place to handle the lock.
> I fully agree Peter!
>
> But we invested quite some time to find a safe default which works by default in most cases.
> All other locking/synchronization solutions need some extra server prerequisites which are not part of a default PHP installation.
> That's also the reason why TYPO3 CMS (and almost any other PHP based software we had a look at) does not have any proper synchronization mechanism.
> A good example is cache access. There's no way to implement a proper reader/writer pattern as there's no mechanism that works on all operating systems / webservers / SAPIs.
>
>
Thank you for your reply, Markus.
Most interesting part for me: "we invested quite some time to find a 
safe default".
This means: not enterprise ready ;-)

It should be configurable like the caching framework: default locker is 
file locking. But there could also be DB based, APC or memcache based 
lockers.

That's what I would expect from a solution claiming "enterprise" cms. 
But definetly not "by default in most cases".

If help is required pls let me know.

Peter

-- 
Fiat lux! Docendo discimus.
_____________________________

http://www.xing.com/profile/Peter_Russ



More information about the TYPO3-team-core mailing list