My recursive script and clock drifts

I made an silly script that looped back into itself, like thoudsands of times over, before I was able to disable it. It was a session property binding that ended up looping back into itself after performing a SQL query. When I opened up the Running Scripts, there was like 4 pages of running scripts, some going on for minutes. As for performance, lots of clock drift, CPU at 90%, memory up the wazoo, you have it.

As for the recursion, no biggie, I mean, it’s happened to me before. Not ideal, but I know what I did. Who hasn’t ever made an infinity loop before? At least I located exactly in the logs when the ‘Flood Limit Tripped’ for the component, but too bad ‘the trip’ didn’t actually stop the loop.

]

So my recursion story leads me to here: after restarting the gateway a couple of times (first red circle is when loop was created, second red circle is when I was able to disable script, third red circle was second gateway restart to try and eliminate clock drift):
image
image

So after my second shutdown, now memory is looking good, CPU very happy:

But I’m seeing a bunch of clock drift errors in my logs, from about 1x every minute to sometimes even faster.

The performance of the system is fine. The logs are giving no hints of any problem. The client is running smooth.

It really seems like to me that the problem I created with my recursive loop has somehow made a lasting impact on the system clock monitoring. When I look at the logs, its like night and day different, there were no drifts, then I did my loop, and now there are drifts:

Any ideas?

Update:
My clock drifts were fixed once I closed the tab that had the gateway threads on it. Weird that that can cause a clock drift but you don’t see any performance degradation.

Lesson to all - don’t keep the thread diagnostics opened or you will see clock drift errors in the logs.

Even better lesson - don’t create recursive loop in the first place. /solved

1 Like