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

[LDM #QHD-410218]: Redundancy Issues with products

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 #QHD-410218]: Redundancy Issues with products
  • Date: Sat, 07 May 2011 10:57:01 -0600
Joel,

> Full Name: Joel Asunskis
> Email Address: address@hidden
> Organization: USACE St. Louis District
> Package Version: 6.8.1
> Operating System: RHEL 5.5
> Hardware:
> Description of problem:
> 
> We have a primary LDM system that manages printing and some other scripted
> tasks.  We have a lot of redundancy from various internal partners, RFCs,
> WFOs, as well as access to multiple NOAAPORT.  Redundancy is desired.
> Problem we have is that printing and the other scripted tasks will fire
> multiple times after the initial product receipt.  (Maybe the files
> have a slight byte difference extra space?)  What i am looking for is a
> better way to manage this.
> 
> Is there a way to do this through the PQACT file or am i stuck with post
> processing the files in a watch directory?  Do you have any experience
> with this or suggestions?

You might be receiving the same data-products multiple times. If a received 
data-product is deleted from the product-queue in order to make room for more 
products, then a duplicate data-product won't be rejected because the earlier 
one won't be found in the product-queue. Because of this, there's a coupling 
between the maximum acceptable latency parameter (typically one hour) and the 
size of the queue: products arriving more than the maximum acceptable latency 
after they were created will be silently ignored; products arriving within the 
maximum acceptable latency window will be checked for prior reception by 
looking in the product-queue.

Prior to LDM version 6.9, this relationship between the maximum acceptable 
latency and the size of the queue had to be manually managed via copious use of 
the pqmon(1) utility to get a handle on the minimum residence-time of products 
in the queue. With LDM 6.9, you can configure the LDM system to automatically 
increase the size of the queue if necessary, or to reduce the maximum 
acceptable latency parameter, or to do nothing but notify you of a problem. For 
more information, start at 
<http://www.unidata.ucar.edu/software/ldm/ldm-6.9.7/basics/configuring.html#vet%20registry>.
 Pay particular attention to the "/reconciliation-mode" and 
"/server/max-latency" parameters.

Contact me if you don't think this is the problem.

> Thanks....

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: QHD-410218
Department: Support LDM
Priority: Normal
Status: Closed