[IDD #LEH-889399]: 20201202: LDM log warnings

Hi,

re:
> I am having these warnings now:
> 
> 20201202T232701.661461Z idd.meteo.psu.edu [23582]    down6.c:vetProduct:226   
>            WARN  Ignoring too-old product:       9518 20201202222310.266706 
> HDS 105266874  JUSA41 KWBC 022200 /pBUFR
> 
> 20201202T232701.699505Z idd.meteo.psu.edu [23582]    down6.c:vetProduct:226   
>            WARN  Ignoring too-old product:       9518 20201202222310.267762 
> HDS 105266875  JUSA41 KWBC 022200 /pBUFR
> 
> 20201202T232701.737537Z idd.meteo.psu.edu [23582]    down6.c:vetProduct:226   
>            WARN  Ignoring too-old product:       9518 20201202222310.268822 
> HDS 105266876  JUSB45 KWBC 022200 /pBUFR
> 
> 20201202T232701.775450Z idd.meteo.psu.edu [23582]    down6.c:vetProduct:226   
>            WARN  Ignoring too-old product:        838 20201202222310.268998 
> HDS 105266877  JUSB45 KWBC 022200
> 
> Is this because I used the old queue after the update? Shall I generate
> a new queue?

No, this is not the result of using an existing queue after a new LDM
installation.  The reason that you are likely just now seeing these
messages is the newer versions of the LDM are a bit more verbose
in their logging than they were in the past.  What each message is
telling you is that the latency for the product received exceeded
max-latency value setting in your LDM's registry.

Can you send the output of the following:

<as 'ldm'>
regutil

The items that I most want to see are:

- the setting for reconciliation-mode

  I recommend that this be set to 'do nothing' (without the quotes

- the setting for /server/max-latency

  I recommend that this be set to the default which is 3600 (seconds)

If, for instance, the reconciliation mode for your LDM was set to
minimize latency (I forget the exact term for this at the moment),
the /server/max-latency value would be changed dynamically by
the LDM.  We have seen several cases where sites stopped receiving
CONDUIT data when the receipt latencies exceeded the dynamically set
value, so pretty much all received data was rejected (meaning not
put into the local LDM queue).  In the case of CONDUIT, the problem
was caused by the clocks on the NCEP source machiens for CONDUIT
drifting, so the indicated latencies grew to over 700 seconds.

Additional comment:

- the cause of your not receiving SATELLITE feed images may, in
  fact, have been caused by the /server/max-latency parameter
  having been adjust down to the point that desired products were
  being rejected

re:
> I have updated the ldm to 6.13.13. If you could take a look if it is
> looking good on your side.

I see that the real time stats being reported for your machine
now indicate that it is running the latest LDM version, v6.13.13.
Excellent!

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: LEH-889399
Department: Support IDD
Priority: Normal
Status: Open
===================
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata 
inquiry tracking system and then made publicly available through the web.  If 
you do not want to have your interactions made available in this way, you must 
let us know in each email you send to us.