Using runScript, any effects on Heap Memory

I have some alarm indicator templates in which I am using runScript functions to display if a particular alarm group has unacked, acked, or cleared alarms. I am running these every 2 seconds. My question is, I know this could potentially cause a client to become unresponsive but does it have implications for drastic heap size increase? Does it in anyway strain the gateway resources? I found another article in which someone suggested doing away with these and moving them to timer gateway scripts. Any thoughts?

Thanks,

Frank

Are you doing these in a tag or on the template? If its on a template, I may be forgetting about something, but I’m not sure how your running them every 2 seconds. Bindings refresh at your client poll rate which I believe is defaulted to 250mS.

Even using the expression alarm functions I’ve personally had bad experiences with running from bindings. Even when the screen worked great locally, it would cause the screen to crash when accessed over VPN.

As far as straining the gateway resources there are a lot of factors that would play into it. If the client locks up, I wouldn’t expect it to strain the gateway, I would assume it wouldn’t be able to send requests while locked up. That may or may not be the case though. Your alarm requests though, even if they are called from the client will run on the gateway. It would need to query the internal database to get the information your requesting.

Personally I wouldn’t use the runScript function, I would do a gateway timer script and write to memory tags that your templates reference. I would also do some testing to see how the timing impacts the performance of your gateway. You said you have it running every 2 seconds right now but do you need it in 2 second intervals or would 5 or 10 seconds work. The other question is will the script complete in 2 seconds. I would look at all of that to make sure you don’t negatively impact your performance.

Don’t do this. Anything called in runScript() is on the foreground (GUI) thread, which blocks the user interface if it takes more than a few milliseconds. Use a timer event (gateway for global stuff, client for client-specific filtering) to call “expensive” functions like this, or an asynchronous thread.

Um, no. Bindings in a client evaluate when anything they reference changes. For tags, that is no faster than 250ms, by default, but other bindings can re-execute much faster. Especially if there are cycles (circular references).

If you’re looking to monitor alarms through an expression, I’d suggest isAlarmActive() or isAlarmActiveFiltered(). Not sure if they’ll work for your implementation, especially if it’s complex or heavy, but I’d at least give them a look.

For most bindings I agree but with binding a runScript or one of the alarm functions won’t it poll at the 250ms rate? I know I was bit by using the isAlarmActive() and isAlarmActiveFiltered() expression functions on templates in a template repeater. It worked great locally but crashed the client when accessed over VPN. Support told me it was because it queried at a 250ms rate looking for new alarms but was slowed by the VPN connection causing it to not get a response before it fired again.

It wouldn’t fire again while the first one was still going, but it could very well fire again immediately after it finishes evaluating, effectively freezing your UI permanently.

Thank you for the explaination, freezing the UI permanently is exactly what it did. It was a missunderstanding on my part for what happened. The end effect was the same though, I moved the expressions to tags so I could slow the rate it ran at.

No. runScript() polls at the rate you tell it in its poll argument, plus any re-executions caused by any arguments changing. The runScript function has no insight into what exactly is running in python. But whatever it runs, runs in the GUI thread.

Support misdiagnosed it. The VPN increased the round-trip time of the gateway calls, which froze your GUI because the foreground thread was waiting on every gateway call.

Don’t do anything in runScript() that requires calling outside of the client. Period.