Re: pqing stopped inserting when downstream requested feed

Jared P Bostic wrote:
> Hi,
> I'm not sure if Jessica is still up or not (she works where I work),
> so I thought I'd throw in more info.  In response to your query,
> we also run a Unisys NOAAPort Receive System here.  We have two Solaris
> 7 x86 boxen attached to our sat receivers, each spewing out 2 channels on
> a private network to the previously mentioned FreeBSD box.  So, under
> normal operation, the FreeBSD box should have four instances of pqing
> running - 2 per Unisys PC.
> This afternoon AOA 2025 Z, one of our developers tried to start ldm,
> with the feedme pointed at ye olde FreeBSD box.  At around the same
> time, the pqing process handling the data from NWSTG (on our system
> the No 2 channel), died, as recorded by the ldm on the FreeBSD box.
> Granted, this doesn't necessary mean there was any connection between
> the two events - just strangely coincident.  This mysterious process
> dying thing has also happened a couple of times when, to our knowledge,
> no one was trying to connect.
> Thanks for the reply and any further comments/assistance!
> Jared Bostic

Hello Jared and Jessica,

This is a just a quick response in order to get back to you.  I'm not
sure what is causing your problem, but I will tell you what I know.

Our IDD does not use the Unisys NRS.  Instead our four ingest sites use
SSEC's ingest system.  We have been running very reliably with this
system for some time.

pqing was originally written to handle the FOS data stream.  It was not
written to handle the NOAAPORT stream, so even with the SSEC system,
pqing is being used for something for which it was not originally
intended.   We have no experience running it with the Unisys NRS. 
Offhand, I do not know what pqing does when, for example, a port is
closed or there is no data for some period of time.  It would be
necessary to study the code to determine this.

I seriously doubt there is a connection between pqing exiting and the
downstream site requesting a feed.  As Mike pointed out, the only
connection between the two processes (pqing and rpc.ldmd) is the queue. 
It was probably just a coincedence.  Although as I write this I can't
entirely rule out the possibility that a conflict on the queue might
have generated the conflict message in the log.  I will investigate what
might cause a conflict for pqing that could cause it to exit.

Although a few of our sites do run their LDM on FreeBSD, we do not
officially support that OS.  None of our ingest sites use it.

There is a recollection regarding an effort some years back to using
pqing with a special box that translated a stream into a TCP format that
involved disconnections.  I will see what I can find out this.

Either your log at the time of the event was very small, or you snipped
a piece out for us to see.  Can you make the entire log available for

Anne Wilson                     UCAR Unidata Program            
anne@xxxxxxxxxxxxxxxx                  P.O. Box 3000
                                  Boulder, CO  80307
Unidata WWW server

  • 2001 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the ldm-users archives: