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

[LDM #OYP-784384]: A strange occurrence with Watch products

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