Re: 20040329: IDD/LDM - RPC Question

Steve (and Patrick),

The dcrdf decode error is caused by a bulletin that is larger than
allowed, so the decoder does not decode it. It is just a limitation
of the compile time parameter of the largest product allowed
to be passed to the decoder, but does not signal any problem
with the LDM behavior.

See item #2 at:

http://www.unidata.ucar.edu/projects/coohl/mhonarc/MailArchives/ldm/msg07161.html

To eliminate the error, a specific pqact entry that avoided the KPAH
product being passed to dcrdf would solve the problem. The general
problem is that the RDF products are still very new and not well
structured as separate from the PFM products.

Steve Chiswell
Unidata User SUpport


On Mon, 2004-03-29 at 13:48, Steve Emmerson wrote:
> Patrick,
> 
> >Date: Mon, 29 Mar 2004 14:37:17 -0600
> >From: "Patrick O'Reilly" <address@hidden>
> >Organization: University of Northern Illinois
> >To: Steve Emmerson <address@hidden>
> >Subject: RE: 20040329: IDD/LDM - RPC Question
> 
> The above message contained the following:
> 
> > Thunder feeds from stokes.  At this point, thunder is a leaf node.
> 
> That configuration would have data products going FROM port 338 on
> Stokes TO some miscellaneous port on Thunder (the opposite of what you
> reported).
> 
> > Stokes
> > has allow entries for thunder, thunder has no accept entries.
> 
> Does Thunder have ALLOW entries for Stokes?
> 
> I note that the LDM system on thelma.ucar.edu receives at least 1.8
> million RPC messages per day.
> 
> > In the
> > default ldmd.conf, it states that at this time, accept entries are only
> > necessary for WSI data.
> 
> Or for getting data via ldmsend(1).
> 
> > Thunder's log file is always full of certain
> > errors, as things usually run well, I have not paid too much attention to
> > them.  There weren't more or less of them when this was occurring.  They are
> > like:
> > 
> > Mar 28 09:24:32 thunder pqact[7550]: child 29832 exited with status 127
> > Mar 28 09:29:22 thunder pqact[7550]: child 30394 exited with status 127
> > Mar 28 09:29:59 thunder pqact[7550]: child 30397 exited with status 127
> > Mar 28 09:32:16 thunder pqact[7550]: pbuf_flush 8: time elapsed   2.625856
> > Mar 28 09:32:37 thunder pqact[7550]: pbuf_flush (5) write: Broken pipe
> > Mar 28 09:32:37 thunder pqact[7550]: pipe_dbufput:
> > decoders/dcrdf-v4-ddata/gempak/logs/dcrdf.log-eGEMTBL=/home/gempak/GEMPAK5.6
> > /gempak/tablesdata/gempak/rdf/YYYYMMDDHH.rdf write error
> > Mar 28 09:32:37 thunder pqact[7550]: pipe_prodput: trying again
> > Mar 28 09:32:37 thunder pqact[7550]: pbuf_flush (5) write: Broken pipe
> > Mar 28 09:32:37 thunder pqact[7550]: pipe_dbufput:
> > decoders/dcrdf-v4-ddata/gempak/logs/dcrdf.log-eGEMTBL=/home/gempak/GEMPAK5.6
> > /gempak/tablesdata/gempak/rdf/YYYYMMDDHH.rdf write error
> > Mar 28 09:35:08 thunder pqact[7550]: pbuf_flush 8: time elapsed   2.320114
> > Mar 28 09:35:10 thunder pqact[7550]: child 30426 exited with status 127
> 
> The above entries pertain to the pqact(1) program writing to a GEMPAK
> decoder rather than to any of the three types of LDM-specific processes
> (LDM server, upstream LDM, downstream LDM).
> 
> > You can view both sets if you like:
> > 
> > http://thunder.storm.uni.edu
> > 
> > http://stokes.metr.ou.edu
> > 
> > I would be interested in eliminating the problem causing the above errors,
> > as a side note.
> 
> I've CC'ed Steve Chiswell.  He might know something about the above
> GEMPAK-decoder failures.
> 
> Regards,
> Steve Emmerson