Are there Point Link (pointLink) tutorials, or examples?
-
And FWIW, this is running core 2.8.8 build 635, pointLinks 1.6.0
-
Hmm. That rejected task would probably be an interval logging task for a data point, but that would still enable the cache to have the result of the point link set.
The NullPointerException may have been escaping to stderr, I can't recall, or if it was logged as an uncaught task exception. If you point link doesn't set the annotation this could very likely cause it. target.set() wouldn't be an option in 2.8.8
You also checked your events and didn't have any cause?
"Disabled" isn't checked on your point link, is it?
-
I do have it set to write annotation (and I have toggled it on & off several times in attempts to debug). Now that I think about it, I never see any annotations (except for manual set values), as expected given the behavior.
"Disabled" is not set (I wish it was a simple idiot mistake like that), although I have toggled it in attempts to debug.
-
I have tested the version you are on, it works as I expect (and is not affected by the annotation issue I believe, or that's only if you've got a websocket open to the target point perhaps).
Here is my configuration:
{ "dataSources":[ { "xid":"DS_808993", "name":"PL_TEST", "enabled":true, "type":"VIRTUAL", "alarmLevels":{ "POLL_ABORTED":"URGENT" }, "purgeType":"YEARS", "updatePeriodType":"MINUTES", "updatePeriods":1, "editPermission":"", "purgeOverride":false, "purgePeriod":1 } ], "dataPoints":[ { "xid":"DP_479771", "name":"Source", "enabled":true, "loggingType":"INTERVAL", "intervalLoggingPeriodType":"MINUTES", "intervalLoggingType":"AVERAGE", "purgeType":"YEARS", "pointLocator":{ "dataType":"NUMERIC", "changeType":{ "type":"NO_CHANGE", "startValue":"50" }, "settable":true }, "eventDetectors":[ ], "plotType":"SPLINE", "unit":"", "templateXid":"Numeric_Default", "chartColour":"black", "chartRenderer":{ "type":"IMAGE", "timePeriodType":"DAYS", "numberOfPeriods":1 }, "dataSourceXid":"DS_808993", "defaultCacheSize":1, "deviceName":"PL_TEST", "discardExtremeValues":false, "discardHighLimit":1.7976931348623157E308, "discardLowLimit":-1.7976931348623157E308, "intervalLoggingPeriod":1, "intervalLoggingSampleWindowSize":0, "overrideIntervalLoggingSamples":false, "purgeOverride":false, "purgePeriod":1, "readPermission":"", "setPermission":"", "textRenderer":{ "type":"ANALOG", "useUnitAsSuffix":true, "unit":"", "renderedUnit":"", "format":"0.00" }, "tolerance":0.0 }, { "xid":"DP_393152", "name":"Target", "enabled":true, "loggingType":"INTERVAL", "intervalLoggingPeriodType":"MINUTES", "intervalLoggingType":"AVERAGE", "purgeType":"YEARS", "pointLocator":{ "dataType":"NUMERIC", "changeType":{ "type":"NO_CHANGE", "startValue":"10" }, "settable":true }, "eventDetectors":[ ], "plotType":"SPLINE", "unit":"", "templateXid":"Numeric_Default", "chartColour":"black", "chartRenderer":{ "type":"IMAGE", "timePeriodType":"DAYS", "numberOfPeriods":1 }, "dataSourceXid":"DS_808993", "defaultCacheSize":1, "deviceName":"PL_TEST", "discardExtremeValues":false, "discardHighLimit":1.7976931348623157E308, "discardLowLimit":-1.7976931348623157E308, "intervalLoggingPeriod":1, "intervalLoggingSampleWindowSize":0, "overrideIntervalLoggingSamples":false, "purgeOverride":false, "purgePeriod":1, "readPermission":"", "setPermission":"", "textRenderer":{ "type":"ANALOG", "useUnitAsSuffix":true, "unit":"", "renderedUnit":"", "format":"0.00" }, "tolerance":0.0 } ], "pointLinks":[ { "xid":"PL_112332", "sourcePointId":"DP_479771", "targetPointId":"DP_393152", "event":"CHANGE", "logLevel":"NONE", "disabled":false, "script":"return source.value", "scriptPermissions":{ "customPermissions":"", "dataPointReadPermissions":"superadmin", "dataPointSetPermissions":"superadmin", "dataSourcePermissions":"superadmin" }, "writeAnnotation":true } ], "watchLists":[ { "xid":"WL_908992", "name":"(unnamed)", "user":"admin", "dataPoints":[ "DP_479771", "DP_393152" ], "data":null, "editPermission":null, "folderIds":null, "params":null, "query":null, "readPermission":null, "type":"static" } ] }
Is it possible that you've pointed the link at a point that doesn't support setting, or that its device is failing the set so the value doesn't change?
-
The target is a virtual data point (user input) so no device to fail. And I did check the "Settable" parameter. Several times. ;-)
My configuration is essentially identical to what you shared.
As I mentioned, it was working once upon a time, so it's extremely puzzling where the problem could be arising.
-
Is it possible that you're not using the latest NoSQL module? I guess if you had an older version and a lock had gotten stuck on that point in the database that would cause something like what you're seeing. You shouldn't be able to set any values to that target point via any means in that condition, though: none would make it into the database. If it were the NoSQL module, though, I would still expect a modbus device, say, to send the set command out.
-
No, this is not using NoSQL.
And again, the target point is a Virtual Point (user input)
-
And you don't have obvious messages about Timer Cancelled, or running out of memory, or anything like that?
And you've tried restarting the instance?
I am certain the example I posted works, and I was using the version you're using.
-
Correct, no “Timer Cancelled” messages, no running out of memory (since I added swap) or any other messages at this point.
I do occasionally get this error message:
WARN 2017-10-20 14:11:12,771 (com.serotonin.m2m2.rt.dataSource.PollingDataSource.incrementUnsuccessfulPolls:107) - Data Source GCI Input aborted 28 polls since it started.
And yes, I have restarted the instance. Several times. ;-)
-
Hmm, that's a real puzzler!
I have no context for what that data source is, so its having aborted polls is probably irrelevant. You say the source point is updating.
If the point link ran, and an error occurred in the SetPointWorkItem, it would have been logged. You could check your SQL logs if you haven't.
Is your instance bogged down, and perhaps every time you expect the point link to fire you see the number of medium priority work items increase, and that isn't decreasing, perhaps they are not executing.
You can launch your instance with
./ma.sh start
and if anything were escaping to stderr you would see it.You can launch Mango on a fresh database and try to replicate.
You can post or email JSON you think would replicate it and I'll try.
-
We're preparing to upgrade that server to 3.2, so I'm putting off any further attempts until then. At that point, I'll try your suggestions (if the problem persists), and report back to you.
For what it's worth, we attempted creating an event handler to accomplish the same effect, but the result was the same.
We are able to change the value manually (user input) but having difficulty with any programmatic changes.
We'll update you on Monday. Have a great weekend.
Aldo
-
Just noticed this interesting message in the logs, when shutting down:
INFO 2017-10-25 13:50:32,882 (com.serotonin.m2m2.rt.maint.BackgroundProcessing.joinTermination:363) - BackgroundProcessing waiting 5 more seconds for 3 active and 1300637 queued medium priority tasks to complete. INFO 2017-10-25 13:50:36,927 (com.serotonin.m2m2.rt.maint.BackgroundProcessing.joinTermination:375) - 1300637 medium priority tasks forcefully terminated.
That does not sound normal, and it would explain the error we were already seeing:
FATAL 2017-10-24 13:40:41,368 (com.serotonin.m2m2.util.timeout.RejectedHighPriorityTaskEventGenerator.rejected:47) - High priority task: com.serotonin.m2m2.rt.dataImage.DataPointRT rejected because Task Currently Running
Thoughts? What would cause this?
P.S. I imported a backup of the settings from a few weeks ago, when it was working; no change
-
@phildunlap said in Are there Point Link (pointLink) tutorials, or examples?:
Is your instance bogged down, and perhaps every time you expect the point link to fire you see the number of medium priority work items increase, and that isn't decreasing, perhaps they are not executing.
-
There really shouldn't be any significant load; it's just receiving on a Persistent TCP Data Source, waiting for user input on a Virtual Data Source, and the previously mentioned point links.
-
How big are your events and pointValues tables?
The NoSQL module is much, much more efficient than using the SQL table.
-
They were big enough that I canceled "SELECT COUNT(*)" queries because I ran out of patience waiting for results. We had been logging all data (then interval) in an effort to force charts to draw points (binary points, would be ON for hours/days before being OFF for 5 seconds at a time).
I truncated the tables, restarted Mango, and now it's behaving as expected.
The troubling symptom is that it seemed the number of queued tasks was never decreasing. Yes, the table is filling up, but even just an SQL insert should eventually catch up (one would think). Hopefully once we migrate to 3.2 and NoSQL this becomes a non-issue, but it is a surprise to find this to be a bottleneck.
One critical piece of information: this is running on an AWS server, with an Aurora RDS backend. Have you come across any issues with Aurora?
Finally, since this was a side-effect of attempting to force logging to create better charts for data that remains unchanged for a long time, do you have any recommendations to accomplish the desired results?
Aldo
P.S. I have emailed separately regarding licenses; awaiting reply.
-
If the inserts are generated faster than they are processed, they would certainly not finish the queue. The SQL point values table hasn't been performance tested in quite some time. The NoSQL backend is so much faster it isn't really worth it. Our licensing in version 3 is such that only free licenses don't have an unrestricted NoSQL license. If using SQL you really need to keep that table small.
I've not had issues with Aurora. I'm not sure that was the AWS RDS I've used by name but I've not had issues with the Amazon RDS in general.
Using NoSQL would have behaved fine in the situation you describe to store data sufficient to charting it that way. Rollups should chart even if the value was log on change.