Details
-
Bug
-
Resolution: Obsolete
-
Medium
-
3.10.0, 4.0.0
-
None
Description
The main pbl is it is hard to be sure that after we steal a mutex the process that originally had it open will not continue to manipulate the locked file
1 - if on win, the posix_kill function does not exist
workaround: look on php.net man pages for tips.
my suggestion: bundle pskill from sysinternals with ez and invoke it via a call to 'system'
2 - if mutex is held by another frontal server, posix_kill will not work.
workaround:
A - add to mutex pid also the host IP address, so that we can distinguish which webserver is holding the lock, plus a unique string (security feature) and the url of a php page that can be used to kill that process
B - if mutex is held by non-local process, try to kill the remote process by doing a get on a specific ez php page (to be created) which will kill process iff the mutex exists, the pid exists, the check string is correct. That page needs to be fast, so maybe it should be a new index_killmutex.php, that does not load lang or debug settings...
B1 - as an alternative, if mutex file is held by non local process, do nothing...