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

Re: 20010421: Thoughts on LDM reclasses

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: Re: 20010421: Thoughts on LDM reclasses
  • Date: Tue, 24 Apr 2001 10:36:36 -0600 (MDT)
Tom,

When the downstream initiated its request, it was based on the time of the last
product received in that set that it had recieved, eg 2 minutes ago. The RECLASS
is initiated on the upstream end. The RECLASS time, and timestep are
configurations on the rpc.ldmd. When the downstream gets the reclass
message for the lesser subset, it will now have to go to its rpc.ldmd
ocnfiguration for maxtime and the timestep. Clearly, there is an additional
problem with the bitmask incompatibilities as opposed to another host asking for
MCIDAS when the upstream is allowing WMO. In that case, at least both computers
are calling WMO and MCIDAS the same things (as long as WMO is 0x0f on both
computers). The additional problem now is UNIDATA != UNIDATA. 

Steve Chiswell



On Tue, 24 Apr 2001, Tom McDermott wrote:

> On Tue, 24 Apr 2001, anne wrote:
> 
> > So you think that the new subset was based on product feed type rather
> > than time?  Because whenever a new connection is made, the same time
> > stamp negotiation has to occur.  If a downstream site comes up, it will
> > send a request for products within some time frame.  If that downstream
> > LDM has run before, it will request products starting from the time of
> > the most recent product in the queue.  Thus, if that site has been down
> > for more than an hour, it will request old data, causing a RECLASS to
> > occur.
> 
> Yes, I have seen the RECLASS occur on product feed type and not on (or
> perhaps as well as) time.  E.g., say a client REQUESTs UNIDATA and the
> server has an ALLOW for WMO (but not MCIDAS), then the server will send
> back a RECLASS message offering WMO.  Then the client accepts the FEED and
> things proceed normally.  I have seen this happen when there is some
> mismatch between the REQUEST and the ALLOW, but unfortunately I don't have
> an example from my logs.  I would have to search on tape and I don't have
> the time to do that.
> 
> Now what is strange about this:
> 
> Apr 18 18:54:12 vortex graupl[29096]: Connection from graupl.uml.edu
> Apr 18 18:54:12 vortex graupl(feed)[29096]: Starting Up:
> 20010418185219.376 TS_ENDT {{UNIDATA,  "(^[A-OQ-X])|(^[YZ].[^HU])"}}
> Apr 18 18:54:12 vortex graupl(feed)[29096]: topo:  graupl.uml.edu UNIDATA
> Apr 18 18:54:13 vortex graupl(feed)[29096]: RECLASS: 20010418175125.595
> TS_ENDT {{UNIDATA,  "(^[A-OQ-X])|(^[YZ].[^HU])"}}
> Apr 18 18:54:13 vortex graupl(feed)[29096]: RECLASS: 20010418175125.641
> TS_ENDT {{UNIDATA,  "(^[A-OQ-X])|(^[YZ].[^HU])"}}
> 
> is that graupl is requesting data which is less than 2 minutes old (1852
> vs 1854) but the RECLASS message sets the time stamp back to almost 63
> minutes behind (1751 vs 1854).  Of course, doing this means graupl will
> never accept data that old.  And each subsequent RECLASS only advances the
> time stamp by a fraction of a second, so no progress is made.  But why did
> the RECLASS set the time stamp back so far?
> 
> Tom
> 
> 
> 
> 
>