Bug #40420
closed
Semaphore based locking returns warning
Added by Rudi Meyer about 12 years ago.
Updated about 7 years ago.
Description
When using the 'semaphore' type locking functionality, sem_acquire return warning when identifier is released in another parallel request.
Example:
Core: Error handler (FE): PHP Warning: sem_acquire(): failed to acquire key 0x91b615ca: Identifier removed in /var/www/lib/typo3_src-4.6/t3lib/class.t3lib_lock.php line 211.
Is I understand it the flow is as following:
1. Request #1 is received.
2. sem_get is called with "id" as key
3. sem_acquire acquires semaphore with identifier from sem_get
4. Page generation begins
5. Request #2 is received
6. Request #2 sem_gets with "id" as key
7. Request #2 start loop on sem_acquire until it gets a lock
8. Request #1 completes, releases lock and removed identifier
9. Request #2 can't acquire, identifier is gone.
This could be considered similar to the unlink issue with the 'standard' locking method: http://forge.typo3.org/issues/32282 - the solution could be the same, adding a '@'...?
Files
Here is my suggestion for a fix, I've gone with the same strategy as in http://forge.typo3.org/issues/32282, that is ignoring the warning. We know it will occur, we know why and we kinda don't care.
The patch is doable on both 4.5, 4.6 and 4.7 since no work has been done on 'class.t3lib_lock.php' in that time.
Hi Rudi!
This can only be solved cleanly by keeping a count on how many processes are currently having this semaphore.
The last one remaining has to remove the semaphore then.
This would of course require some shared memory or a file to store the number of processes. That takes time.
So my suggestion would be to NOT remove the the semaphore at all. Usually the same IDs are requested over and over again, so that shouldn't be a problem.
Although on heavy load this might cause issues with maximum resources available in the OS.
If that is the case, we've to implement shared memory.
What do you think?
- Status changed from New to Under Review
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
- Status changed from Resolved to Closed
Also available in: Atom
PDF