TL;DR If you make an excel template, limit your named ranges to as small as possible
Alrighty, so after a few more days of troubleshooting, @phildunlap took a look at my excel template. He determined that the named range I designated in Excel was too long (only by a million cells!) for EACH named range, of which there are about 50. So, the theory was that the POI Apache plugin that allows Mango to interact with Excel was loading these empty cells into memory somehow, and was sporadically causing a memory leak or memory usage at least until the point where it would cripple the amount of available memory to the JVM to VERY VERY low, and render the garbage collection useless. Thats a mouthful.
And so, the problem only reared its ugly head once in awhile, it was hard to track down, but I've been operating for about a week now with no "crippling" memory issue, and I've launched thousands of reports without issue. For anyone who wants to know, the final template filled in is 82kb, has charts and 5 sheets of data, the time range spans 14 months and there are multiple different time ranges used and approximately 10-15 data points queried.
It is expected. Ideal or not, who can say. But, originally there was 'no change' to facilitate this kind of point, and it would do what you described. But, it also generated a 'point updated' event every poll period. So, in comes the non-polling virtual data source, which never schedules itself to do any work, it just sits there.
I could understand using the start value even still in this situation: it does seem implied. But, it's just as easy to initialize them elsewhere.
Sory for my English language. I want to build my page. May be include graphic, gauges or anything for my design. And one I want include datasource table and chart function same example below picture into my page too. Can you recommend me?😅
No worries. I would use the word "watchlist" for what you posted, and the chart would then be a "watchlist chart". That's what it will be called in the API docs
Glad to hear it! It should work in any script set point event handler, but you may need to give the handler sufficient script permissions (add 'superadmin' to the script permissions fields on the event handler) and ensure the event is raised.
Thank you for your advice. I got this working last week, but as you indicate, it requires tree structures in Mango 2.8.8:
one metadata point used for creating a context change from user input
one metadata point to detect the context change then execute the script
one scripting datasource to set multiple points each time the context of the first point changes
I'm glad to hear this has been simplified in Mango 3.x.
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.
Did you add a user? If you're editing using crontab -e, you may be running them as the mango user and may have various file permission issues to tackle. If you place them with a user specified in the /etc/cron.d directory you may have more luck.
The second item, com.serotonin.m2m2.Common.databaseProxy.newPointValueDao()
is actually a specific call into the Java code. The com.serotonin.m2m2 is the package path to the class Common, which has member variable databaseProxy. The returned object is still a native Java object. There isn't documentation for this because it simply wouldn't be feasible. The code is open source, it's about the best we can do for direct references to the Java code.