Menu
▾
▴
#867 Maximum execution time errors due hardcode
closed
fixed
Core/OQL
major
2.0.2
defect
2014-05-27
2014-01-08
No
Hello
While trying to do a bulk data modification, I received the following messages:
[06-Jan-2014 14:07:28] PHP Fatal error: Maximum execution time of 5 seconds exceeded in /htdocs/itop/core/cmdbsource.class.inc.php on line 259
[06-Jan-2014 13:54:21] PHP Fatal error: Maximum execution time of 5 seconds exceeded in /xampp/htdocs/itop/core/dbobjectset.class.php on line 398
In the php.ini file the variable "max_execution_time" I have set it with the value of 1800.
I found that the following scripts have a hardcoded value of 5 seconds for "set_time_limit" function:
+ application/cmdbabstract.class.inc
+ core/bulkchange.class.inc
+ core/dbobject.class
+ core/deletionplan.class.inc
Thanks for the report (please, leave the milestone empty so that we can discuss the point during our bug review, otherwise it may be forgotten for a while)
Reported in the duplicate ticket #907 (now closed)
Fix committed as revision [3144] in trunk.
De-harcoded set_time_limit(5) (per loop) in lengthy operations.
The default value is now 30 seconds (per loop), instead of 5 previously, configurable via the new parameter 'max_execution_time_per_loop'.
This parameter really specifies how much time is allowed for 1 run inside the loop to complete. During "bulk" operation (bulk modify, bulk delete, CSV import...): 1 run in the loop corresponds roughly to the processing of one DBObject.
The timer is restarted each time we call set_time_limit (according to PHP documentation), so 30s per object seem quite large here but...
... the behavior of set_time_limit() is slightly different between Linux and Windows: on windows the time allowed for the script to run counts everything (it's really a the duration: end - start) whereas on Linux set_time_limit only applies to the time spent inside the PHP script (so MySQL ans sytem calls count for zero).