Please Note This forum exists for community support for the Mango product family and the Radix IoT Platform. Although Radix IoT employees participate in this forum from time to time, there is no guarantee of a response to anything posted here, nor can Radix IoT, LLC guarantee the accuracy of any information expressed or conveyed. Specific project questions from customers with active support contracts are asked to send requests to support@radixiot.com.
Are there Point Link (pointLink) tutorials, or examples?
-
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 startand 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 RunningThoughts? 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.
