[TYPO3-dev] malformed cached config files

Roland Hager roland.hager at tu-berlin.de
Wed Nov 2 10:21:43 CET 2011


Hi Helmut,

On 01.11.2011 23:19, Helmut Hummel wrote:
>[...]
>
> Thanks for bringing up this topic.
> I also observe problems with (re-)creating these files.
> The scenario you describe also happend (luckily only) once recently in a
> high load cluster environment, similar to the one you described. Since
> this happend only once, we did not dig into it any further, but since
> you also mention suh problems, it's probably worth doing so.
>

Nice to hear, that we are not the only one in TYPO3-Universe having this 
problem :-)


> There is a race conditions between the checks if the files are available
> and the place where they are actually required. What I observe
> regularily in the php error log, that requiring the temp_cached files
> fail (failed opening required ...)
>
> In general this process not protected against parallel execution.
> So in high load scenarios it may happen, that the cache-files will be
> written more than once at the same time. Hopfully the file system
> locking works properly then...


As mentioned I wrote a check function that is called directly after 
writing the files. When I deleted the config cache via the backend I got 
an error message from three out of four webservers, that a cached config 
  file is malformed (wrong syntax or to many closing php-tags). The 
function moves the files and regenerates them again in that cases. After 
two retries the files were recognized as OK.
The funny things:
	- the corrupted copy was totally fine
	- I got multiple "succesfully recreated" messages per server.

So the cached config files were created from more than one server and 
more than once per server. This might be OK in most cases, since every 
server should write the exact same content but as we noticed: this can 
cause problems.
The message indicates to me, that when the files are read in to check 
the content, they might be incomplete due to other server / processes 
just creating the files them self. The same problem may occur for other 
users just visiting our site.

=> I guess that's the raise condition you mentioned :-)

We might have other problems related to our networking filesystem but 
this problem seems quite clear.


Synchronizing every "cached files exist" call might could do the trick 
but we need to be carefully not to serialize every page hit.

I'd like to think of doing this within the database to circumvent 
problems with the filesystem.

Does TYPO3 support something like that? A DB based locking mechanism?


> [...]
> As you probably already know now, they're only regenerated when they are
> not found. And they are only deleted, if extensions are installed or the
> extension cache is cleared manually.
>[...]

Yes, I grep'ed a bit around and came to that point. The problem is, the 
files are regenerated when nobody of our team neither cleared the cache 
nor installed / updated the extensions. My guess is, that the files are 
sometimes not reachable due to our network filesystem. So this is 
probably not a TYPO3 issue.


Thanks for your reply!
Roland




More information about the TYPO3-dev mailing list