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

Re: 19990901: pqing conflict

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: 19990901: pqing conflict
  • Date: Wed, 1 Sep 1999 16:42:38 -0600 (MDT)
On Wed, 1 Sep 1999, Unidata Support wrote:

> >To: address@hidden
> >cc: address@hidden
> >From: Chad Johnson <address@hidden>
> >Subject: pqing conflict
> >Organization: .
> >Keywords: 199909012109.PAA24574
> 
> Hi,
> 
> A couple days ago I had a problem regarding an error with pqing. The 
> recommended
> solution was to increase the product queue by 20%. I increased the size of the
> product queue and the same error occurred again this afternoon. The only data
> getting stuffed into the product queue is NWSTG from NOAAPORT. My queue size
> currently stands at 144 MB. Is there a recommended queue size for ingesting
> NOAAPORT data? I suppose I could bump it up to say 200MB. Also, where do you

Chad,

I wondering if you are getting some of the nexrad data now on the NOAAport
system. I have a filter to exclude that data but it was recently modified
because of loophole. Here's new the filter:

"(^[A-RT-Z]|^S[^D]|^SD..[0-8]|^SD..9[^7])"

The filter should be on the request line to the alden nport machine as
well as your local one.

If you continue to have del_oldest messages, go ahead and bump up the
queue size. The del_oldest conflict causes much overhead for the ldm.

> recommend the ldm.pq file be placed. Currently it is in a ufs (Solaris) file
> system, but this file system is not dedicated strictly to the product queue.
> 
It doesn't matter that the ldm queue is not on a dedicated system as long
as it's a local file system.

Robb...


> Thanks for your help.  -Chad
> 
> Sep 01 20:44:27 dusk pqing[13424]: del_oldest: conflict on 86415008
> Sep 01 20:44:27 dusk pqing[13424]: pq_insert: Resource temporarily unavailable
> Sep 01 20:44:27 dusk pqing[13424]: Exiting
> Sep 01 20:44:27 dusk pqing[13424]:   Queue usage (bytes):144003072
> Sep 01 20:44:27 dusk pqing[13424]:            (nregions):   38891
> Sep 01 20:44:27 dusk pqing[13424]:   Duplicates rejected:    5537
> Sep 01 20:44:27 dusk pqing[13424]:   WMO Messages seen:    399746
> Sep 01 20:44:27 dusk pqing[13424]:   SOH/ETX missing  :         0
> Sep 01 20:44:27 dusk pqing[13424]:   parity/chksum err:         0
> Sep 01 20:44:27 dusk pqing[13424]:   WMO format errors:       732
> Sep 01 20:44:27 dusk pqing[13424]:   FILE Bytes read:    3186083069
> 
> -- 
> Chad W. Johnson                           E-mail: address@hidden
> Programmer/Meteorologist                  Voice: (608) 265-5292
> Space Science and Engineering Center      Fax: (608) 263-6738
> University of Wisconsin -- Madison
> 

===============================================================================
Robb Kambic                                Unidata Program Center
Software Engineer III                      Univ. Corp for Atmospheric Research
address@hidden             WWW: http://www.unidata.ucar.edu/
===============================================================================