Bug #18084

Better solution for "Page is being generated"

Added by Bernhard Kraft over 13 years ago. Updated about 9 years ago.

Status:
Closed
Priority:
Must have
Category:
-
Target version:
-
Start date:
2008-01-31
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.2
PHP Version:
4.3
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

The message "Page is being generated" is typical for TYPO3. No other CMS is generating such messages and it is not very clear why such messages are necessary.

Currently those pages get sent to "Client/Browser B" when another process (started by "Client/Browser A") has started to render the same page as requested by client A.

The reason for this lies inside the caching mechanism of TYPO3. While a page gets generated and another process requests the same page the second process delivers the "page is being generated" screen with an 10 seconds timeout/reload - so the page doesn't get generated twice - which would increase server load.

But currently this does not work very well - if two clients request the same page almost concurrently it will get created twice (Check the 100ms png in the supplied images). And this message is very annoying.

Solution:
See my posting in the dev-newsgroup:

http://lists.typo3.org/pipermail/typo3-dev/2008-January/027357.html

(issue imported from #M7333)


Files

lockPageGeneration_v3.diff (18.9 KB) lockPageGeneration_v3.diff Administrator Admin, 2008-02-08 00:00
bug_7333_debug.diff (4.07 KB) bug_7333_debug.diff Administrator Admin, 2008-02-08 23:08
0007333_post.patch (1.64 KB) 0007333_post.patch Administrator Admin, 2008-02-11 14:14
0007333_post_v2.patch (2.06 KB) 0007333_post_v2.patch Administrator Admin, 2008-02-16 14:44

Related issues

Related to TYPO3 Core - Bug #17088: "Duplicate entry" in cache_pagesection when using framesClosedMichael Stucki2007-03-07

Actions
Related to TYPO3 Core - Bug #18279: Several problems with locking API (t3lib_lock)ClosedOliver Hader2008-02-22

Actions
#1

Updated by Ingo Renner over 13 years ago

committed Stucki's patch to 4-2 and trunk

#2

Updated by Stefano Cecere over 13 years ago

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)

#3

Updated by Michael Stucki over 13 years ago

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

#4

Updated by Stefano Cecere over 13 years ago

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?

#5

Updated by Michael Stucki over 13 years ago

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...

#6

Updated by Stefano Cecere over 13 years ago

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?

#7

Updated by Michael Stucki over 13 years ago

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.

#8

Updated by Stefano Cecere over 13 years ago

i did set FF as you suggest.

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

anyway Safari behaves the same...

#9

Updated by Michael Stucki over 13 years ago

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

#10

Updated by Ingmar Schlecht over 13 years ago

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

#11

Updated by Oliver Hader over 13 years ago

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).

#12

Updated by Michael Stucki over 13 years ago

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

#13

Updated by Stefano Cecere over 13 years ago

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?

#14

Updated by Oliver Hader over 13 years ago

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.

#15

Updated by Stefano Cecere over 13 years ago

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.

#16

Updated by Oliver Hader over 13 years ago

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

#17

Updated by Oliver Hader over 13 years ago

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

#18

Updated by Michael Stucki over 13 years ago

Yes.

#19

Updated by Chris topher about 9 years ago

  • Category deleted (Communication)
  • Target version deleted (-1)

Also available in: Atom PDF