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

[LDM #YZC-779273]: One product in a data feed stops writing to disk

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: [LDM #YZC-779273]: One product in a data feed stops writing to disk
  • Date: Thu, 16 Jun 2016 12:55:15 -0600
Gilbert & Ryan,

Do either of you know if the data-product that was *not* written to disk was, 
nevertheless, in the receiving LDM's product-queue? You should be able to check 
for base reflectivity quality-control products with the command

    pqcat -vl- -o 999999 -f EXP -p 
/data/realtime/outgoing/grib2/MRMS_MergedReflectivityQCComposite_00.50_ 
>/dev/null

> MRMS RALA quit being written to disk yesterday.
> 
> REQUEST entries below.
> 
> # MRMS
> request EXP
> "/data/realtime/outgoing/grib2/MRMS_ReflectivityAtLowestAltitude_00.50_"
> 140.90.98.15
> request EXP "/data/realtime/outgoing/grib2/MRMS_RadarOnly_QPE_01H_00.00_"
> 140.90.98.15
> request EXP "/data/realtime/outgoing/grib2/MRMS_RotationTrack60min_00.50_"
> 140.90.98.15
> request EXP "/data/realtime/outgoing/grib2/MRMS_MESH_00.50_" 140.90.98.15
> request EXP "/data/realtime/outgoing/grib2/MRMS_MESH_Max_60min_00.50_"
> 140.90.98.15
> request EXP "/data/realtime/outgoing/grib2/MRMS_MESH_Max_1440min_00.50_"
> 140.90.98.15
> request EXP
> "/data/realtime/outgoing/grib2/MRMS_MergedReflectivityQCComposite_00.50_"
> 140.90.98.15
> request EXP "/data/realtime/outgoing/grib2/MRMS_MergedAzShear_" 140.90.98.15
> request EXP
> "/data/realtime/outgoing/grib2/MRMS_RotationTrackML60min_00.50_"
> 140.90.98.15
> request EXP "/data/realtime/outgoing/grib2/MRMS_RadarOnly_QPE_12H_00.00_"
> 140.90.98.15
> request EXP "/data/realtime/outgoing/grib2/MRMS_SeamlessHSR_00.00_"
> 140.90.98.15
> request EXP "/data/realtime/outgoing/grib2/MRMS_EchoTop_18_00.50_"
> 140.90.98.15
> request EXP "/data/realtime/outgoing/grib2/MRMS_VIL_00.50_" 140.90.98.15
> request EXP
> "/data/realtime/outgoing/grib2/MRMS_LightningProbabilityNext30min_scale_0_"
> 140.90.98.15
> request EXP "/data/realtime/outgoing/grib2/MRMS_RadarOnly_QPE_24H_00.00_"
> 140.90.98.15
> request EXP "/data/realtime/outgoing/grib2/MRMS_Reflectivity_-20C_00.50_"
> 140.90.98.15
> 
> # Non-CONUS MRMS
> request EXP
> "/data/realtime/outgoing/grib2/HAWAII/MRMS_MergedReflectivityQComposite_00.50"
> 140.90.98.15
> request EXP
> "/data/realtime/outgoing/grib2/GUAM/MRMS_MergedReflectivityQComposite_00.50"
> 140.90.98.15
> request EXP
> "/data/realtime/outgoing/grib2/ALASKA/MRMS_MergedReflectivityQComposite_00.50"
> 140.90.98.15
> request EXP
> "/data/realtime/outgoing/grib2/CARIB/MRMS_MergedReflectivityQComposite_00.50"
> 140.90.98.15
> 
> This worked fine until 6.13.0. After that upgrade, we've seen select
> products from this upstream site go missing. A "notifyme" against the
> upstream site shows the products are in their queue and an LDM restart
> fixes the issue. The first time we were missing ~5 of the requested
> products while the rest continued to be processed. This latest time
> (yesterday at 13Z) we only lost RALA but again, a LDM restart was necessary.
> 
> The MRMS feedset is so large that we've been forced to individualize the
> entries.
> 
> The only logs from the incident are from our LDM and they were included by
> Gilbert. Nothing in the log seems to indicate any issues other than the LDM
> does appear to be re-establishing its REQUESTs to the server for some
> reason.

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: YZC-779273
Department: Support LDM
Priority: Normal
Status: Closed
===================
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.