[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20040630: 20040630: potential LDM/pqact problem on OSF/1
- Subject: 20040630: 20040630: potential LDM/pqact problem on OSF/1
- Date: Wed, 30 Jun 2004 10:10:22 -0600
>From: Steve Emmerson <address@hidden>
>Organization: University of Washington
>Keywords: 200406241954.i5OJsCWb010248 LDM PIPE Perl
Steve,
>After perusing the pqact(1) code, I've concluded that a PIPE-ed
>data-product could be smaller than a FILE-d data-product if the computer
>were heavily loaded. In order to avoid spending too much time trying
>to pipe data to a slow decoder, the pqact(1) process sets a timeout
>alarm. The default timeout is 60 seconds but can be overridden by a
>command-line option. If the associated SIGALRM is received before the
>data is written, then pqact(1) will abandon the attempt and log this
>fact in the LDM logfile.
I have not gotten the impression that the system David is doing the
processing on is loaded, but, then again, this issue did not come up.
One thing that doesn't fit with the SIGALRM scenario is David's comment
that he will see truncated files created by the Bourne shell script
I sent him (ldmfile.sh) when it is located after the running of his
Perl script in the pqact.conf file on the UW OSF/1 macine. I guess
that _if_ the Perl script sent the process load sky high, then the
Bourne shell script could then be operating under the same conditions
that would cause a SIGALRM. This seems like a stretch, but I guess
that it is possible.
>I'm waiting for David to tell me if the LDM logfile contained any relevant
>messages.
OK.
Cheers,
Tom
--
+-----------------------------------------------------------------------------+
* Tom Yoksas UCAR Unidata Program *
* (303) 497-8642 (last resort) P.O. Box 3000 *
* address@hidden Boulder, CO 80307 *
* Unidata WWW Service http://www.unidata.ucar.edu/*
+-----------------------------------------------------------------------------+