dflaven
|
1b110522ca
#1150: Spurious message "A restore is running..." - FIXED !
|
%!s(int64=9) %!d(string=hai) anos |
romainq
|
bebfa57f54
Instrumented the code to help in solving the "restore runing" issue. Completion of commits [3733] znd [3595] = issue an exception if something is going wrong within iTopMutex::TryLock (exceptions are correctly handled in the various places where TryLock is invoked)
|
%!s(int64=9) %!d(string=hai) anos |
dflaven
|
2ea54b8644
Mutex instrumentation for troubleshooting...
|
%!s(int64=10) %!d(string=hai) anos |
dflaven
|
5551f50e4e
Make sure that the SQL mutexes are specific to the current iTop instance, but still preserving the capability for the setup to detect an already running cron job with or without a valid config file.
|
%!s(int64=10) %!d(string=hai) anos |
romainq
|
15a7e9b975
Added a warning when upgrading the application while a CRON is being executed on the same DB
|
%!s(int64=11) %!d(string=hai) anos |
dflaven
|
3185bbf95c
Proper handling of the re-entrence of the Lock/Unlock within the same PHP page. Previously the code was sometimes performing 2 Unlock() for each Lock().
|
%!s(int64=11) %!d(string=hai) anos |
dflaven
|
3d0c9f4e5c
Allow re-entrance in the same named mutex within the same PHP page.
|
%!s(int64=11) %!d(string=hai) anos |
romainq
|
2a2a54895c
CRON: protection against re-entrance now relies on a bullet-proof mutex. Also added the option 'debug=1' to output the call stack in case an exception occurs (not always because of passwords being shown in the call stack)
|
%!s(int64=11) %!d(string=hai) anos |