Hei,
I’ve written a script that generates a menu of sort using the Tree component reading data from an MSSQL database. I’ve managed to get it to work by itself, but the moment I put where I want to use it the gateway goes nuts. Clock drift detector warnings start triggering and memory usage spikes over 90%, the only way to get out of it, is to stop the gateway and restart it.
The setup I have is as follows:
- Tree has a structure that has multiple levels, i.e. Gateway/Group/Device/Sensor in the same way MQTT is used.
- User selects one sensor and parameters are passed to an embedded view, the embedded view loads values by using indirect tags based on the path from the Tree.
The Tree by itself works fine, but when I try placing the script that creates the tree dynamically it seems to break the bindings between the Tree and the Embedded view, Gateway goes crazy and I need to stop and restart. I managed to return to my previous setup, but I have the feeling that there some underlying problem when the tree is generated on view loading which breaks the bindings, can’t set them up again and it goes into a memory leak loop of some sort.
Is this a bug? or am I doing something wrong?
Ok, small follow-up.
I’ve managed to fix this problem using the info in this thread: [Question] Null values causing errors in Perspective
I just added a validation Script (it can check for “None”), Expressions worked, but it still gave off a warning, albeit not crashing the gateway.
The problem was caused by the lack of selection in the Tree. Since the “selection” and “selectionData” properties on the Tree are dynamic (and therefore empty if nothing is selected) it caused problems on the binding.
These problems/warnings on the binding are to be expected, but they shouldn’t crash the gateway, so, maybe a bug?
It sounds like you have a recursive binding or script in there causing an out of memory condition or cpu race.
Maybe?
I have a Tree that is filled from a DB query, the tree selection passes the parameters to the embedded view, that is, the embedded view parameters have a binding to the Tree selectedData prop. That selected Data provides the parameters for the Indirect Tags of the embedded view to get the values I want to display. I’m using this kind of setup in all of my project, but it only goes into this “cpu race” in the case of the tree losing any sort of selection and not having a failsafe value.
I mean, at most, the problem I see from the tag side is not having a proper tag path, which as far as I’m aware doesn’t cause anything besides a warning. As for the bindings/script, I can’t think of any instance in this project that I would categorize as recursive, as far as I know all I’ve done is pretty basic perspective stuff as it’s meant to be done.
Also, I’ve tried duplicating this with a similar view but without and embedded view and the problem is not triggering. So, I’m guessing its a combination of the tree and the embedded view? Not sure, I’ll see if I can duplicate it some other way, even though it’s fixed for I don’t want this to come back and haunt me.
Recursion can be non-explicit. Assigning to a component property in a script will trigger its propertyChange event at that point, nesting the two scripts. If the latter script, or a further nested script causes the original script to trigger, you have recursion. Even though there’s no apparent classically recursive code. A similar connection between scripts can also occur when a script action causes a component to re-compute itself, with property and binding updates as side effects. Your symptoms strongly suggest something along these lines.
I’ve found that temporarily adding logging to the head of every component event script in a window helps identify the implicit looping. (For propertyChange scripts, place the logging inside the if-block for each property name.)
That may be the case, but I don’t have that many scripts in that page, and I’ve tried duplicating the error in another view under the same circumstances. I’ve added logging to the few scripts there and those are not the one causing the problems. I’m inclined to think both of you are right and there is some sort of recursion, but I’m not sure it’s coming from scripts. I’ll keep looking and posts something again if I find the issue.
Ok, I think I found the problem.
I have a label component I made with multiple custom props that shows a value but changes the format depending on other values an calculations. That is:
- I get the upper and lower limits from indirect tags as customs props
- I change the number shown if the value is not setup, this device in particular returns -32768 when not configured, so I change the value to 0
- Based on all these values I had an expression that changed the prop.style.classes property and changed the label to be red if bad, orange if warning, green if ok,grey if not configured, with the additional variable of which limits were setup (i.e. only the high high limit, or both low low and high high limits).
Using an expression that changed the style property the solution worked when the indirect path for all tags was correct, but when the tag path was broken, or had a null value at any point (such as when you reload a “tree” and have no selectedData it started causing this warning repeatedly:
“Flood limit tripped, starting 5000ms cooldown.”
Which eventually led to clock drifts and a cpu race.
The weird thing is, that if I change the style property with a script, and not an expression the error doesn’t happen and I don’t get a cpu race.
Any idea what’s going on here?
EDIT: After writing this I added 2 more labels with a script instead of only 1, it didn’t cause a flood limit trip, but it did cause some clock drifts, but the load was temporary and it recovered by itself as opposed to going crazy and needing a gateway restart.