1. Why another archiver?
    Archiving millions of PVS requires a few additional features. In addition to focusing on the EPICS side of the equation, we also need to address the various IT aspects like flexibility, scriptability, policy enforcement etc. A integrated multi-head, multi-stage solution was called for; hence the appliance.
  2. What are the various configuration items?
    The various aspects of configuration are separated logically.
    Environment variableDescriptionDefault
    ARCHAPPL_APPLIANCESThis 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.appliances.xml
    ARCHAPPL_POLICIESThis contains the full path name of your policies file. The policies file is a python script that controls the parameters for archiving.policies.py in WEB/classes
    ARCHAPPL_PROPERTIES_FILENAMEThis contains the full path name of archappl.properties file. The archappl.properties is the misc bucket for configuration and is a Java properties file with various name/value pairs.archappl.properties in WEB/classes
    ARCHAPPL_MYIDENTITYThis 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 appliances.xmlgetCanonicalHostName() in InetAddress.getLocalHost()
    In addition to this, the configuration for each PV is stored in the PVTypeInfo table in the MySQL configuration database specific to each appliance. The connection pool for the database is typically configured in Tomcat's conf/context.xml.
  3. Where are the logs?
    Most deployment have four tomcat containers per appliance - one each for the engine, ETL, retrieval and mgmt components. All the logs typically are sent to arch.log or similar files in the CATALINA_HOME/logs of these containers. Log levels are typically controlled using a log4j.properties file in the TOMCAT_HOME/lib folder of these containers.
  4. What's the difference between SCAN and MONITOR?
    These are minor variations of the similar concepts in the ChannelArchiver and other archivers. Both SCAN and MONITOR use camonitors.
    • For MONITOR, we estimate the amount of storage needed using the sampling period and fill it up. The capacity is computed using something like so (see ArchiveEngine.java:addChannel)
      int buffer_capacity = ((int) Math.round(Math.max((write_period/pvSamplingPeriod)*sampleBufferCapacityAdjustment, 1.0))) + 1;
      
      For example, if the write_period is 10 seconds, and the pvSamplingPeriod is 1 second, we would allocate 10/10 + 1 = 11 samples 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 SCAN, the engine updates one slot/variable at whatever rate is sent from the IOC. And then a separate thread picks the value of the one slot/variable every sampling period and writes it out.
  5. How are timezones handled?
    EPICS IOC's use UTC as their timezone. The EPICS Archiver Appliance also uses UTC for data storage and retrieval; that is, data is received, stored and retrieved as UTC timestamps. Conversion to local time zones are to be done at the client/viewer. The various viewers handle the transition into and out of daylight savings appropriately. For example, in this case, there are two 01:00 blocks on the x-axis to handle the extra hour inserted when daylight savings comes to an end at 01:00 on Nov/1/2015.