Several problems with locking API (t3lib_lock)
The locking API has problems if an extension sets TSFE->set_no_cache().
When a page is rendered, a lock is generated as long as the page itself isn't set to be uncached. At this point in time, we know nothing about what individual extensions will do within page caching. When rendering completes, we again check to see if the page is marked as uncached, which it may be because of an extension setting TSFE->set_no_cache. If the page is now marked as uncached, we don't do anything with locks which in turn leaves us with an open lock. Subsequent reloads of the page will take approximately 30 seconds due to the open locks.
The attached patch fixes this issue by releasing the locks within TSFE->set_no_cache(). The patch also contains some debug output for more insight into the problem, but this should be removed before its committed.
I'm also attaching a test extension that contains a frontend plugin for setting TSFE->set_no_cache(). You can first try the plugin without the patch. Make sure you're not logged into the backend and page loads should take approximately 30 seconds. After applying the patch, it should be back to normal speeds.
(issue imported from #M7630)
#2 Updated by Oliver Hader almost 12 years ago
The attachment "0007630_v2.patch" replaces the previous patch and was also posted to core list.What does this patch do?
- always release aquired locks (no matter if caching was disabled because this could also have been happened during runtime)
- always remove semaphores (additional to release) to avoid shm leaks
- added sysLog method and its calls to t3lib_lock
- create typo3temp/locks/ directory automatically if it does not exist
#5 Updated by emds-itsupport almost 12 years ago
Thanks for that... however I have an error message for tslib_fe.php (cf. file attached: errorMerge.gif), relates to version number. I am under version 3286.
Concerning t3lib_lock.php, this file is not present anymore in the rep, which is a bit worrying.