GeoEvent Server configuration file

The ArcGIS GeoEvent Server configuration file (ArcGISGeoEvent.cfg) stores the startup configuration for GeoEvent Server. For the most part, entries in this file should not be modified. In some cases, it may be necessary to modify the configuration file as described below.

Configuration line numbering

Notice in the ArcGISGeoEvent.cfg file that each wrapper.java.additional property line has a number associated with it, starting with 1 for the first property and incrementing from there:

wrapper.java.additional.1=-Dkaraf.home="%KARAF_HOME%"
wrapper.java.additional.2=-Dkaraf.base="%KARAF_BASE%"

These index numbers are important and accurate ordering must be maintained. When adding or commenting out individual lines, be sure to review the indexes for accuracy.

Monitoring GeoEvent Server with JMX

JMX is a Java Management Extension that implements management interfaces for managing and monitoring Java applications. It is useful when you need to monitor the health of GeoEvent Server. You can enable JMX by adding the following lines of code to your configuration file.

#Uncomment to enable jmx settings
wrapper.java.additional.n=-Dcom.sun.management.jmxremote.port=1009
wrapper.java.additional.n=-Dcom.sun.management.jmxremote.authenticate=false
wrapper.java.additional.n=-Dcom.sun.management.jmxremote.ssl=false
wrapper.java.additional.n=-Dcom.sun.management.jmxremote.local.only=false

# Uncomment to enable jmx settings
wrapper.java.additional.n=-Dcom.sun.management.jmxremote.port=1009
wrapper.java.additional.n=-Dcom.sun.management.jmxremote.authenticate=false
wrapper.java.additional.n=-Dcom.sun.management.jmxremote.ssl=false
wrapper.java.additional.n=-Dcom.sun.management.jmxremote.local.only=false

You will need to replace the n in the lines above with the index number for the given parameter. For example:

# Minimum and Maximum Java Heap Sizes
wrapper.java.additional.13=-Xms1g
wrapper.java.additional.14=-Xmx4g

# Uncomment to enable jmx settings
wrapper.java.additional.15=-Dcom.sun.management.jmxremote.port=1009
wrapper.java.additional.16=-Dcom.sun.management.jmxremote.authenticate=false
wrapper.java.additional.17=-Dcom.sun.management.jmxremote.ssl=false
wrapper.java.additional.18=-Dcom.sun.management.jmxremote.local.only=false

Configure JMX authentication

The above examples provide access to the JMX interfaces without any authentication. Anyone guessing the proper JMX port can access the JMX data. Therefore, it is recommended to implement a proper authentication scheme as described in Using Password and Access File section of the Java Management Extension documentation.

Controlling inputs on startup

It is possible to configure GeoEvent Server to stop all inputs when GeoEvent Server starts up. Adding the following property to your configuration file and setting the value to true will ensure that when GeoEvent Server starts, all inputs will be in a stopped state.

wrapper.java.additional.n=-DSTOP_INPUTS_ON_STARTUP=true

Once again, ensure the proper index as described above is used.

Remarque :

This property is useful in development environments where GeoEvent Server may be starting and stopping frequently, and you want to ensure the elements in your GeoEvent Services are ready to receive and process the event data. In a production system, this setting would require someone to start the inputs before any data was received. Given the level of automation in system restarts and high availability, it seems unlikely that human interaction would be deliberately required.

Java memory (heap) size

On both the Linux and Windows operating systems, ArcGIS GeoEvent Server runs in a Java Virtual Machine (JVM) instance. The out-of-the-box default configuration allocates only 4GB of your server's available RAM to this JVM. All GeoEvent Server operations requiring RAM draw from this allocation, including but not limited to:

• Geofence storage
• Event caches such as the Field Enricher Processor
• Incident detection
• Analytics requiring a stateful cache such as track gap detection, enter, and exit
• General performance when processing large volumes of data at high velocities

When monitoring the performance of GeoEvent Server, you may notice it routinely consumes its maximum amount of memory (default is 4GB of RAM). Alternatively, you may notice the number of geofences that can be loaded is limited to a number that is smaller than you need. If this is the case, you can increase the amount of RAM allocated to GeoEvent Server.

When allocating RAM in a system, consider all applications that may be running on the machine. In a production environment, where GeoEvent Server is ideally the only application installed, it is reasonable to expect that GeoEvent Server would be allocated a significant portion of the machine's total memory. In development environments, where GeoEvent Server may be one of several applications installed, you should carefully allocate memory among the various applications. Even on a dedicated machine, you cannot allocate all the memory to GeoEvent Server. There are two reasons for this. The first is operating system performance; the various components of an operating system need memory to perform their various duties. As a best practice, provide the operating system approximately 25% of the memory resources. The second is the maximum JVM memory setting of 32GB; Windows limits a JVM to no more than 32GB of memory, so there is no need to set it higher than 32GB.

In addition to setting the maximum amount of memory a JVM can consume, you can also set the minimum starting memory allocation. When Java starts up, it will initially allocate this minimum amount of memory. As it consumes more memory, it will allocate more until it reaches its maximum allocation. The process to increase memory can be intensive and cause GeoEvent Server to pause while this memory allocation takes place. Because of this, plan to set the minimum starting memory as close to, or larger than, your final memory consumption as possible.

System administrators who have determined the machine has sufficient available RAM, and have determined the GeoEvent Server deployment needs more RAM allocated to the JVM instance running GeoEvent Server, can follow the steps below to increase the memory available to GeoEvent Server by allocating more RAM to the hosting JVM.

1. Stop the ArcGIS GeoEvent Server service.

   In Windows, ensure the ArcGIS GeoEvent Server service and it's associated java.exe process is stopped.

2. Navigate to the ArcGIS GeoEvent.cfg file and open it as an administrator in a text editor.

   In Windows, the file is located in the GeoEvent Server installation directory in the etc folder. Default directory location is: C:\Program Files\ArcGIS\Server\GeoEvent\etc.

3. Locate the Minimum and Maximum Java Heap Sizes block.

   Remarque :

   Depending on the version of GeoEvent Server you are using, the indexes for the JVM parameters may be different from the illustration below. The default and example allocations listed below are in gigabytes (GB).

   1. Set the -Xmx property to the maximum size to limit the JVM memory. For example:
      1. The default is 4GB: wrapper.java.additional.[index]=-Xmx4g
      2. Setting it to 16GB: wrapper.java.additional.[index]=-Xmx16g
      3. Setting it to 32GB: wrapper.java.additional.[index]=-Xmx32g
   2. Set the -Xms property to the minimum starting size of the JVM's memory. For example:
      1. The default is 1GB: wrapper.java.additional.[index]=-Xms1g
      2. Setting it to 4GB: wrapper.java.additional.[index]=-Xms4g
      3. Setting it to 16GB: wrapper.java.additional.[index]=-Xms16g
4. Save the ArcGIS GeoEvent.cfg file and close the text editor.
5. Start the ArcGIS GeoEvent Server Windows service.

Using system administrative tools, verify the JVM instance (java.exe process) for GeoEvent Server never consumes more memory than what is allocated in the ArcGISGeoEvent.cfg configuration file and that more than the default 4GB is now available for GeoEvent Server operations.