[CONDUIT #WJF-152207]: Not getting CONDUIT data either

Hi Scott,

re:
> Here's what I see in the log:
> Oct 20 12:54:40 ldm idd.unidata.ucar.edu[16052] ERROR: readtcp(): EOF on 
> socket 4
> Oct 20 12:54:40 ldm idd.unidata.ucar.edu[16051] ERROR: readtcp(): EOF on 
> socket 4
> Oct 20 12:54:40 ldm idd.unidata.ucar.edu[16051] ERROR: one_svc_run(): RPC 
> layer closed connection
> Oct 20 12:54:40 ldm idd.unidata.ucar.edu[16051] ERROR: Disconnecting due to 
> LDM failure; Connection to upstream LDM closed
> Oct 20 12:54:40 ldm idd.unidata.ucar.edu[16051] NOTE: LDM-6 desired

This typically indicates that there was a network connection problem somewhere
between your machine and idd.unidata.ucar.edu or at your machine or on
the real-server node of the idd.unidata.ucar.edu cluster that was attempting
to handle your REQUEST(s).

re:
> These are the last messages in the log about this.
> 
> My three feeds from idd.unidata.ucar.edu are:
> 
> 1. CONDUIT "gfs.*pgrb2"
> 2. CONDUIT "nam.*awip12"
> 3. IDS|DDPLUS ".*"

OK.

re:
> I'm not sure if the problem is fixed, I got some of the gfs.2014102012
> files and some of the nam.2014102018 files.

As part of the troubleshooting for the UNIWISC problem reported by
another user, I restarted the LDM on the idd.unidata.ucar.edu node that
was handling REQUESTs from the machine the other user was REQUESTing
from.  I just checked, and this node was and still is the one that is
also servicing your CONDUIT feed REQUESTs.  Since data started flowing
to you again, it seems likely that the LDM restart on the node corrected
the problem you were experiencing.

re:
> My forward and reverse DNS is working.  I just checked it.  My FQDN is:
> ldm.cicsnc.org IP: 198.85.226.20

OK, thanks.

re:
> Is there some alternative server I should list in case of situations
> like this?  Thanks for your help,

There is a possibility that your machine was added to the set of ALLOWs
on one or more of the following top level IDD relay servers:

idd.meteo.psu.edu
idd.tamu.edu

You can test to see if you are ALLOWed to REQUEST CONDUIT from these
relays as follows:

<as 'ldm' on ldm.cicsnc.org>
notifyme -vl- -f CONDUIT -h idd.meteo.psu.edu

and
notifyme -vl- -f CONDUIT -h idd.tamu.edu

The other thing to know is that all feed REQUESTs to idd.unidata.ucar.edu
will be directed to the same real-server backend of the cluster as long
as there is any active connection to the downstream within the past
two minutes.  This means that in situations like the one you reported 
you could stop your LDM for a period greater than or equal to two minutes
and then restart.  It would be likely that your new feed REQUESTs would
be sent to a different real-server backend by the cluster director, and
your feed might resume normally.  It is also possible that a simple 
LDM restart on your end might have resulted in resumption of data flow
(I should have asked you if you tried an 'ldmadmin restart' in my
first reply).

Please note that we are not saying that needing to stop/restart an LDM
is something that needs is routine/normal.  In fact, most connections
remain active for very long periods of time (e.g., months) without
any problems.  In the rare even that a connection becomes "stale"
(I can think of no better way to describe the situation), restarting
or stopping, pausing, and then restarting a downstream LDM might help
in getting things running smoothly again.

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: WJF-152207
Department: Support CONDUIT
Priority: Normal
Status: Closed