RE: MCH74A5 - The Java Virtual Machine has ended

In fact I do use a custom data queue for a PDF generation java class
since that class requires the "java.awt.headless=true" property and so
must run in a separate job, as discussed in a previous thread.

This could, if a need is a must, be done for the Xalan class, but it is
hoped that it will fail critically only when testing a mal-formed
style-sheet.

But this does not alter the fact that whatever job the class ( or any
other class that may kill the JVM ) runs in will require operator
intervention to end the job as opposed to cancelling a message as
normally occurs. At least the HTTP server will raise a new thread
automatically, whereas a custom restart mechanism must be applied to a
data queue server.

I guess it means being more circumspect about unleashing java from RPG
whenever the opportunity may arise.

Peter



-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Nathan Andelin
Sent: Tuesday, 23 June 2009 7:39 a.m.
To: RPG programming on the IBM i / System i
Subject: Re: MCH74A5 - The Java Virtual Machine has ended

From: Scott Klement
On my system, anyway, if a job fails, Apache starts a new one to
take it's place.

Perhaps, up to a configuration limit.

And since you don't get the same job on every call, you
can't rely on anything to have previously been set up in the job,
anyway.

Right. That's the way CGI works. But I'm not sure how that might apply
in this case. Maybe Peter can answer if the RPG-Java process relies on
an initialization step or other type of state being established before
handling HTML-PDF conversion requests. If so, that would be a good
reason to communicate over a data queue.

So why would it maroon anything?

There have been quite a few reported cases where an errant CGI program
eventually locks up an entire HTTP server. The multi-threaded server job
dispatches requests to CGI server jobs - and waits. The next request
for the CGI program goes to the next available CGI process - and waits.
Eventually a thread configuration limit is reached, and no additional
CGI server jobs are started, and the HTTP server job locks up. That
seems to be the usual scenario, however it seems that there have also
been cases reported where an errant CGI process locks up the HTTP server
to the degree that ENDJOB is the only option.

Nathan.