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.

@Jared-Wiltshire Thanks! I made that change, but I am now having an issue rebooting the Mango server. I had to take it down to move it. I posted a new topic here: http://infiniteautomation.com/forum/topic/2488/java-error-during-init-cannot-map-handler-there-is-already-handle-of-type-xxx-mapped Java cannot map handler to the URL path of my custom dashboard because apparently there is already a handler of that type mapped.

You may get truncated class or class not found exceptions after you've manipulated the files without restarting. Neither is fatal. But, you don't really save yourself a lot of effort by running three bash commands sooner than whenever you're going to restart.

Thank you for the quick reply. I will give this a try. It may take a bit for me to digest and figure out a few other things in addition to the info here in order to finish. I hope to get back and post details of a successful result.

Phil, When we changed back to the h2 db mango came up fine, so it's something with the mysql and the server. will let you know more when we fine it. Thanks

Do you get the same behavior in a different file location? I assume by 'the file' you meant the Mango directory. This still surprises me, as a Windows user (having USER privileges) cannot delete a directory whose contents are open in another application. Going through Windows Explorer this gives a dialogue that files are open. Running "del /s /q C:\Mango" in an elevated command prompt appears to work, but that's somewhat willful, and files and directories open at the time of the delete attempt are still spared. This is definitely not a Mango issue.

unitronics PLCs support modbus over serial and TCP/IP on ethernet. use the mango modbus data source.

Phil, I restored all of the incrementals up until the deletion occurred since everything since then would be stored on the ES devices we've deployed so I wasn't worried about the most recent stuff. I did not attempt what you suggested since restoring them one at a time worked. After restoring around 10 I would run in to a concurrent error. I would reboot and then pick up were I left off. Everything seems to have gone well and I don't appear to be missing anything. Thanks for your help and suggestions.

Ok after reading trough those posts, I can see that mine happens about every 12 hours, but I don't know what tasks I've set (if it was me) to occur every 12 hours. Either way, if it's not a big deal then I'm not worried.

Thanks for sharing the resolution!

Most welcome. Also, I had to edit my script... tis "detectorXID" in the point event handler object.

Hello again! Thanks for your fast response. I tied your proposal. Success! If all points are set to " Do not log" I still get the "0x0" so I tried set points to log and the Data source to not log anything and the fail disappeared. Now i can see other problems diving up in an reasonable way. I will continue my investigation what are causing the problems. Possibly its due to bad wiring or severe disturbances from source. Will post later what finding I get. Thanks again.

Hi ray, You're correct. I took a quick peek at the history of the code producing that chart, and didn't find an obvious culprit. So, I've created a git issue for this: https://github.com/infiniteautomation/ma-core-public/issues/828 Thanks for letting us know.

uhhh... yeah. I knew that. ;-)

Hi Phil, There are no hs_err logs in my MangoES instance after changing the meta datasources like you instructed. The system was stable for a while but then switched off and a manual restart was needed to get mango up again. As I was checking what may be the cause I found out that using concurrent-carbage-collector to free some memory space was the reason for strange behaviour in the system. The average uptime was still around 3-5 h. After removing the CGC the system went stable and then I noticed that there is a memory leak somewhere because right now the system can work around 20 h and then reboots. The memory usage at boot is around 1 gb and starts growing until Mango reboots. Probably because system kills Mango as it is taking so much memory and then the check.sh script reboots MangoES. As i understand that removing the CGC set me up with the default GC algorithm but I can't seem to notice if the GC on Mango is freeing up my memory or not. Its a problem because I think ideally MangoES should be running for days/months without interruption. I have another MangoES in my office running now 3 days straight without problems. Of course it is just a clean out of the box with only System Information datasources activated. But this instance will be going to our clients also next week with a similar system installed on it as the one which I am having problems with. Many thanks, Thomas

Unfortunately there is no way. You can also do it from the SQL console, try this DELETE FROM pointValues WHERE dataPointId NOT IN (SELECT ID FROM dataPoints) LIMIT xxx

Terry, Thanks for the tip on: runtime.realTimeTimer.defaultTaskQueueSize The setting was adjusted to a max of 2. The FATAL message still occurs. Periodicity is around a minute between occurrences. It seems better than it was but still nagging away. If you're not seeing the same thing on your end there must be a configuration difference on my end. Dealing with configuration problems is tiresome for all involved. With that in mind, I highly recommend Docker. If Mango were available on the Docker hub I'd definitely use it.

Solved.. Thank you all