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

20031121: 20031121: LDM and viability of multiple instances of pqact

Art,

When making pqact.conf changes, this underscores the use of 
"ldmadmin pqactHUP" to send the -HUP to pqact as to not have to shut
down the ldm.

Unfortunately, the same feature doe snot exist at this time for changes
to ldmd.conf, which requires a restart. 

The solutions would be to allow ldmd.conf changes without an LDM restart,
or, run pqact process outside of the "EXEC" lines of ldmd.conf as
a workaround, so that pqact processes did not end with an ldmadmin stop/start.
This would unfortunately mean that 1) the user would have to shut down the
pqact processes separately when remaking a queue, etc, and 2) the pqact
process would not receive the signals of the rpc.ldmd process group
which notify when a new product has arrived, so that you would rely
on the -i option of pqact (of course, if pqact is behind, that is moot).

I have 9 seperate pqact processes running here on our development
machine, and have less problems now with pqact's falling behind as
bogus timestamps on the CRAFT feed products causing request dropouts
on restarting the ldm.

Steve Chiswell





>From: "Arthur A. Person" <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200311212236.hALMaPEH001973

>Steve,
>
>On Fri, 21 Nov 2003, Steve Emmerson wrote:
>
>> Art,
>> 
>> Chiz wrote:
>> 
>> > When pqact starts up, it is looking at the end of the product queue
>> > (unless the -o option is used). So, if you restart the LDM, and pqact
>> > had fallen behind in its processing of the queue, you would lose that
>> > state information on restart- eg, your pqact output would be skipping
>> > those products bewteen where it was when it was shut down and where
>> > the end of the queue is when it restarts. This would happen anytime
>> > pqact was behind on processing (single or multiple pqact instances).
>> >
>> > I'll CC Steve Emmerson in case he has a different view.
>> 
>> I think Chiz is ritht on.
>> 
>> This is a good argument for restarting the LDM only during data lulls.
>
>Wow, I guess I was under the (wrong) assumption that stopping and
>restarting the LDM was pretty risk-free, meaning it would stop where it
>was and restart where it left off.  So, on a busy system (where pqact is
>always running a little behind in the queue), one would always lose data?
>If this is the case, then is the only option to use "pqact -o" to prevent
>it, and if so, wouldn't that mean it has to re-read a lot of products
>previously processed depending how far back it looked?  Has anyone ever
>considered adding some sort of state to where pqact left off so there
>isn't so much guess-work in LDM restarts?
>
>                                  Thanks...
>
>                                    Art.
>-- 
>Arthur A. Person
>Research Assistant, System Administrator
>Penn State Department of Meteorology
>email:  address@hidden, phone:  814-863-1563
>