The later versions, post 8.1.1, look to have major issues wit tag() and runscript(). I have done away with tag() references, and all but one runscript() reference. What are my options for using runsciprt() for system.alarm.queryStatus on a 1 second update? I was thinking of dropping a timer, but figured someone might have a better way.
Don’t use runScript() for anything that takes more than a tiny fraction of a second. (If using Vision, that means anything that calls out to the gateway). Anything longer should be run in a gateway timer event and delivered by tag or message, or in Vision, run in an asynchronous thread with results delivered with invokeLater.
Yes, you can get away with breaking this general run in small, simple applications. Don’t do it.
1 Like
I used runscript for:
- system.tag.exists
- system.alarm.queryStatus
For #1 those were easy enough to fix, just place in a window open script, they only ran once anyways.
For #2, this needs to update on a regular basis. These are dynamic popups so gateway timers are not an option. So what would you recommend for that?
Is this Vision or Perspective?
Vision
Then use a client timer event to start an asynchronous thread, and report the results to a client tag.
Yeah, I’m obviously not explaining myself well. I’ll throw a timer on the window for now.
A timer’s actionPerformed event runs on the GUI thread, too. If you go this route (nothing wrong with a timer component instead of a timer event), you still need to make the call to queryAlarmStatus from a background thread. The timer component can launch one with invokeAsynchronous.
The problem isn’t that runScript itself is a problem, but that calling slow functions from the GUI thread is a problem. And runScript uses the GUI thread.
Yes it is! There is a bug introduced sometime after 8.1.1, I have been through this with IA.
Do you have the ticket number? I can’t find an existing ticket that seems remotely similar. Thanks!
No. I asked several times for it. Aaron Palas is the one working on it. He did respond today stating he isn’t able to replicate on his end. I gave him a project to work with and did a remote session so he could see for himself.
It’s very easy for me to replicate. I had a well working project in 8.1.1. Upgrade to 8.1.2/3/4, and popups are insanely slow to open, about 3-4 seconds longer. Once I removed all runscript(), they were basically back to normal, maybe a bit faster.
Whatever the problem turns out to be it isn’t going to be runScript itself, rather it’s going to be whatever you’re executing inside the runScript that is behaving differently.
1 Like
Perhaps, but the same code running from the runscript is still executing, just in other ways, window event or timer event for the instance that needs to run continuously. So based on that, it’s hard to agree with you. Like I said, I’ve given the project to support to look at it. Works fine in 8.1.1, later versions it doesn’t. Whatever the problem, it doesn’t matter to me, I just would like to figure out what the problem is.
I left a note on the ticket for the support rep suggesting this but I’ll tell you directly as well: it might be interesting to set the logger “alarm.StateModel.Query” to DEBUG level and then open the slow windows/popups and check the gateway logs to see what alarm status queries are being executed and how long they’re taking. Comparing these logs between 8.1.1 and 8.1.2 may show something interesting.
I’m focused on alarm status queries because a number of your thread dumps from 8.1.2 clearly show alarm status queries invoked from runScript on the UI thread. I don’t know how this wasn’t already an issue for you regardless of what version you were on. I can only guess the queries are now returning slower for some reason.
Thank you for digging into this and for the tips.