Anne,
After looking at more pqing exits, it looks like the pqing process exits
after there is a conflict when deleting the oldest product from the queue.
The following lines seem to happen every time that we have the pqing exit.
<131>Feb 15 00:10:33 pqing[38196]: pq_del_oldest: conflict on 65407472
<131>Feb 15 00:10:33 pqing[38196]: pq_insert: Resource temporarily
unavailable
<133>Feb 15 00:10:33 pqing[38196]: Exiting
<133>Feb 15 00:10:33 pqing[38196]: Queue usage (bytes):300003328
<133>Feb 15 00:10:33 pqing[38196]: (nregions): 14577
<133>Feb 15 00:10:33 pqing[38196]: Duplicates rejected: 0
<133>Feb 15 00:10:33 pqing[38196]: WMO Messages seen: 127
<133>Feb 15 00:10:33 pqing[38196]: SOH/ETX missing : 0
<133>Feb 15 00:10:33 pqing[38196]: parity/chksum err: 0
<133>Feb 15 00:10:33 pqing[38196]: WMO format errors: 2
<133>Feb 15 00:10:33 pqing[38196]: FILE Bytes read: 260290889
We tried reverting back to ldm-5.1.2. It had the same problem.
We have appreciated your response. If we can give you any more information,
please let me know.
Thanks,
Jessica
jthomale@xxxxxx
> From: Anne Wilson <anne@xxxxxxxxxxxxxxxx>
> Organization: UCAR
> Date: Wed, 14 Feb 2001 11:04:36 -0700
> To: Jared P Bostic <jpbostic@xxxxxxxxxxxxxxxxxxxxx>
> Cc: mwdross@xxxxxxxxxxxxxxx, Jessica Thomale <jthomale@xxxxxxxxxxxxxxxxxx>,
> ldm-users@xxxxxxxxxxxxxxxx
> Subject: 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
> me?
>
> Anne
> --
> ***************************************************
> Anne Wilson UCAR Unidata Program
> anne@xxxxxxxxxxxxxxxx P.O. Box 3000
> Boulder, CO 80307
> ----------------------------------------------------
> Unidata WWW server http://www.unidata.ucar.edu/
> ****************************************************
