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

[LDM #QST-811359]: Using pqinsert as daemon

Hi again Justin,

I agree with Steve's comments:

"I prefer event-driven designs rather than one that rely on poling."

(even though polling has two Ls ;-)

The other thing that I forgot to include in my earlier reply is the
desirability to create a "manifest" of the products inserted into
the LDM queue as product inserts (via pqinsert) are attempted.  It
is useful for all if the 'manifest' file is sent as the last product
in a set as this lets feed recipients cross check to make sure that
they received all of the products that should have been sent.  It
is also useful as a check to see if some pqinsert attempts did not
succeed due to a product with the same MD5 signature already being
in the LDM queue.  This "reality check" is especially useful for
the CONDUIT datastream where multiples of the same product (GRIB2
message) are attempted to be added to the LDM queue but the duplicates
are rejected.  In the early days of CONDUIT, end-users would send
us support inquiries that claimed that the LDM was dropping products.
Their observations were a result of comparing the volume of data
received versus what was downloaded by FTP. The size differences
were always explainable by the non-sending of duplicate products.


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: QST-811359
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.