curious for 7800 points how often are they read from the datasources, how often are they logged to disk, and how much RAM are you allowing for the JVM on the 6 core CPU?

maybe a limit could be implemented so if "select all" was clicked it would only select up to 30.

Hi Phil, no failed network requests and no errors in the firebug console, it is on version 3.6.4. Guess it is a web browser thing

firefox 68, or more exactly: userAgent=Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Hi,

When I try to save a plot from a watchlist the jpg,png,pdf exports are all blank white space. The PDF has an URL at the top. The xlsx export does provide data, and there is data in the plot.

looks like this exception in the log occurs:

WARN  2019-10-07T09:42:16,831 (com.infiniteautomation.mango.rest.v2.ServerRestV2Controller.postClientError:319) - Client error
[user=admin, cause=Possibly unhandled rejection: {}, location=http://192.168.172.11:8080/ui/administration/system-status/logging-console, userAgent=Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0, language=en-US, date=2019-10-07T09:42:35.800-07:00, timezone=Africa/Abidjan]
TypeError: this.activeEvents is undefined
	at subscribeToEvents/< (http://192.168.172.11:8080/ui/mangoUi~ngMango~ngMangoServices.js?v=f41ab677f738e8ffe5b8:72:97514)
	at u/</< (http://192.168.172.11:8080/ui/mangoUi~ngMango~ngMangoServices.js?v=f41ab677f738e8ffe5b8:78:94777)
	at u/< (http://192.168.172.11:8080/ui/mangoUi~ngMango~ngMangoServices.js?v=f41ab677f738e8ffe5b8:78:94915)
	at $digest (http://192.168.172.11:8080/ui/mangoUi~ngMango~ngMangoServices.js?v=f41ab677f738e8ffe5b8:78:100341)
	at $apply (http://192.168.172.11:8080/ui/mangoUi~ngMango~ngMangoServices.js?v=f41ab677f738e8ffe5b8:78:102518)
	at $applyAsync/r< (http://192.168.172.11:8080/ui/mangoUi~ngMango~ngMangoServices.js?v=f41ab677f738e8ffe5b8:78:102663)
	at Qr/this.$get</</this.completeTask (http://192.168.172.11:8080/ui/mangoUi~ngMango~ngMangoServices.js?v=f41ab677f738e8ffe5b8:78:122819)
	at un/this.$get</</a.defer/r< (http://192.168.172.11:8080/ui/mangoUi~ngMango~ngMangoServices.js?v=f41ab677f738e8ffe5b8:78:34332)

actually that exception might be related to viewing the log, not the empty plots

No points have been disabled, no event messages about disabled points, just some meta points not starting back up properly after a dirty shutdown.

The meta point has a cron of 2 minutes as the update event, the script is "return p.previous(MINUTE,2).average", and is set to average interval logging every 2 minutes.

The excel report is using rollups.

Let me know if there is any other information I can provide before I start changing things that will make any further troubleshooting of the root cause impossible.

Thanks for the details on the corruption scan. Maybe not related at all!

Part of the problem appears to be that we have used meta points for one reason or another I don't understand. The modbus data point looks fine - all the data is there except for the 3 hour period when the machine was powered off.

in the watchlist some of the meta points are flatlined and did not update since the machine was powered off. here is a screenshot showing orange penstock flow and yellow PHDS gauge flow (meta points) flatlined starting at 3:25 when the machine was powered off and did not recover until mango was restarted again, whereas others carried on just fine september 26 onwards:

however on the modbus data source it is all there:

The excel report that uses the metadata points oddly doesn't show any flatline except for where there is actually missing data, so that doesn't make any sense to me how it is getting the right data from the meta point when the flatlines are shown in the watchlist for the meta point for the same time period:

and lastly the e-mail report (not excel), also using the meta data point, is not able to produce a plot with a flatline even:

Probably re-generating the point history for the meta points will fix all this. Since I don't understand why we are using meta points at all we can probably just delete them and use the modbus points and stop having these issues, otherwise I will probably have to re-generate meta point history after the next dirty shutdown.

Before I re-generate meta history or get rid of the meta points altogether let me know if you'd like to take a closer look at the data and configuration that is there in case anything looks like an issue with mango that you would like to fix.

Thanks for your help and continued work on mango
Craig

plug was pulled on the computer. upon plugging back in some pointvalues are plotting flatlines. using tsdb.

in env.properties db.nosql.runCorruptionOnStartupIfDirty=false

so no corruption scan happened when mango restarted. changing that property to true and restarting mango does not go back and fix corruption because it was shut down cleanly. kill -9 of mango and then restarting does initiate the corruption scan, but I still have flatlines in the logs for the time between computer being plugged back in and me cleanly restarting mango.

Is there a way to force mango to go back and run a corruption scan on the whole tsdb database so the data from the time period between (plug pulled) and (mango cleanly restarted) can be plotted, or is that data not even recorded since part of the database for those point values was corrupted?

is there any reason runcorruptiononstartupifdirty is set to false by default?
is there any way I can detect when data is not being logged due to corrupted database?

Thanks.

I am trying to use units MVAR and MVARh but mango keeps changing them to MV*A and MVAh.

Can MVAR and MVARh be added to the list of units?

Hi Phil,

This was on mango 3 at all times. I had upgraded to the latest mango 3 a week ago after the problem happened the first time.

I have just upgraded the mangoNoSQL module. No update to the excel reports appeared in the list of newly released modules.

We will make sure to upgrade all of the MangoES with version 2.8 to the latest 2.8 as well.

Thanks for such a quick turn around!