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.
Virtual Data Source to store plant name
-
Hi,
I've the following Virtual data source:
and the following datapoint used to store plant name:
If I change the value of this datapoint to "NEW POINT VALUE" it is stored correctly but when I restart mango it happens that sometimes the point value is the start value "Terlizzi Plant T01".
There's a way to retain stored the new value "NEW POINT VALUE"?
Thanks,
Antonio -
Hi Antonion,
How are you restarting Mango? What version of Mango and the NoSQL module are you using? 2.8?
The only thing that comes to mind as a suspicion is that you're running on Windows and are restarting Mango by closing the CMD window with the X, which is an abrupt termination and file buffers may not always have a chance to get flushed to disk. It would be the equivalent of giving a
kill -9in Linux. The right way to stop Mango in a CMD window is to select the window and press Ctrl + C or to restart it from the modules page. -
yes, it is 2.8.
It happens sometimes that there's no electricity from the power station so RPI shutdown but I think there's not enough time to shutdown mango correctly.
In any case I will set also the start value of the datapoint to the value I need and I think it is ok.
Thanks as always.
Antonio -
Certainly!
You may still be able to mitigate this by lowering the max open files in your Mango/overrides/properties/env.properties file. In specific, the
#Set the number of files the database can have open at one time db.nosql.maxOpenFiles=500property. The comment is somewhat misleading, what this number really means is the maximum number of output streams that can be held open. Setting this to 0 would tell the database to always close files after every write, which would encourage flushing to disk (I believe MAPPED_BYTE_BUFFER streams may not be flushed until a subsequent garbage collection)
The downside would be that buffering is done for a reason, which is efficiency, especially when points are receiving fairly rapid writes. So, performance can be affected.
