Welcome back to AWIPS Tips!
Today we’re going to take a more in-depth look at some of the processes running on an EDEX server. EDEX makes use of a concept known as modes. A mode consists of include and exclude statements to enable or disable various capabilities of EDEX.
The most common, and default, modes are known as:
- ingest
- ingestGrib
- request
The names are mostly self explanatory. The ingest mode is responsible for decoding and ingesting almost all of the data that goes into EDEX, except for data in grib format. The ingestGrib mode takes care of grib data specifically. The request mode handles all incoming data requests from CAVE and python-awips connections. If you are running a standalone server (all processes on one machine), you would most likely want all three of these modes running on your EDEX. The exception would be the unlikely situation where you have filtered out your incoming data so much that you don’t need ingest or ingestGrib.
Now, these processes can all function well on one machine if you have a limited set of data you’re bringing in, or you have an extremely powerful machine (lots of RAM and disk space). If you are limited by either of those factors, then you may want to run a distributed EDEX system where some of the data is received, decoded, and ingested on an external machine, and then stored properly on the main EDEX system.
In this case, you may want to run some other mode than one of the default modes. When you install EDEX, it comes with a few more modes pre-defined. You can view those modes in this file:
/awips2/edex/conf/modes/modes.xml
If you read through this file you’ll see the first three modes we talked about already defined, and then you’ll see a few more such as ingestRadar and ingestGoesR among others. These two modes are what we currently use on our two ancillary EDEX machines (one for processing radar data, and one for processing satellite data).
NOTE: This architecture differs from NWS EDEX, because we have all modes combined into the single file mentioned above. At NWS they may run multiple modes.xml files.
Using the format of entries in this file, you can create your own additional, custom modes too if you’d like. This can be really helpful if you’re running ancillary machines and want to only run the appropriate processes on them.
This architecture differs from NWS EDEX, because we have all modes combined into the single file mentioned above. At NWS they may run multiple modes.xml files.
NOTE: It is important to also limit the data you’re requesting, if you’re only processing a subset of data. Refer to our previous blog about LDM and specifically about restricting your pqact.conf on the machine.
In order for EDEX to function properly, you need to modify one more file to include the new mode you defined:
/etc/init.d/edexServiceList
The service command edex_camel references the contents of the edexServiceList to know what to activate. This means running sudo service edex_camel start will start all the modes defined in the edexServiceList. It also means the built in edex function (ie. edex start or edex stop) will properly reference and control these newly defined modes as well.
Hopefully you have learned something new about EDEX and can run a more efficient system. Please check back in two weeks for the next blog post about several different CAVE tools.
To view archived blogs, visit the AWIPS Tips blog tag, and get notified of the latest updates from the AWIPS team by signing up for the AWIPS mailing list. Questions or suggestions for the team on future topics? Let us know at support-awips@unidata.ucar.edu
