Thank you, it works in my sandbox Mango environment! :) You just saved me 4 hours of exporting-textediting-deleting-importing-testing nightmare!
Thanks again!
Thank you, it works in my sandbox Mango environment! :) You just saved me 4 hours of exporting-textediting-deleting-importing-testing nightmare!
Thanks again!
Hi Phil!
I did what you suggested, I added the code to the end of the file. It works correctly, the views are in alphabetic order now.
However, the view-selector drop-down menu works incorrectly. The selected view is not the view I can see on the webpage (but the last one). The result is that I cannot select the last view, because the list "thinks" that this is selected already.
Could you please fix this for me?
Thank you!
Hi Phil!
I tried to get the thread-list, but the Mango did not respond. In that state (H2 database file recover?) the rest API was not responding. I tried to restart the Magno multiple times, but it did not solved the issue, just the database file gets bigger and bigger.
I also tried to move the full Mango with the problematic database file to ramdrive to speed up the recovery, and it finishes in 10 minutes, but after 2-3 Mango restart, the recovery started again.
Finally, I decided to try to restore the database from the latest automatic backup file, and this looks like solved the issue in the last 11 hours. I will monitor closely the server in the next 2-3 days to make sure this is the solution for this problem.
I'm worried about that I don't know what was the root cause of the H2 database problem, do you have a list that I must not do with the Mango to avoid this behavior in the future?
Thank you,
gbodacs
I had to restart the Mango instance, because the login was not working. After pressing the ctrl+c, the Mango logged the line (pressed the ctrl+c and started shutdown procedure), but nothing happens after 5 minutes of waiting, so I killed the process.
I started it again, and now I can log in and use the webpages. The CPU and HDD usage is high again and the features (Graphics View, SQL, Settings, etc) are not working, so it is still in that status.
Luckily, the threads in the log view works, so I made a screenshot about the suspicious thread:
Of course, this was not triggered from the UI in this case.
Hi TerryPacker!
It is happening more than eight hours now. The CPU usage and the hard disk usage is still very high.
The situation changed in a bit, now I cannot log in into the webpage. The login page is loaded, but after I type the creds and press the Login button, the webpage is loading endlessly.
Is there a way to get this information outside of the Mango webpage?
Thank you,
Gbodacs
I have found the thread what causes the problem:
Please help to fix this issue!
Well, it happend again. I was watching the data points in the Mango, and the database halted. The Mango webserver working correctly, but no data on the webpages (eg. settings) or the page does not load (Graphic views) correctly, just the loading animation of the browser shows.
The problem is not connected to the Mango start (because the Mango instance was working for more than a day correctly). I just realized, that the CPU usage is very high in this status (30-60%) and the hard disk is working hard on the database file:Mango\databases\mah2.h2.db (it's not on the screenshot)!
The console log is "empty", no exception, no error messages. The log file in the log folder are 0 byte long.
Last time it takes 40 minutes to relive from this half-dead status.
This Mango instance controls 13 government heating centers for schools, kindergardens, hospitals, etc! Any thoughts how to fix this?
Thanks!
Hi Phil,
Thank you for the fast response!
After running the "db corruption check" the Mango works like a charm! I'm pretty sure I did not close the console window with the X, but I found a timeout in the configuration file:
runtime.shutdown.medLowTimeout=60
runtime.shutdown.highTimeout=60
What happens if I start the shutdown process and one minute is not enough? Could this make to corrupt the database?
In the past I had lots of "high priority task timeout exception, thread pool is full (100)". So I modified the 100 to 200. Could the small thread pool make corruption to the database?
The log files in the log folder are always 0 byte long, where should I look for the notification about the corrupted database?
Thank is advance,
gbodacs
I set the "fix db corruption problems" flag in the property file and after 40 minutes of loading, the Mango finally started!
I mean 40 minutes after the startup sequence, after I can log in.
The db file size is ~2 GByte.
I did not waited 40 minutes before the flag set, so I'm not sure the db was in a corrupted state...
I still think the root cause of the problem is the Windows update.
@gbodacs
I unzipped an old backup package from 17-dec-2017, that version was working correctly. Now it doesn't. Same issue with it.
I can think of the only change in the last week that I updated my Windows Server 2016 with the latest updates. Does anyone have issues with the latest Microsoft updates here?