Hello! Did you solve the problem? We have the same problem here. However, some data is stored in the database. This makes it very difficult for us to estimate when processing was actually canceled and when partial or complete processing took place.

I hope to hear from you!

greeting
Tobias Gumpert

Hi

We also having same issue when scheduling a report delivery. Anyone found the root cause or solution? 

Hi

Me too. Any ideas?

I am having this issue from a print job as well.  Any suggestions on how to resolve?

Hi @STMVALENTINE 

Application reconfiguration is good option. Despite this I still have no idea what is the root of cause.

Yeah, the reconfiguration has been done many times.  This issue still remains.

Hi, 

I have the same issue with reports. Has anyone found the root cause on this one?

The reason behind this issue is, the related functional flow takes more than 600 seconds to complete its work. By default, the timeout value for a STUCK thread has been set as 600 seconds in Weblogic. Therefore, if a process takes more than 600 seconds to complete, it is considered as a STUCK thread as per the design of the application. But, even though if you get a STUCK thread for a application message, that does not mean it is a permanent one which is a final blocking thread. This STUCK thread will be released once the process is completed. In this scenario the STUCK thread will be released after the work manager completes the functional flow in the background.

The Fix
----------
* Increase the timeout value of the related BizApi call. The timeout setting can be set specifically to a relevant BizApi call. Therefore, please increase the current value at least up to 15minutes (900 seconds). After changing the timeout value, we can check if it causes to reduce the number of failed Application messages.

This change will allow the related Application messages (relevant for the specific BizApi call), to decide if the status should be changed after 15 minutes (Previously it was 10 minutes, After 10 minutes, if the process is not completed the application message changes its status as "Failed" with that "STUCk Thread" error message).

. This can be done by changing the "ifs.properties" file reside in "ifs home/instance//conf/ifs.properties".

You have to add the following line; ifs.bizapiTimeout.ExcelQuickReport.RenderExcelDocument = The value of the has to be an integer representing the number of seconds (A value greater than 600(10 mins) in this situation).

After doing this change please restart the application server. 

Hi,

We have the same problem. We've added the line “ifs.bizapiTimeout.ExcelQuickReport.RenderExcelDocument =  1800” to the ifs.properties file and restarted the application server, but the error persists and is triggered after 10 minutes.
Is there a particular place in the ifs.properties file where to add the line?
An action other than restarting the application server ?

Thank you in advance and best regards

We also having the same issue for BizAPI calls. We did the change ifs.bizapiTimeout.ExcelQuickReport.RenderExcelDocument=1800 like suggested. But, we are still having the issue. Anybody having solution for this?

Hi,

This issue is occurred due to the execution time is taking long  than defined time out time.
Normally the default time out time is set up to 10 minutes (600 seconds )in IFS standard.

 

Solution 1:  need to find the time cost code/cursor and optimize it .

if not

Solution 2:

Go to the Setup IFS connect Window .

Add new entry in BIZAPI_WORK_TIMEOUTS
   Enter the relevant BizApi connected in related  routing address/rule and define a new  timeout time based on the time taking to process.
   And make sure to restart the integration server after saving the change.

 Time taken to process this can be vary based on the data amounts/ conditions inside the logic.
Eg:

 

Thanks and Best Regards,
Chathuri

 

@Chathuri Senanayake , How can I find the BizApi to add to the timeouts? The drop down did not list anything for render excel or quick reports?

Any idea?

Thank you,