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

20040929: ldm 6.1 - change in "-m" behavior



Hi Harry,

> To: address@hidden
> From: Harry Edmon <address@hidden>
> Subject: ldm 6.1 - change in behavior
> Organization: University of Washington
> Keywords: 200409282351.i8SNpxHP002118 LDM 6.1

The above message contained the following:

> I start my rpc.ldmd processes with a "-m 10800".  In the past if I 
> started the ldm with a new queue file it would get data 3 hours old.  I 
> just tried this with the new ldm, it seems to have done it for some of 
> the feeds, but not all.  Is this a bug?  The first 100 lines of my 
> ldmd.log are attached.

You've been relying on undocumented (or, at least, badly documented)
behavior.  The "-m max_latency" option specifies the maximum latency
that a downstream LDM 5 will accept before responding with a RECLASS
reply.  It also specifies how far back to request data-products
unless overridden by the "-o toffset" option (which must be less than
"max_latency").  The value used for this "backlog" request will be
adjusted, however, by the creation-time of the most recent data-product
in the product-queue that matches the selection criteria -- but only
if the creation-time is more recent than the current time minus
max_latency.

If the "-o toffset" option is used, then the backlog time isn't adjusted
by anything in the product-queue.

I know, this is horribly convoluted.  I tried to keep the original logic.

If you absolutely, positively must get data-products from 3 hours ago --
even if they're already in the product-queue -- then use the following:

    rpc.ldmd -m 10801 -o 10800 ...

Regards,
Steve Emmerson


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.