[LDM #XDD-957859]: SPECIs not being "seen" by pqsurf.conf?/missing SPECIs in pqact.conf

> Steve,
> 
> > Between the 0755Z and 0855Z obs you show below, I have the following 
> > received here and decoded in GEMPAK
> > for listing with SFLIST:
> >
> > This is quite a bit more than just the 0807 and 0824Z times you mention.
> >
> > Since you said that your general FILE output where you catch all the ^S[AP] 
> > products was likewise missing the 1807Z
> > report, it sounds like either:
> >
> > 1) your output is not keeping up with the data, so that the pqact 
> > processing cannot act on the
> > data before it is removed from the queue
> 
> Hmmm. I am getting everything else.
> 

Did you get all the other KLTS times I mentioned?



> > 2) You have multiple request actions that and not identical or
> > completely disjoing such that any broken connections are confused on the
> >last product received.
> 
> Well, I have only one; I posted it.
> 

You must have more than 1 request line. Fron the IDS|DDPLUS stats, I see
weather2 feeding from idd.unidata.ucar.edu and weather3,
while weather3 is feeding from flood-0.atms.uiuc.edu, idd.aos.wisc.edu,
and idd.unidata.ucar.edu.

Since you are feeding from multiple locations, we need to make sure your request
lines match on all three, so that one is not a subset.

Where did you post the ldmd.conf file or request lines?




> > If the first item is the issue, then you will see ldmd.log messages
> >with a WARN level about processing oldest product in the queue. If you
> >see that, then data is likely getting overwritten before it
> > gets out of the queue. The solution here is to examing disk IO for
> >slowdowns, split up the
> > pqact.conf processing to multiple processes, and or check your "pqmon" 
> > output for the age of
> > the oldest product in the queue and increase the queue size if it is too 
> > short. The LDM 6.5+ distributions
> > will log this condition, so you are covered there.
> 
> So far, so good there...
> 
> > If you don't see the above, then look for disconnect/reconnects and the 
> > possibility that your
> > request line patterns contain a subset pattern. send your ldmd.conf request 
> > lines if
> > you want me to review those.
> 
> Hmmm. I'll look further, but nothing here seems to ring a bell for a
> problem. And I am definitely getting everything else. What do you suggest
> for a pqsurf.conf?

Check for any reconnections in that 8Z time range.

I think we can focus on the pqact.conf at this point, since if your FILE action 
there
didn't FILE the KLTS products, then you probably didn't get the data into your 
queue
(so the pqsurf won't se it either). Your latency looks fine, so my thought 
would be that
you are skipping over some products if your request lines have some 
peculiarities
when reconnects happen.

Since I received the products here, we know that they were in the IDD from 
idd.unidata.ucar.edu.

Steve Chiswell
Unidata User Support


 




> 
> *******************************************************************************
> Gilbert Sebenste                                                     ********
> (My opinions only!)                                                  ******
> Staff Meteorologist, Northern Illinois University                      ****
> E-mail: address@hidden                                  ***
> web: http://weather.admin.niu.edu                                      **
> *******************************************************************************
> 
> 


Ticket Details
===================
Ticket ID: XDD-957859
Department: Support LDM
Priority: High
Status: Closed