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

20051129: LDM 6.4.3 pipe_prodput, pbuf_flush, pipe_put errors (cont.)

>From: Mark Seefeldt <address@hidden>
>Organization: CU
>Keywords: 200511212255.jALMtu7s026640 GEMPAK LDM pqact.conf

Hi Mark,

re:
>All indications are that the timeout fix likely takes care of the 
>problem.  There were not any errors listed for dcwstm for yesterday 
>after the change at 1845 UTC.  Today, the same error did resurface again 
>at 14:58 UTC.  That is one occurrence compared to 21 times the error was 
>indicated yesterday, although the advisories/watches/warnings were 
>probably more active yesterday.

Very good.  You may want to add/increase the timeout (use '-t' flag) on
the other GEMPAK decoders that are showing up ldmd.log 'pipe_put' error
messages.

While we were on your system we noticed that you had redundant
requests for data from the same upstream site:

request WMO ".*" rainbow.al.noaa.gov
request    IDS|DDPLUS    ".*"    rainbow.al.noaa.gov
request    HDS    "/mNAM_84"    rainbow.al.noaa.gov
request    HDS    "/mRUC"    rainbow.al.noaa.gov

'WMO' is a mnemonic for two distinct datastreams:

WMO == IDS|DDPLUS|HDS

(IDS|DDPLUS is actually one stream)

Your request for 'WMO' data from rainbow.al.noaa.gov will get you
all products in the IDS|DDPLUS and HDS datastreams.  If you want to
receive only the 'NAM_84' and 'RUC' products from HDS, you should
comment out your request line for 'WMO' and then restart your LDM.

Cheers,

Tom

>Unidata Support wrote:
>>> From: Mark Seefeldt <address@hidden>
>>> Organization: CU
>>> Keywords: 200511212255.jALMtu7s026640 GEMPAK LDM pqact.conf
>> 
>> Chiz and I logged onto foehn this morning and looked at the ldmd.log
>> pipe_put errors you are getting.  Chiz commented that some of the
>> decoders are most likely timing out due to lack of new data and
>> exiting.
>> 
>> The pqact.gempak entries for processing are sending all of a certain
>> type of product to the decoder using a PIPE action that does not
>> close.  What is going on is that the next time that pqact has a product
>> to send to the decoder, the decoder has exited so the pipe write
>> fails.  pqact then retries the same action (it will always retry once
>> for each failed invocatino) and a new invocation of the decoder is
>> started, and it succeeds.
>> 
>> To test the assertion that the GEMPAK decoders are timing out and
>> exiting, Chiz added a timeout of 7200 seconds for dcwstm at about 18:45
>> UTC today (Monday, NOvember 28).  If the timeout assertion is correct
>> you will not see any more errors from dcwstm while weather rolls across
>> the country.
>> 
>> Cheers,
>> 
>> Tom
>> --
>
--
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.

>From address@hidden  Tue Nov 29 18:07:24 2005

I forgot to include a comment on this.

Yeah, this duplication took me a few months to figure out.  I kept 
wondering why I was getting all of the model runs, when I had only 
specified NAM_84 and RUC.  I think looking through the feed types last 
month I made the connection.  Now that I have been receiving the data I 
am re-determining what I want to keep.

Thanks for point it out to me.

Mark