[IGN-3831]Running Scripts Blank Description

[deon.korb]

Hi,

I have many running scripts that come and go and I would like to track them down. I have searched for every instance of system.util.invokeAsync and have given the calls descriptions, but I still have these appear:

None of these scripts stay running, but I would like to trace their origin to reduce the number of times they are invoked and their impact, if practical. They are also almost certainly originating from a tag or Perspective change script.

Is there anything other that system.util.invokeAsync that could spawn a thread like this? I just don’t know where to search next to reduce the load caused by these.

Thanks,
Deon

[deon.korb]

Is it possible that Perspective script transforms create threads without descriptions?

[pturmel]

Consider taking a thread dump and looking at those threads’ stack traces. It should at least identify the subsystem involved.

[PGriffith]

@deon.korb

Is it possible that Perspective script transforms create threads without descriptions?

Yes.

Currently, Perspective works with an unbound, caching thread pool. If you end up with many sessions or scripts running concurrently, you could quickly create a lot of threads, which will exist for a certain TTL then terminate.
We have a feature request to allow you to contribute description information when creating script transforms to make situations like this easier to diagnose.

[deon.korb]

The culprit was a lot of frequent system.alarm.queryStatus calls in a Perspective script transform.

[PGriffith]

Just curious - what are you using queryStatus for in a transform?

If you can refactor to plain alarm status tables, there’s a significant optimization that’s landing in 8.1.12, where any tables querying at the same time will automatically reuse from a cache, instead of pulling their own data per session.

[deon.korb]

I was testing this:

[IGN-4921]Alarm Aggregation/Summary

Hi, I would like to know what the best way is to get a summary of the alarms on a UDT. What I need is the highest priority active alarm (for a colour around the UDT symbol) and if there are any unacknowledged alarms (to blink). I need to do this for about 50 UDTs on a page with about 100 clients active. I see the following options: Use an expression tag on the UDT that monitors all configured alarms and presents a summary integer (priority code and negative if unacked). Similar to below: if…

Turns out my original strategy of an expression tag on the UDT is so far the lightest on the Gateway.

I'm still looking for the best way

[rbachman]

You mentioned that we can contribute description information; how exactly do we do that? We have a need for this in a few cases.

[PGriffith]

We have a feature request for that capability. We don’t currently have that capability.

[nminchin]

Fwiw, I use tags as well. I have two udts, one which has one instance only which has a tag that calls queryStatus at a regular interval 2s to get all alarms and write the info into a library variable. The other udt is instantiated anywhere you want a folder summary and has tags in it that process the library variable and summarise them, like active unack, priorities, etc