Re: pqing stopped inserting when downstream requested feed

Good morning,

Our problem is a pqing process dies on the upstream server.  Has anyone feed
products using pqing -P <port number> using a feed unrelated to NOAAPort?
If so, have you had a similar problem?

Is there better way to get the NOAAPort feed into LDM?

James,

Do you use pqing -P <port number> for the IDD feed or do you request by
setting up an upstream server in the ldmd.conf?

Thank you for your response,

Jessica

-- 
Jessica M. Thomale
Oklahoma Climatological Survey
E-mail: jthomale@xxxxxx
Mail: 100 E. Boyd, Suite 1210 Norman, OK 73019-1012
Phone: (405) 325-7809
Fax: (405) 325-2550

> From: "James D. Marco" <jdm27@xxxxxxxxxxx>
> Organization: UCAR/Unidata
> Date: Wed, 14 Feb 2001 08:19:43 -0500
> To: ldm-users@xxxxxxxxxxxxxxxx
> Subject: Re: pqing stopped inserting when downstream requested feed
> 
> Hi all,
> It sort of looks like a socket problem, as Mike mentioned.
> The occasional crashes could be from an occasional port scan that we
> all see. 
> The standard internet IDD stuff does not seem to have
> this problem. I feed locally from one machine to 6 others with no
> problems from the LDM...a mixed bag of 5.1.2 and 5.1.3 versions.
> Apparently this is NOAAPORT specific.
> jdm              
> 
> Jared. Sorry. You will get this note twice.  The reply button
> doesn't pick up this mailing list, and I forgot to change it.
> 
> At 06:54 AM 2/14/01 +0000, you 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
>> 
>> 
>> -- 
>> ----------------------------------------------------
>> Jared P. Bostic
>> Oklahoma Climatological Survey Operations Center
>> Email:    jpbostic@xxxxxxxxxxxxxxxxxxxxx
>> USmail: 100 East Boyd, Suite 1210, Norman, OK  73019
>> Phone: (405) 325-3231 / Pager: (405) 530-4478
>> Fax:   (405) 325-2550
>> ----------------------------------------------------
>> 
>> 
>> 
>> On Wed, 14 Feb 2001 mwdross@xxxxxxxxxxxxxxx wrote:
>> 
>>> 
>>> Jessica,
>>> 
>>> I too am ingesting NOAAPORT data using the pqing -P  <port number> directly
>>> from our Unisys NOAAPORT
>>> Receive System.  I have occasional, unexplained problems with the pqing
>>> just stopping, not receiving data via the socket.
>>> Although I haven't related it to another LDM feeding from this system. In
>>> fact, if I am correct the pqing has little
>>> to do with feeding downstream sites, rather the rpc.ldm  does much of that,
>>> I believe.
>>> 
>>> I am running 3 different pqing processes, with the NRS system filtering
>>> the  WMO headers to mimic the Unidata
>>> feed types for compatibility.  I am running Linux Mandrake 7.1 on this
>>> system, but the problem also occurred on our
>>> AIX 4.3 RS/6000 when I tested on that platform a few months ago, so I don't
>>> think the problem is platform specific.
>>> 
>>> * DDPLUS|IDS feed type
>>> * HDS feed type
>>> * NNEXRAD feedtype
>>> 
>>> Almost always 1 will quit while the others continue.  I have felt like the
>>> problem is more likely with the Unisys NRS software, thats
>>> why I haven't brought it to the attention of the LDM users.  But it sounds
>>> like you may be having a similar problem. What type of
>>> NRS system are you using?
>>> 
>>> I have had much better success when I run just 1 pqing process and ingest
>>> everything as WMO.  But this
>>> doesn't suit our current environment.
>>> 
>>> There may be a bug in the way pqing handles socket connections?  I would
>>> curious to know how Unidata is
>>> feeding there top level relay sites from the NRS systems? If they are using
>>> the socket connection?
>>> 
>>> If I figure anything out from this end I will pass it along.
>>> 
>>> Mike Dross
>>> Duke Energy
>>> 
>>> 
>>> 
>>> 
> 
>>> Jessica Thomale
> 
>>> <jthomale@xxxxxxxxxxxx        To:
> <ldm-users@xxxxxxxxxxxxxxxx>, <support@xxxxxxxxxxxxxxxx>
>>> ou.edu>                       cc:
> 
>>> Sent by:                      bcc:
> 
>>> owner-ldm-users@unidat        Subject:     pqing
> stopped inserting when downstream requested feed
>>> a.ucar.edu
> 
>>> 
> 
>>> 
> 
>>> 02/13/2001 09:01 PM
> 
>>> 
> 
>>> 
> 
>>> 
>>> 
>>> 
>>> 
>>> Good Evening,
>>> 
>>> We are requesting a NOAAPort feed using pqing -P <port number> on a ldm
>>> server that serves this data to downstream ldm hosts.
>>> 
>>> Today, when the downstream ldm server started requesting a feed from the
>>> upstream ldm server, one of the pqing processes (importing the NWSTG
>>> channel) mysteriously died. I attached a copy of the two ldmd log files.
>>> 
>>> Both machines are running ldm-5.1.3. The upstream server is a FreeBSD
>>> (version 4.2) box.  The downstream server is a Solaris/x86 box (version 8).
>>> 
>>> There appears to be a problem with the product queue on the upstream ldm
>>> server.
>>> 
>>> Has anyone experienced any problems similar to this problem?
>>> 
>>> Thank you in advance for any assistance,
>>> 
>>> Jessica
>>> 
>>> --
>>> Jessica M. Thomale
>>> Oklahoma Climatological Survey
>>> E-mail: jthomale@xxxxxx
>>> Mail: 100 E. Boyd, Suite 1210 Norman, OK 73019-1012
>>> Phone: (405) 325-7809
>>> Fax: (405) 325-2550
>>> 
>>> 
>>> (See attached file: ldmd.log.downstream)
>>> (See attached file: ldmd.log.upstream)
>>> 
>>> 
>> 
>>