TYPO3 Core

committed Stucki's patch to 4-2 and trunk

on PHP 5.2.4 OSX Leopard

i get empty FE (no render at all, then it crashes browser (rolling cursor on FF 2 and Safari 3))

BTW: the lock directory is created in typo3temp, and files are created in there by the new patch.
but whatever call in the FE gives nothing... no error, but crash)

Can you please try to access the same site using a different browser first? I need to get some pointers...

i have my dev trunk in local
until this last update everything was perfect.

now i went a bit deeper: the browsers don't crash anymore (by "crash" i meant they went in "rolling cursor mode" until i had to force quit them)

now after several (about 20) seconds, the FE page shows up
but then it takes ages to reload or load other pages.

apache's log shows nothing unusual

is there a flag to disable this new behaviour? just to do some checks?

Of course! You can disable it with $TYPO3_CONF_VARS['SYS']['lockingMode'] = 'disable';

Other possible values for this setting are "simple" (that's default), "flock" and "semaphore".

I will provide you with a patch so you can do some debugging and find out where the problem comes from...

thanks Michael

i don't know what it means, but with "disable", "flock" and "semaphore" it works well

only "simple" is giving problems...

one hint: if the FE is trying to load a page with "simple" set, and i try to load a page in the BE, neither there it works...
maybe the FE process does takes all the webserver resources?

Important note: While you are debugging, make sure that you do not use Firefox unless you have changed the following settings (call "about:config" for this):
- network.http.use-cache = false
- network.http.max-connections-per-server = 4 (or more...)
- network.http.max-persistent-connections-per-server = 4 (or more...)

It took me quite some time to find out that the strange behaviours were caused by Firefox.

i did set FF as you suggest.

for now it didn't change anything from previous behaviours!

anyway Safari behaves the same...

Attached you find a file "bug_7333_debug.diff". Please apply this, clear your cache, and reproduce your problem.

Can you tell me what your failing request is doing?

- michael

One more thing: The lock directory should be created automatically.

I've attached a post patch which might solve Stefano's behaviour.

Problem:
If no_cache is enabled during runtime, maybe there were already some locks aquired in that process but won't be released because no_cache=1 generally indicates that noch locks are required - which is wrong in this special case.

Solution:
On releasing, always check if the lock object exists and was actively aquired, if so, release the lock.

edit: I got an "Internal Server Error" on testing without the patch. If the lock is not released correctly this will cause several strange behaviours. If the process is terminated by "whatever" the lock file remains - e.g. shm locks are released after process was terminated (correctly finished or killed).

Makes sense, thank you! Stefano, can you report if the fix solves your problem?

Hi Michael

yes i did apply both patches, but nothing changed

i can say that yes: i did put no_cache everywhere (since it's an intranet application, not a website)

maybe we could suggest to put.
$TYPO3_CONF_VARS['SYS']['lockingMode'] = 'disabled';
to solve problems?

Hi Stefano,

sorry, I forgot to mention, that the lock files in ./typo3temp/locks/ have to be removed. Otherwise the behaviour will remain. Could you please test again? Thanks!

Disabling the locking does not really fix the general behaviour. But you can try to use the mode 'semaphore' which works different and locks get released if the PHP process terminates.

YES! now it works!

i can give you also my cc_debug feedback:

[debug] in file
user variable debug
> Variable scope report
String (79) variable pagesection was found in cache. Try to read the pages record from cache, too...

(2) prev | next
[2008-02-11 15:06:22]
[debug] in file
user variable debug
> Variable scope report
String (91) variable pages record was not found in cache. Try to acquire lock and if successful, build the page.

(3) prev | next
[2008-02-11 15:06:22]
[debug] in file
user variable debug
> Variable scope report
String (25) variable Trying to acquire lock...

(4) prev | next
[2008-02-11 15:06:23]
[debug] in file
user variable debug
> Variable scope report
String (76) variable Lock "e9d5cc2751aa260190a721f7d5e5cd46" was successfully acquired.

(5) prev | next
[2008-02-11 15:06:23]
[debug] in file
user variable debug
> Variable scope report
String (52) variable Successfully acquired lock. Start building the page.

(6) prev | next
[2008-02-11 15:06:23]
[debug] in file
user variable debug
> Variable scope report
String (29) variable Releasing all existing locks.

(7) prev | next
[2008-02-11 15:06:23]
[debug] in file
user variable debug
==> Variable scope report
String (68) variable Lock "e9d5cc2751aa260190a721f7d5e5cd46" has been released.

I've attached a new patch which removes semaphores if the current process was able to release a semaphore.

In semaphore mode, the semaphores stay and are not removed:
(use ipcs on linux systems to show active semaphores)

Warning: sem_get() [function.sem-get]: failed for key 0x47da8e21: No space left on device in /home/web/typo3/typo3_svn/TYPO3core/TYPO3_4-2/t3lib/class.t3lib_lock.php on line 113

Warning: sem_acquire(): supplied argument is not a valid SysV semaphore resource in /home/web/typo3/typo3_svn/TYPO3core/TYPO3_4-2/t3lib/class.t3lib_lock.php on line 171

Warning: sem_get() [function.sem-get]: failed for key 0x7c614959: No space left on device in /home/web/typo3/typo3_svn/TYPO3core/TYPO3_4-2/t3lib/class.t3lib_lock.php on line 113

Warning: sem_acquire(): supplied argument is not a valid SysV semaphore resource in /home/web/typo3/typo3_svn/TYPO3core/TYPO3_4-2/t3lib/class.t3lib_lock.php on line 171

Warning: sem_release(): supplied argument is not a valid SysV semaphore resource in /home/web/typo3/typo3_svn/TYPO3core/TYPO3_4-2/t3lib/class.t3lib_lock.php on line 211

Warning: sem_release(): supplied argument is not a valid SysV semaphore resource in /home/web/typo3/typo3_svn/TYPO3core/TYPO3_4-2/t3lib/class.t3lib_lock.php on line 211

Fixing the mentioned issues takes place in bug #18279.
So I think, that this one can be closed again?

Yes.