Yes, they are the old parameters. I Realized that once Henrik posted the
solution and said I thought "duh". It's been so long since I debugged on a
system where I had to worry about multiple jobs starting up at once (mainly
from using SSI directives on each page that each call CGI programs).
Normally I get by buy guessing which job to start a service job on. :)
The issue with the solution above is that if I go to a page that has
multiple CGI SSI directives, the server jobs fail. The only thing they out
put is a short dump that looks like this:
User Trace Dump for job 119117/QTMHHTTP/BVSTESTV4. Size: 16382K, Wrapped 0
times.
--- 12/19/2012 06:33:41
---
00000063:844136
Application............:
HTTP
Instance...............:
BVSTESTV4
System.................: I5.BVSTOOLS.COM
Start date/time........: Wed Dec 19 06:33:41
2012
00000063:844176 isAsciiCcsid() - ccsid 37 is not an ascii
ccsid
00000063:844192
THREAD ID:TIMESTAMP
DATA
--------------------------------------------------
00000063:844224 CGI/NTS: Trace level set to 'VERBOSE' for this
process.
00000063:844240 CGI/NTS:
Apache/2.0.63
00000063:844248 CGI/NTS: Module Magic Number:
20020903
00000063:844272 N helper job for instance
BVSTESTV4
00000063:844416 fillBuffer(), received 119 bytes and 0
descriptors
00000063:844440 receiveData(), returned 36 bytes of
data
00000063:844456 receiveData(), returned 83 bytes of
data
00000063:846016 fillBuffer(), control pipe receive error with errno
0
00000063:861936 apr_dump_trace(): dump for job
119117/QTMHHTTP/BVSTESTV4
TRCTCPAPP Output
The main server job then outputs HTP8080:
Message ID . . . . . . : HTP8080 Severity . . . . . . . : 20
Message type . . . . . : Diagnostic
Date sent . . . . . . : 12/19/12 Time sent . . . . . . :
06:36:05
Message . . . . : HTTP Server instance BVSTESTV4, hot backup
takeover.
Cause . . . . . : The primary job for HTTP Server instance BVSTESTV4
failed.
Receipt of this message usually indicates there is a problem that needs
to
be
resolved.
Recovery . . . : Check for previous messages in QSYSOPR for HTTP
server
instance BVSTESTV4 to identify the cause of
failure.
Technical description . . . . . . . . : The hot backup server job is now
the
primary job and is serving client requests. Also, a new hot backup
server
job has been created
automatically.
Using the CGI SSI directives it's like getting multiple requests at once,
so normally more CGI jobs would start to handle the extra requests. And on
the old CERN web servers if you were running maxat 1, it would simply queue
the requests and take them one at a time.
But with Apache it seems that isn't the case, and when you specify 1 max
job, and it gets multiple requests at once and it can't start new CGI jobs
it crashes and dies.
So, it's not quite the exact equivalent of -maxat 1. But, it is usable to
a point.
Make sense? It would be nice to have the same workings as the old CERN
server.
Brad
www.bvstools.com
On Tue, Dec 18, 2012 at 5:24 PM, Scott Klement <web400@xxxxxxxxxxxxxxxx>wrote:
hi Brad,
Have you considered using SEPs to debug your web applications? This
makes them easy to debug even if there are many jobs running for each
server (which is something I have to do frequently.)
As for -minat/-maxat... aren't those for the old (pre-Apache) HTTP
server? I may be wrong about that, as I haven't used them. But, I have
not run across these, even on other platforms (where I use Apache's
command-line args much more often).
On 12/18/2012 4:16 PM, Bradley Stone wrote:
I seem to remember a while back that IBM let us know that using using
minat
and maxat before V6R1 these were really ignored.
Or I could be confusing it with the threads settings.
Anyhow, I'm starting my webserver with -minat 1 -maxat 1 and I will be
darned if more jobs CGI don't start up when I don't want them to. Makes
debugging quite tricky.
--
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.
midrange.com
