|
midrange.com
Thanks for the help guys - I stumbled on the answer by luck today when a
job wouldn't end after I stopped the Apache server.
One of the CGI modules was occasionally getting itself in to a loop. The
problem has been there for a while before we migrated to Apache but the
original HTTP server used to automatically trigger a "SIGKILL" when the job
started to eat up the CPU. We never managed to identify the cause of the
problem. I was mistaken in my belief that the job was on TIMW status, must
have been the 6am problem!
The Apache server doesn't seem to do the same thing so the job keeps
looping even after an ENDTCPSVR *HTTP. My thinking was that this command
would trigger a kind of *IMMED end to the server but it's obviously a
*CNTRLD type of end so the QZSRCGI instance just carries on running until
the request has completed.
We've now fixed the problem but I'm now wondering whether there's a way
that we can configure the Apache server to abort looping jobs in case we
ever get any more???
Regards
Michael Bailey
Mel Rothman
<mel@xxxxxxxxxxxx To: web400@xxxxxxxxxxxx
om> cc:
Sent by: Subject: [WEB400] Re: An
instance of QZSRCGI won't end after ENDTCPSVR
web400-bounces@mi
drange.com
01/07/2004 16:18
Please respond to
Web Enabling the
AS400 / iSeries
You might want to do some performance testing before changing your CGI
programs
to seton LR. Personally, I wouldn't make that change. I would continue to
try
to find out why some CGI jobs don't end in a timely manner. Since the
problem
did not occur with the classic server over a long period of time, I, as you
do,
would suspect the powered by Apache server implementation.
Also, you mentioned that all PTFs are up to date. However, there is a PTF
for
problem with persistent CGI jobs not ending properly (may or may not be
your
problem and you may or may not have it applied and you may or may not be
using
persistent CGI). Here is the description from PTF SI10682 for V5R2
5722-DG1
(superseded by SE16064):
HTTPSVR Apache Persistent CGI Jobs Not Ending Correctly
DESCRIPTION OF PROBLEM FIXED FOR APAR SE12286 :
-----------------------------------------------
When multiple persistent CGI programs are running, and a new
persistent CGI program is called with a time out value that is
shorter than all of the others, the call to the CGI appears to
be hung. An MCH3601 error is written to the job log, and a
response is never returned back to the browser.
CORRECTION FOR APAR SE12286 :
-----------------------------
A change was made to the code to handle the timer situation.
CIRCUMVENTION FOR APAR SE12286 :
--------------------------------
If any CGI program is using the HTTimeout header value to set
the time out value of the program, make sure it is longer than
the default persistent CGI time out value being used by the HTTP
server. See the documentation for the PersistentCGITimeout
directive for more information.
Mel Rothman, CGIDEV2 Author
Mel Rothman, Inc.
michael.bailey@xxxxxxxxxx wrote:
> Thanks for getting back to me Bob, I've been working with the AS/400
since
> it was first released and my first rule of support has always been to
> gather as much information as possible before cancelling a crashed app.
as
> you may not get a chance until it happens again. Have I ever bothered to
> check exactly which procedure and line number that the CGI app. is
sitting
> on - NO! Could be because I'm just not myself at 4am!
>
> You're right though, the CGI program doesn't set on LR. However, in 2
> years it's never been a problem so perhaps Apache has unearthed something
> that the old server tolerated (I found a few of those when I was
testing).
> As a catch-all I probably need to do both of your suggestions in case the
> job is just stuck but not receiving any page requests. I'll give it a go
> when I get back from vacation next week.
>
> Cheers
> Michael
>
>
>
>
>
>
> "Bob Cozzi" <cozzi@xxxxxxxxx>
> Sent by: web400-bounces@xxxxxxxxxxxx
> 01/07/2004 14:53
> Please respond to Web Enabling the AS400 / iSeries
>
> To: "'Web Enabling the AS400 / iSeries'"
<web400@xxxxxxxxxxxx>
> cc:
> Subject: RE: [WEB400] An instance of QZSRCGI won't end
> after ENDTCPSVR
>
>
> Michael,
> Two things to try.
> 1) Are you setting on LR in those CGI apps or not? If not, then they
might
> be sitting waiting for something that will never get there, and
eventually
> they time out. You might want to try the SHTDN opcode; testing for an
> endjob
> request. If that happens, set on the LR indicate to cause the program to
> end
> when RETURN is issued. Of course that would only happen if someone hits
> the
> page and the CGI program is called.
> 2) The other thing is to write a little tool that lists all the jobs for
> the
> server. Then go through each one in a CL program and issue an ENDJOB
> LOGLVL(0) and perhaps add the OPTION(*IMMED) if that's okay with you. To
> get
> the list of jobs use the CrtJobList() API in the RPG xTools or call the
> QUSLJOBI API and iterate through the list.
> -Bob
>
>
_______________________________________________
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
