[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[AWIPS #KLE-673390]: EDEX Latency Issues

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: [AWIPS #KLE-673390]: EDEX Latency Issues
  • Date: Tue, 02 Dec 2014 11:29:36 -0700
The default purge rules for any product not specified in a decoder purge file 
is taken from

/awips2/edex/data/utility/common_static/base/purge/defaultPurgeRules.xml

You will need to add a purge rule to the file

/awips2/edex/data/utility/common_static/base/purge/satellitePurgeRules.xml

and restart EDEX for it to take effect.  The syntax should be

<rule>
        <keyValue>CONUS</keyValue>
        <keyValue>DHR</keyValue>
        <versionsToKeep>60</versionsToKeep>
</rule>

Notice at the top of that file, 
<key>sectorID</key>
<key>physicalElement</key>

SectorID for all Unidata FNEXRAD composites is "CONUS" and the physicalElement 
key must match what is in

https://github.com/Unidata/awips2/blob/upc/edexOsgi/com.raytheon.edex.plugin.satellite/res/scripts/physicalElements.sql

In the case of FNEXRAD products it's simply the product identifier (DHR, DVL, 
HHC, etc)

By the way, I'll add these purge rules by default.  How many frames back is 
ideal for you?

-Michael


> Thank you. I will make the changes.
> 
> I was surprised myself. I mean it hasn't always been that way. On earlier
> releases, I didn't encounter this type of issue, or not at least to this
> degree.
> 
> BTW, do you know how to change the purge for the radar composites (DHR)? It
> doesn't appear to be under radar or satellite purge rules.
> 
> address@hidden> wrote:
> 
> > > After I left it run most of the day, it actually went up to like 10,000
> > > second latency.
> >
> >
> > Yikes.  That's bad.  I'm seeing error with the ACARS decoder so I've
> > commented out the ACARS entry in pqact.conf
> >
> > ANY    ^(IUA[^XK]0[12]) (....) (..)(..)(..)
> >        FILE    -overwrite -close -edex
> > /awips2/data_store/acars/acars_raw_decrypted/\1_\2_\3\4\5_(seq).bufr.%Y%m%d%H
> >
> > I suggest you do the same and restart.  You may have to turn off live
> > ingest to let EDEX catch up, or shut down EDEX services and remove
> > /awips2/qpid/messageStore/ and restart.
> >
> > with your system specs I'm surprised you're seeing latencies growing like
> > this.  I see some delay on my two servers but nothing that can't be caught
> > up with.
> >
> > Ticket Details
> > ===================
> > Ticket ID: KLE-673390
> > Department: Support AWIPS
> > Priority: Normal
> > Status: Open
> >
> >
> 
> 

Ticket Details
===================
Ticket ID: KLE-673390
Department: Support AWIPS
Priority: Normal
Status: Open