java question

[Willem Grooters]

Environment: OpenVMS 7.3-2, Java 1.4-2 (for JDBC) and 5.0 (for webservice). Webservice is a multi-threaded Java application, accessing 2 RdB databases. Each thread may create a subprocess to do some work by the java exec statement.

When run interactively, multiple subprocesses can be created, regardless the thread that executes the exec statement.
When run as a detached process, it will start one subpriocess but any other attempts fails - regardless the thread.

User has no privileges.
No limits on number of detached processes, PRCLM set to 10.

What may be the cause of this behaviour?

[Bojan Nemec]

Willem,

Maybe some other quota problem? (FILLM, ASTLM, ENQLM)
Java probably use LIB$SPAWN for creating a subprocess.
The C documentation says that execl,execv etc... all use LIB$SPAWN. Java is written in C.

Maybe a quick test with a DCL procedure run by the same user with some lines like that:
$ spawn /nowait /notify wait 0:0:5

Or better simulating the Java exec statements.

Bojan

[Hoff]

Any relevant auditing or accounting details around failures?

The quotas and the differences between your interactive user quotas and the server username quotas (if different) and PQL settings (usually different) are certainly a path worth investigating, too.

[John Gillings]

Willem,

What is your EXACT command or call to start the detached process? What are PQL_DPRCLM and PQL_MPRCLM?

Have you checked that the detached process really is getting quotas you intend? (use SDA on the running process, FORMAT JIB)

>any other attempts fails

"fails"? Error message? Status? Accounting or auditing message? Please be more specific.

[Willem Grooters]

Accounting shows the first subprocess finished properly; no surprise since that one did it's work. The second process creation doesn't get that far, it's not mentioned in accounting.

Some more information:

As a detacher process, the Java program is started with a commandline without any parameters (I know it's not the right thing to do, it will be changed when we have obtained statistics):
run/detach/process=sub_tst/input=runsub.com/output=runsub.log sys$system:loginout

runsub.com contains the lines:

$ @sys$manager:java$150_jre_setup ! to setup the java environment
$ java -jar applsub.jar ! + parameters

Runsub.com is also used to run the java program in a terminal session.

The program reads a URL from the designed socket and will execute a procedure by the Java "exec " commmand. Output is returned to the issuer (Browser, or program). Though the program is multi-threaded, and one URL is issues at a time, there will be no simultanious subprocesses.

Interactively, repeating this URL (unchanged) will launch a subprocess as many times as the URL is issued.

As a detached process, only the first URL will cause the subprocess be created, but any subsequent URL (changed or unchanged) will does not create a subprocess.

Since the first process is actually created and finished before a second EXEC is to be executed, it seems odd that quota is the cause. Unless the program runs on the edge of it's quota and the garbage collector hasn't run yet ??

We use the Java-5 JRE on OpenVMS 7.3-2 - I know it's unsupported - but since there is no problem at all running the Java program interactively, it's not feasable there is a problem running as a detached process (IMHO).

Attachement shows requested information:
* Code snipplet
* Program log on second invokation in detached process
* PQL sysgen parameters
* User quota (user that runs program interactively or as detached process)

[H.Becker]

Works for me and Java 1.42 and a simple java/command procedure example on V7.3-2. However, I can get into a RWMBX after the 1st exec of the command procedure. It shows if the page file quota is too low. But I do not get a java error as shown in the attachment.

Maybe you need more virtual address space, aka page file quota. But to me it looks more like a Java on VMS/compatibility problem.

[Willem Grooters]

The message may well be different, the snipplet has been extracted from the program and has been edited to obscure it's origin, as required by policy :)
A comtablity mismatch seems unlikely to me since interactively, thete is no problem. Pagefilequota could be an issue - though I doubt that when a process enters that state, it will still finish; let alone it's ending written to accounting with a SUCCESS status.

[Jan van den Ende]

Willem,

>>>
let alone it's ending written to accounting with a SUCCESS status.
<<<

I assume you would be aware of it, but assuming sometimes leads into a morass...

Since JAVA is ported U*X stuff, you HAVE made sure that the SUCCESS status is a _VMS_ success ( %X1 ), and _NOT_ an untranlated transfered U*X status ( 1 = something-is-wrong).

I ask because the reverse once severly has bitten us: EXIT status 0 (zero). U*X: all is well; VMS interpretation: unspecified failure.

If you are sure of the source of the status and the correct interpretation, then considere this not written.

fwiw

Proost.

Have one on me.

jpe

[John Gillings · Accepted solution]

Willem,

Q>What may be the cause of this behaviour?

A>As a detacher process, the Java program
A>is started with a commandline without any
A>parameters I know it's not the right thing
A>to do, it will be changed when we have
A>obtained statistics):

There's your answer. The differences between your "working" and "not working" cases are the quotas they're running under. ergo...

Copy a RUN/DETACHED command with a fully populated set of quota qualifiers from somewhere in SYS$STARTUP. Fill in more "reasonable" values and repeat your experiment. (Gosh! now it works!)

Attempting to diagnose exactly which quota is "the" problem is a waste of your time.

Restricting a process to some "minimal" set of quotas may appeal to a sense of frugality, but it's a false economy. It really doesn't "save" anything, and it wastes the time you spend attempting to derive the magical values, and debugging them when you get them wrong! (and trust me, with Java involved, you will!).

Remember that OpenVMS quotas, and commonly accepted values thereof, derive from a time when resources were several orders of magnitude scarcer and more expensive than they are now. PQL_D and PQL_M values are a joke, but if you want your code to work on more than one system it's a mistake to paper over inadequate RUN/DETACHED commands by jacking up defaults or minima.

Just keep that thought in mind. Any RUN/DETACHED command without a complete set of quotas specified is a bug waiting to happen.

[Willem Grooters]

Ok, I got that;
RUN/DETACH with the same quota as the user under which the job should run and the problem was gone - for the time being.
Renmains the question why a first EXEC succeeded, and any subsequent fails. If it were just that quota-issue, even the first would fail, or subsequent would work.
The collegue that encountered the problem just showed me monitoring output from his development machine (winXP) and it showed that heap-size increased during run - and he told me that heapspace that was once allocated, is NOT returned to the system (He's the Java exeprt, not me)
If that happened onm OpenVMS, it explains the situation.