Re: [WEB400] CGIDEV2 strange happenings

["Nathan M. Andelin" <nandelin@xxxxxxxxxxxxxxxxxxx>]

> From: "Michael Skvarenina" <mskvarenina@usa.net>
> We don't fully understand the technicalities of how RPG
> programs are "called" via the HTTP server...

Browsers connect to a thread in the HTTP Server, which forwards the request
to one of the HTTP Server BCI jobs.

The HTTP Server thread and the BCI Job communicate with one another via
socket.  The thread waits, apparently indefinately for a response.  While
waiting, the thread won't service any more browser connections.

The BCI Job calls your CGI program which returns a response to the HTTP
Server thread.  If the CGI program runs in the *caller, or a named
activation group, then the CGI program remains active after the first call.
Allocated memory is neither released nor reinitialized afterwards, unless
explicitly coded, for example.

If the CGI program is halted by an exception, the corresponding HTTP Server
thread simply waits.  However, the browser won't wait indefinately.  If the
browser drops the connection, the HTTP Server thread apparently remains
locked afterwards, which reduces the number of threads available to support
clients.

If a BCI job is unavailable at the moment a new request is made, then a new
BCI Job is automatically started.  The maximum number of BCI jobs eventually
started is controlled by the number of concurrent users, and the
MaxActiveThreads directive, which overrides the settings of the CHGHTTPA
command.

Since the HTTP Server indiscriminately balances CGI workload across the pool
of BCI Jobs, an instance of ALL your CGI programs will eventually become
active in each one of the BCI jobs, unless the CGI programs run under a new
activation group, or the HTTP Server is periodically shut down.

> but we suspect that when a program blows up,
> it's memory isn't initialized within the instance it
> was running in, and the next incoming request
> on that instance returns the bogus HTML.

While I don't know what causes the bogus HTML, CGI programs that "blow up",
tend to eventually destabilize the HTTP Server.

To solve that problem, I use a framework in which the RPG program is
submitted from the command line and waits for new requests on a queue,
rather than being called by one of the BCI Jobs.  An exception in the RPG
program has no impact on the HTTP Server.  It also enables you to control
the number of running instances of your application.

Nathan M. Andelin
www.relational-data.com