The LMI appliance may be unable to finish executing a parsed report query because the query is returning too many results and is subsequently causing MySQL to require caching the results to disk which slows down the query and causes it to exceed the default timeout period. In other circumstances there may just be too many parsed reports scheduled to execute simultaneously or in combination with other activity on the appliance which causes them to slow each other down to the point of exceeding the timeout period.

If there are multiple parsed reports scheduled simultaneously the first solution should be to reschedule them to spread out their execution. In the other situations, or if rescheduling them doesn't completely resolve the issue, it may be required to adjust the timeout value. You'll see the following event logged to /var/log/sys.log when the query is being killed because it is exceeding the timeout value:

<14>May 31 16:14:00 logapp MGMT: %LOGLOGIC-6 module:engine_lx_scheduler(21523);  file:sql_wrappers.c(check_register_db_thread,377);  action:db_thread: kill; threadid:75; type:unregistered; reason:idle_too_long; idle:913, query:  ;

The Idle: 913 refers to the amount of time, in seconds, it was idle. The default timeout is 900 seconds, or 15 minutes.

Scheduled parsed reports may timeout when executed. The default is 15 minutes. This article shows how to extend the timeout and provides an example log to help confirm whether a timeout is the cause for why the reports are not running to completion.

This article describes how to extend the timeout period for all parsed reports.

1. SSH to the appliance and log in as ”toor”.

2.  Run these commands:

$ mysql logappconfig -e 'update Settings set maxIdleDBQuery=7200;'
$ /loglogic/bin/loadsettings

The 7200 value dictates the timeout period in seconds that you wish to set. The loadsettings command (it returns immediately to the shell prompt and with no output despite executing successfully) is required in order to have the setting take effect by forcing the various LMI components that rely on the setting to re-read the value from the database and load it into LMI's shared memory.

The exact value to use that can satisfy all situations is unable to be given in this article. Some reports may only need an additional 5 minutes while others may need many hours. It is advisable to set a value and re-execute the report to see if it can completely successfully. If the same issue occurs then raise the value again. One method for doing this is to double the value each time. Another method is to try a large value, such as 10,800 (3 hours), then reduce it as needed. The key is to not use such a large value that allows improperly configured reports to run for as long as they need because this can cause LMI resources to be consumed for many hours or days. If you need assistance with configuring an accurate value then do not hesitate to contact TIBCO Support.