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

[#RFZ-122547]: Re: Re: More data to send from CMA

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: [#RFZ-122547]: Re: Re: More data to send from CMA
  • Date: Tue, 10 Apr 2007 12:28:16 -0600
Manuel,

> ... but looks like CMA is getting all ECMWF data via NCAR. Looking at
> address@hidden:logs/ldmd.log, there are lots of nasty messages:
> 
> Apr 10 15:16:22 tgn01 tigge-ldm.ecmwf.int[11043] ERROR: readtcp(): EOF
> on socket 4
> Apr 10 15:16:22 tgn01 tigge-ldm.ecmwf.int[11043] ERROR: one_svc_run():
> RPC layer closed connection
> Apr 10 15:16:22 tgn01 tigge-ldm.ecmwf.int[11043] ERROR: Disconnecting
> due to LDM failure; Connection to upstream LDM closed
> 
> It seems we are not quite there yet. Any clues ?

If you look for corresponding entries in the log file for ECMWF's
LDM, then you will probably see messages indicating that the
upstream LDM process at ECMWF was unable to send a data-product
or flush the connection to CMA.  Basically, this means that the
TCP layers were unable to keep open the connection between ECMWF
and CMA.

Incidentally, I'm not surprised that ECMWF products reach CMA
faster via NCAR than they do directly.  NCAR is on a network
superhighway; if the products heading directly to CMA don't
use that superhighway, then they can arrive later than products
that go to NCAR and are then sent to CMA.

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: RFZ-122547
Department: Support IDD TIGGE
Priority: Normal
Status: On Hold