|This is mandatory and points to a file containing the list of appliances in this cluster. This must be identical across all members in the cluster.|
|This contains the full path name of your policies file. The policies file is a python script that controls the parameters for archiving.|
|This contains the full path name of |
|This contains the identity of this appliance; of course, this is different for each appliance. The appliance identity needs to match the identity as defined in the |
PVTypeInfotable in the MySQL configuration database specific to each appliance. The connection pool for the database is typically configured in Tomcat's
arch.logor similar files in the
CATALINA_HOME/logsof these containers. Log levels are typically controlled using a
log4j.propertiesfile in the
TOMCAT_HOME/libfolder of these containers.
int buffer_capacity = ((int) Math.round(Math.max((write_period/pvSamplingPeriod)*sampleBufferCapacityAdjustment, 1.0))) + 1;
write_periodis 10 seconds, and the
pvSamplingPeriodis 1 second, we would allocate
10/1 + 1 = 11samples for the default
sampleBufferCapacityAdjustment. Thus, in the case where the PV is changing at a rate greater than 1Hz, you should expect 11 samples, a gap where we run out of space and throw away samples, then 11 samples when we switch buffers and so on. For example, here's a 10Hz PV being MONITOR'ed at 1 second.
Nov/22/2019 08:30:06 -08:00 -0.6954973468157408 0 0 717169462 ... Buffer switch drop samples here Nov/22/2019 08:30:15 -08:00 0.13051475393574385 0 0 717195856 Nov/22/2019 08:30:15 -08:00 0.1404225266840449 0 0 816931850 Nov/22/2019 08:30:15 -08:00 0.15031625729669593 0 0 917194635 Nov/22/2019 08:30:16 -08:00 0.1601949564088804 0 0 17161946 Nov/22/2019 08:30:16 -08:00 0.17005763615891936 0 0 117100329 Nov/22/2019 08:30:16 -08:00 0.17990331028705667 0 0 217167979 Nov/22/2019 08:30:16 -08:00 0.1897309942340842 0 0 317064449 Nov/22/2019 08:30:16 -08:00 0.19953970523979697 0 0 416941153 Nov/22/2019 08:30:16 -08:00 0.2093284624412683 0 0 516970909 Nov/22/2019 08:30:16 -08:00 0.21909628697093528 0 0 617021076 Nov/22/2019 08:30:16 -08:00 0.22884220205448483 0 0 717085134 .... Buffer switch drop samples here Nov/22/2019 08:30:25 -08:00 0.9047907734809058 1 4 717192286
pvSamplingPeriodseconds and writes it out to the buffers.
01:00blocks on the x-axis to handle the extra hour inserted when daylight savings comes to an end at 01:00 on Nov/1/2015.
When adding a PV with an alias to the archiver, the archiver uses the
NAME/NAME$ fields of the PV to determine the real name.
The PV is then archived under the real name and an entry is added to the
PVAliases table with the alias name.
Data retrieval and management are then supported under both names.
For aliased PV's, the PVDetails of the PV should an a line indicating that this PV is an alias for the real PV.
Also, in the mgmt webapp's arch.log, there should be an entry indicating this like so Aborting archive request for pv ABC:DEF:ALIAS Reason: Aborting this pv ABC:DEF:ALIAS (which is an alias) and using the real name ABC:DEF:REAL instead.