NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Hi Scott, > The SPC is testing a new mechanism to send their watch products and we have > seen a very strange behavior with the products when they are received by > the LDM on an independent test system. > > We have the following 2 entries in the pqact: > > # > # WWP Product > WMO ^WWUS40 KWNS ([0-3][0-9])([0-2][0-9]).*/pWWP > FILE data/nwx/spc/wwp/(\1:yy)(\1:mm)\1\2.wwp > # > # TEST FOR TEST WATCH with OPCN and SPC > WMO ^WWUS.. .... ([0-3][0-9])([0-2][0-9]) > FILE data/nwx/spc/wwptest/(\1:yy)(\1:mm)\1\2 > > That is one with "/pWWP" and one without. For the old distribution method, > both entries store the product. For the new method, only the second entry > stores the product. > > The ldmd.log had the following: > > ldmd.log:Mar 08 19:47:47 YYY XXX[23232] INFO: 1057 20120308194747.677 > IDS|DDPLUS 21516205 WWUS40 KWNS 081947 /pWWP7 > ldmd.log:Mar 08 19:47:47 YYY pqact[23228] INFO: 1057 20120308194747.677 > IDS|DDPLUS 21516205 WWUS40 KWNS 081947 /pWWP7 > ldmd.log.1:Mar 07 15:05:16 YYY XXX[23232] INFO: 1052 20120307150516.987 > IDS|DDPLUS 18984771 WWUS40 KWNS 071504 /pWWP9 > ldmd.log.1:Mar 07 15:05:17 YYY pqact[23228] INFO: 1052 > 20120307150516.987 IDS|DDPLUS 18984771 WWUS40 KWNS 071504 /pWWP9 > ldmd.log.1:Mar 07 20:25:02 YYY XXX[23232] INFO: 1057 20120307202502.416 > IDS|DDPLUS 19449113 WWUS40 KWNS 072024 /pWWP8 > ldmd.log.1:Mar 07 20:25:02 YYY pqact[23228] INFO: 1057 > 20120307202502.416 IDS|DDPLUS 19449113 WWUS40 KWNS 072024 /pWWP8 > > (XXX and YYY are machine names that I removed for this email.) > > Note that the "/p" are present on all of the products. WWP9 on 3/7/12 and > WWP7 on 3/8/12 were sent with the new method and did not store properly. > WWP8 on 3/7/12 was sent with the old method and worked. > > Do you have any insight into this behavior? Offhand I'd say the old method creates product-identifiers that match both pqact(1) entries and the new method creates product-identifiers that only match one entry. I don't see how that's possible, however, given that the product-identifier "WWUS40 KWNS 072024 /pWWP8" matched both entries but the product-identifier "WWUS40 KWNS 071504 /pWWP9" only matched one. If you sent the pqact(1) process in question a SIGUSR2, then it will log messages at the DEBUG level, which might provide more information on what, exactly, is happening. A second SIGUSR2 will put the process into terse logging mode and a third SIGUSR2 will return it to verbose logging mode. Because the FILE actions don't utilize the "-close" option, it could be that the missing data-products are "latent" and haven't yet hit the disk. You might try adding that option (or at least "-flush"). > Thanks, > > Scott Regards, Steve Emmerson Ticket Details =================== Ticket ID: OYP-784384 Department: Support LDM Priority: Normal Status: Closed