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

Re: 20010418: ldm connection problem (fwd)

Tom McDermott wrote:
On Wed, 18 Apr 2001, anne wrote:

> What was the outcome of your test?  The LDM groups requests together
> based on fully qualified domain name.  So, both requests to vortex will
> be grouped into a single request handled by a single connection.  In
> theory, removing one line should not have made a difference.  Did it?

It was a just a hunch that the overlapping request might have confused the
ldm server on vortex.  But that proved not to be the case.

> What does the log say on graup1?  And, which versions of the LDM are you
> each running?  Tom, are you running pqexpire?

Anne,

Frank Colby notified me that he would be away from Friday thru Monday so
you may not get a response from him until then.  I am running ldm 5.1.3,
but this problem, as mentioned, also existed last year, when I was running
v 5.0.10 .  (See http://unidata.ucar.edu/cgi-bin/mfs/65/3706?45#mfs and
http://unidata.ucar.edu/cgi-bin/mfs/65/3723?29#mfs ).  I am not running
pqexpire now (and have not run it since I started running 5.1.1 beta), but
of course I was running it under 5.0.10 and earlier.
 

Hi Tom,

Thank you for refreshing my memory on this.  I see that Colgate was running an old version - is it possible that Colgate upgraded from 5.0.6 and tried to connect?   Or, do you think that Colgate simply stopped trying to feed from you?
 

 
> One possibility that would explain all the RECLASS messages is if the
> clock on graup1 was wrong, causing it to continually request data from
> the wrong time.  But, I guess the times work for the feed from Rutgers to
> graup1, is that correct?

I understand from Frank that he has had no problems with Rutgers.

> The only other anomaly I see in what you've sent is that the RECLASS
> entry in Tom's log looks incomplete - no pattern shows up for the UNIDATA
> feed.   Maybe long lines were simply cut off, or maybe it's not handling
> the dual entries properly...

The lines are truncated in my log.  Here is an excerpt from our last try
today after the unecessary DDPLUS pattern was commented out:

Apr 18 19:14:20 vortex graupl[29755]: Connection from graupl.uml.edu
Apr 18 19:14:20 vortex graupl(feed)[29755]: Starting Up:
20010418185219.376 TS_ENDT {{UNIDATA,  "(^[A-OQ-X])|(^[YZ].[^HU])"}}
Apr 18 19:14:20 vortex graupl(feed)[29755]: topo:  graupl.uml.edu UNIDATA
Apr 18 19:14:20 vortex graupl(feed)[29755]: RECLASS: 20010418181133.242
TS_ENDT {{UNIDATA,  "(^[A-OQ-X])|(^[YZ].[^HU])"}}
Apr 18 19:14:20 vortex graupl(feed)[29755]: RECLASS: 20010418181133.307
TS_ENDT {{UNIDATA,  "(^[A-OQ-X])|(^[YZ].[^HU])"}}
Apr 18 19:14:20 vortex graupl(feed)[29755]: RECLASS: 20010418181133.360
TS_ENDT {{UNIDATA,  "(^[A-OQ-X])|(^[YZ].[^HU])"}}
Apr 18 19:14:20 vortex graupl(feed)[29755]: RECLASS: 20010418181133.424
TS_ENDT {{UNIDATA,  "(^[A-OQ-X])|(^[YZ].[^HU])"}}
Apr 18 19:14:20 vortex graupl(feed)[29755]: RECLASS: 20010418181133.474
TS_ENDT {{UNIDATA,  "(^[A-OQ-X])|(^[YZ].[^HU])"}}
Apr 18 19:14:20 vortex graupl(feed)[29755]: RECLASS: 20010418181133.520
TS_ENDT {{UNIDATA,  "(^[A-OQ-X])|(^[YZ].[^HU])"}}
Apr 18 19:14:20 vortex graupl(feed)[29755]: RECLASS: 20010418181133.571
TS_ENDT {{UNIDATA,  "(^[A-OQ-X])|(^[YZ].[^HU])"}}
Apr 18 19:14:20 vortex graupl(feed)[29755]: RECLASS: 20010418181133.655
TS_ENDT {{UNIDATA,  "(^[A-OQ-X])|(^[YZ].[^HU])"}}
Apr 18 19:14:20 vortex graupl(feed)[29755]: RECLASS: 20010418181133.707
TS_ENDT {{UNIDATA,  "(^[A-OQ-X])|(^[YZ].[^HU])"}}
 

Thanks - this looks better.  Looks like Frank is running with only one request line now.
 
Here is what else I tried today.  I thought I would install the sparc
binary version which Unidata supplies, which is v 5.1.2 .  Unfortunately,
I forgot that I can't use the binary versions, because support for gdbm
and pqsurf got eliminated aways back for some reason, so I have to compile
from source.

The only minor clue that resulted from this abortive experiment was the
due to the fact that I had to remake my queues since the format changed
from 5.1.2 to 5.1.3 .  This had the effect of putting my ingest more than
1 hour behind (while the 12Z model runs were coming in), and I wasn't
getting any data at that point in time.  And presumably, I had no data <
61 minutes to provide to any host feeding from me.  At this point, graupl
connected to vortex and remained connected for about 5 minutes without
getting any RECLASS messages.  Then Frank shut it down again because he
wasn't getting any data coming in, assuming that it was the same problem:

Apr 18 16:19:16 vortex graupl[21948]: Connection from graupl.uml.edu
Apr 18 16:19:16 vortex graupl(feed)[21948]: Starting Up:
20010418161813.879 TS_ENDT {{UNIDATA,  "(^[A-OQ-X])|(^[YZ].[^HU])"}}
Apr 18 16:19:16 vortex graupl(feed)[21948]: topo:  graupl.uml.edu UNIDATA
Apr 18 16:24:16 vortex graupl(feed)[21948]: nullproc(graupl.uml.edu): RPC:
Unable to receive
Apr 18 16:24:16 vortex graupl(feed)[21948]: Exiting

Then after I went back to feeding from Cornell and my ingest caught up,
Frank reconnected and the RECLASS messages reappeared again (see the
19:14:20 example above).  So possibly the RECLASS messages may be
triggered by the vortex server attempting to transmit data to the graupl
server, rather than the REQUEST from graupl.  I'm speculating that since I
had no data to transmit at that time (16Z), the RECLASS phenomenon did not
occur at that instance.

The problem seems to have something to do with my server, since the
Colgate host that I referenced from the support archive also experienced
this problem.  But it does not affect all hosts feeding from vortex.
Currently I have 2 hosts feeding from vortex, catwoman.cs.moravian.edu and
blizzard.weather.brockport.edu here at Brockport, and they have never had
this problem. (Also the met-05.oswego.edu host has connected to vortex in
the recent past without any problems.)


This is interesting.  It certainly seems to indicate that the problem happens when vortex tries to serve data to graup1.

Do you have any idea which LDM version Frank is running?

 

I have an ALLOW line for any unidata host in my ldmd.conf in case you want
to try a feed experiment.  However, I will be leaving for the day now.

I will indeed give this a try.  Also, I'm going to talk with some of my colleagues about this.  I will get back to you.

Anne

 

Tom
------------------------------------------------------------------------------
Tom McDermott                           Email: address@hidden
System Administrator                    Phone: (716) 395-5718
Earth Sciences Dept.                    Fax: (716) 395-2416
SUNY College at Brockport

-- 
***************************************************
Anne Wilson                     UCAR Unidata Program            
address@hidden                  P.O. Box 3000
                                  Boulder, CO  80307
----------------------------------------------------
Unidata WWW server       http://www.unidata.ucar.edu/
****************************************************