This was caused by the strict comparison in \utils::IsMemoryLimitOk for the special "-1" value of memory_limit, which was added in c2f5cafa.
Fix was to change \utils::ConvertToBytes : it was returning original value when input was numeric (so if input is '-1' output was '-1') now it always returns an int (input '-1' output -1)
Mutex are using their own DB connection
Because the `wait_timeout` isn't specified when opening the connection, it could be closed before we released the lock : if so the lock is silently released !
We are now setting this variable directly when opening the connection to avoid such case (setting 86400s, so 1 day : this should be enough !)
iTop is sending large volume of data to the server, and those data can be truncated due to this php.ini option.
Now we are checking for common issues : if the data is truncated a log is done (IssueLog, warning level, no channel) and the corresponding column is set as not selected.
User will still see an inconsistent result, but we won't have PHP notices generated anymore, and a log can tell what caused the issue.
Some scripts are setting the memory_limit PHP option : setup, csvimport and XLSX export. This was done to avoid crashing when dealing with such large amount of data.
But sometimes we were setting the value without any prior check, so we could actually lower the memory_limit value :/
Now this memory_limit change is done using \utils::SetMinMemoryLimit, which will call ini_set if and only if the current value is lower than the one to be set.
Setup calls (setup/ajax.dataloader.php and webservices/backoffice.dataloader.php) were left as is as they weren't subject to this bug, and also they are more complex (logging done on each case).
