FWIW: http://ca3.php.net/manual/en/function.session-write-close.php "Session data is usually stored after your script terminated without the need to call *session_write_close()*, but as session data is *locked* to prevent concurrent writes *only one script may operate on a session* at any time. When using framesets together with sessions you will experience the frames loading *one by one due to this locking*. You can reduce the time needed to load all the frames by ending the session as soon as all changes to session variables are done." ~Daniel Friesen(Dantman, Nadir-Seen-Fire) of: -The Nadir-Point Group (http://nadir-point.com) --It's Wiki-Tools subgroup (http://wiki-tools.com) --The ElectronicMe project (http://electronic-me.org) --Games-G.P.S. (http://ggps.org) -And Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) --Animepedia (http://anime.wikia.com) --Narutopedia (http://naruto.wikia.com) Daniel Barrett wrote:

Perhaps we should begin to look at this at a webserver level. Perhaps the webserver is blocking and can only handle one request at a time. Try testing this on a variety of webservers. Apache, lighttpd, nginx... I think Apache used worker processes, and I know that nginx does. So it may be a good idea to debug this on different numbers of worker processes. ~Daniel Friesen(Dantman, Nadir-Seen-Fire) of: -The Nadir-Point Group (http://nadir-point.com) --It's Wiki-Tools subgroup (http://wiki-tools.com) --The ElectronicMe project (http://electronic-me.org) --Games-G.P.S. (http://ggps.org) -And Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) --Animepedia (http://anime.wikia.com) --Narutopedia (http://naruto.wikia.com) Daniel Barrett wrote:

Here's a summary of the problem and my findings. It's still unsolved. Any help appreciated! Symptom: ALL requests to MW 1.13 time-out while ANY ONE user is hitting a long-running page (e.g., one with a long-running parser tag) Theory: PHP sessions are locked - Brion reproduced this behavior only per-session, by hitting a long-running wiki page in one browser tab and a second page in a second tab. He did not experience it for two simultaneous, separate sessions. - I have the problem even when two separate *users* hit two MediaWiki pages from two different PCs. A long-running page prevents wiki pages from being served to the second user. So I suspect my issue is different from Brion's. - I got the same results Brion did by writing two trivial PHP scripts that simply call session_start(), with one of them sleeping for 30 seconds. The problem is limited to MediaWiki pages. Therefore, the problem I'm experiencing (everyone blocked) is different from the "PHP session" behavior Brion reproduced. Ruled out: - It seems not an Apache problem because other PHP pages (non-MediaWiki) on the same webserver are not affected. They always get served immediately, even when a long-running MediaWiki page is running. - It's not due to a third-party extension because I've reproduced this problem on a virgin MW 1.13 install. - Occurs for MW servers on both Windows 2003 Server and CentOS Linux with different Apache and PHP configurations. - It's not eAccelerator, which I disabled and the problem still happened. Stack dump when the problem occurs (MW 1.13): Fatal error: Maximum execution time of 30 seconds exceeded in includes\\db\\Database.php on line 579 Stack trace: 1. {main}() index.php:0 2. MediaWiki->checkInitialQueries() index.php:60 3. Title::newMainPage() includes\\Wiki.php:105 4. wfMsgForContent() includes\\Title.php:293 5. wfMsgReal() includes\\GlobalFunctions.php:380 6. wfMsgGetKey() includes\\GlobalFunctions.php:432 7. StubObject->get() includes\\GlobalFunctions.php:467 8. StubObject->__call() includes\\StubObject.php:0 9. StubObject->_call() includes\\StubObject.php:76 10. call_user_func_array() includes\\StubObject.php:58 11. MessageCache->get() includes\\StubObject.php:0 12. MessageCache->getMsgFromNamespace() includes\\MessageCache.php:543 13. MessageCache->load() includes\\MessageCache.php:606 14. MessageCache->saveToCaches() includes\\MessageCache.php:250 15. BagOStuff->add() includes\\MessageCache.php:419 16. SqlBagOStuff->set() includes\\BagOStuff.php:100 17. SqlBagOStuff->delete() includes\\BagOStuff.php:274 18. SqlBagOStuff->_query() includes\\BagOStuff.php:288 19. MediaWikiBagOStuff->_doquery() includes\\BagOStuff.php:319 20. Database->query() includes\\BagOStuff.php:433 21. Database->doQuery() includes\\db\\Database.php:540 Any help appreciated, or advice on what to check next. DanB

Since I've reproduced this behavior on 4 wiki servers now, and it's not due to session locking as far as I can tell, I've filed it as: https://bugzilla.wikimedia.org/show_bug.cgi?id=15460 DanB