lb, > We receive Weather Service HML/XML text products over NOAAPORT, insert them > in the queue of a local LDM where they are requested from by a downstream > LDM. The pqact file on the downstream server directs the LDM to write the > files to a directory using the -overwrite option then "EXEC" a shell script > to search for the word "forecast" in product written to disk to copy the file > to a staging area for further processing if "forecast" is found. Everything > works well for awhile, but after several hours the LDM stops writing new HML > products to disk. I can see the new HML products using "ldmadmin watch" on > both the upstream and downstream LDM. When I perform a "pqcat -p HMLDVN" > (for instance) I can see the new products in the queue but pqact is not > writing them to disk. After performing an "ldmadmin restart" on the > downstream LDM it will begin writing HML files again as it is supposed to but > will eventually stop again. We have other custom products we pqinsert into > the upstream instance being requested by the downstream LDM that remain > uninterrupted. Is there a scenario that would cause pqact to stop handling > certain products after a period of time? The downstream server requests very > specific items so traffic is pretty light. We would like to avoid scheduling > an "ldmadmin restart" every few hours if possible. I can't think of anything that would cause pqact(1) to behave that way. It's certainly not intended to act that way, I don't recall anything similar, and there are hundreds of installations where it doesn't act that way. Consequently, the solution is probably something simple. Do you use the "-close" option of the FILE action? If not, does it make a difference? Are there any relevant error messages from pqact(1) in the LDM log file? It might be useful to see what the relevant pqact(1) process thinks it's doing. If you EXEC the relevant pqact(1) process with a "-v" (verbose) option from the LDM configuration-file, then the pqact(1) process will log every product that it processes. Alternatively, you can send the relevant pqact(1) process a USR2 signal to change its logging level (two more such signals will return it to its original logging-level). What version of the LDM are you using? > Thanks. > > lb > > Classification: UNCLASSIFIED > Caveats: NONE Regards, Steve Emmerson Ticket Details =================== Ticket ID: VQD-922230 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.