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

[Support #YQU-684227]: Re: [SCOOP-LDM] LDM problems with UFL feed

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: [Support #YQU-684227]: Re: [SCOOP-LDM] LDM problems with UFL feed
  • Date: Mon, 11 Sep 2006 10:00:54 -0600
Gerry,

[Please pass this on to John.]

> > I restarted LDM.  When starting up, it had a problem with the  counter,
> > and wouldn't start (this is quite common in my experience).

If that is the case, the the LDM was not stopped cleanly.  If and "ldmadmin 
start"
command indicates that the writer-counter of the product-queue is not zero and
no other LDM is running, then you should recreate the product-queue before 
starting
the LDM.

> > I created
> > a new product queue from scratch (because reseting the  counter
> > sometimes seems to leave the queue in a corrupt state, which  causes
> > problems further down the line).  And the files started  flowing again...
> >
> > There were no errors in the ldmd.log for Florida.
> >
> > Anybody got any tips they'd like to share about how to spot that  feeds
> > have stopped of their own accord?  Or should I restart LDM  periodically?

Downstream LDM processes are very persistent in their attempts to obtain
data-products from an upstream LDM (they will, for example, retry every minute
until they are serviced).  One way to see this is to put the relevant downstream
LDM into verbose logging mode (via a "kill -USR2" command) and check the log
file.  In our experience, the overwhelming majority of data-reception problems
of this nature are caused by the data-products simply not being injected into
the LDM network.

I am very interested in evidence to the contrary.  Please feel free to contact
me.


Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: YQU-684227
Department: Support IDD SCOOP
Priority: Normal
Status: Closed