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

Re: 20010421: Thoughts on LDM reclasses

Tom and Anne,

In general, I think the reclass should happen once when the allow
is a subset of the request. However, each time an old product is received
(and we saw that uml's clock was 3 minutes off) it has to reclass
again, and then renegotiate. But, now we have an added problem-
in that 2 computers are calling UNIDATA something different.

Since the reorganization of feedtypes occurred in 5.0.10
(To add the NEXRAD and other feedtypes at the same time NPS was taken out
of the unidata bit mask), we probably need to urge everyone to upgrade to 
at least that release to eliminate the potential problems in the feedtypes.
Of course, the queue rework in 5.1.x is much better, so I would hope
that all sites would upgrade to the latest release.

Thanks for helping us track this down!

Chiz

On Tue, 24 Apr 2001, Tom McDermott wrote:

> On Tue, 24 Apr 2001, anne wrote:
> 
> >       > The thing I don't understand is why this mismatch resulted
> >       in a cascade of
> >       > RECLASS messages, instead of just a single RECLASS
> >       message.  The latter I
> >       > have seen many times when connecting to an ldm server, but
> >       the former
> >       > never.  Perhaps the RECLASS was considered unacceptable to
> >       the ldm server
> >       > on graupl.  Did the RECLASS messages show up in your ldmd
> >       logs last week?
> >
> > I think it's much more common for RECLASS messages to appear when there's
> > a timing problem - a product is either requested or served that has an
> > unsatisfactory time stamp.  In that case, the two hosts can quickly
> > renegotiate what to serve, hence only one or a few RECLASS messages
> > appear.  However, in this case, graup1 was continually asking for a feed
> > type that vortex was unwilling to serve.   This rarely happens, as sites
> > usually have an agreement beforehand about what will be served and
> > configure their LDMs appropriately.    Unlike with the time stamp
> > problem, the two hosts have no automated way to renegotiate this.
> 
> No, I wasn't referring to the time-based RECLASSES (such as when the
> client requests data > 61 min. old), but to the RECLASSes that occur on
> connection, where the client will request X and the server will RECLASS
> and serve Y, which is some subset of X.  In all of the cases that I have
> seen except this one, the client then accepts the subset Y, and the feed
> then proceeds normally.
> 
> Tom
> 
> 
>