Hello All,
We have a case of expected RTEs reliably occurring at the same time of day (4 hour window) for a specific protocol. We have confirmed there is no clear way to solve the root of the issue generating the RTEs and we have also confirmed the RTEs are not negatively impacting the performance of the system.
With that said, is there a way that we can have DataMiner ignore specific RTEs for a specific Protocol and at a specific time of day, ultimately keeping the RTEs from generating in the first place?
Or is there a way to increase the default 15min RTE threshold for specific cases?
Thank you,
Thomas
Hi Thomas,
As far as I know it is not possible to change the default 15 min RTE threshold.
There is a new feature coming in 10.3.0(CU13)/10.4.4 that avoids RTE SLProtocol when the connection with a device is slow. You could double check if this feature can solve your issue.
Reference: RN38858
Hope it helps.
Thank you for the information Miguel and Jan.
Hi Thomas,
I’m not sure if you’ve already tried it, but if the problem is caused by a long-running qaction, this can typically be solved by using the ‘queued’ option.
When this option is activated the QAction will run on a separate thread, in parallel with other QActions. This QAction can run longer than 15 minutes without generating an RTE. This should be used with care, and the necessary protections need to be added regarding locking and making sure the action doesn’t run forever.
For more information see: https://docs.dataminer.services/develop/schemadoc/Protocol/Protocol.QActions.QAction-options.html?#queued
Hi Tom, Thank you for the information. We’ll check if this can be used in our case.
That’s correct Miguel! This change is expected to be available on April 19th and will also be part of 10.4 CU1.
More information is available in the RN on docs:
https://docs.dataminer.services/release-notes/General/General_Main_Release_10.4/General_Main_Release_10.4.0_CU1.html#problem-with-slprotocol-when-it-took-longer-than-15-minutes-to-execute-a-poll-group-id_38858