Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi,
(Using TOS Data Integration 7.4.1, and logging to a database.)
In the code snippet below, the component SERV_DATA contacts a server and has a rather long execution time. Therefore the whole subjob takes between 20 and 40 minutes to complete, depending on the network and other variables. When this execution time is low (typically under 30 minutes), the CHECK_API tWarn successfully writes in the log, and the Job completes as well as the application. On the other hand, when the subjob's execution time is high, then CHECK_API component is unable to write in the logs due to a connection timeout, and the whole application crashes !
I already considered solutions such as breaking the application just before the CHECK_API component, but I would like to know if there is no cleaner way to tackle the issue.
If I understand well, a single connection is opened to the log database, and all twarn use that connection. If so, is this feature configured somewhere ? Can I ask for tWarns to open each their own connection ? Or is it possible to ask them for a re-connection whenever the connection has been severed ? Also, a complete explosion of the whole application seems pretty drastic to me. Is this configurable to ?
Thanks for you help
Hello
tWarn component is used to trigger a warning message often caught by the tLogCatcher component for exhaustive log. In your case, tWarn(CHECK_API) is linked by a connector 'OnSubJobOK', means this component only works when the previous subjob is executed successfully. If a connection timeout occurs, tWarn(CHECK_API) will not be triggered.
To retry a DB connection, you can refer to this topic.
Regards
Shong
Hi Shong, and thank you for your answer (didn't see it earlier, hence my response time).
In my case the tWarn(CHECK_API) is *always* triggered, the problem is that it sometimes crashes. I have the feeling the crashes occur when the execution time of the SERV_DATA component is high (>30 minutes).
Our application doesn't use tLogCatcher components, instead it relies on the "Stats & Log" properties defined for the project (see image below).
Actually I didn't know the tLogCatcher component, and it might indeed provide a solution to my problem, so many thanks for mentioning it.