Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

JNI Option -Xrs Doesn't Seem to Work; Ctrl-C not ignored by JVM

 
SOLVED
Go to solution
Ralph Cabrera
Occasional Visitor

JNI Option -Xrs Doesn't Seem to Work; Ctrl-C not ignored by JVM

Scenario: Calling Java from Pascal via C API in a command line application. We have an exception handler established via Pascal code using LIB$ESTABLISH that appears to be called whenever a Ctrl-C is issued and it appears that the embedded JVM is the culprit. We capture Ctrl-C via a handler to allow users to abort commands, but remain in the command line application. With the addition of the embedded JVM, the Ctrl-C kicks the user out of the application every time. We are at JDK 1.4.2 on Alpha running OpenVMS and are using the Fast version of the JVM. Any ideas?
4 REPLIES
Willem Grooters
Honored Contributor
Solution

Re: JNI Option -Xrs Doesn't Seem to Work; Ctrl-C not ignored by JVM

The easy answer: Don't use (embedded) Java :-)

It may be a feature of the Fast VM, try the classic VM to start with, though I doubt it would make a difference.
Based on what I know of JVM and VMS knowledge:
When Java code is called, it will take control - completely, implying that a condition handler, defined in a higher level, will be ignored.
So the JVM will capture ^C, and follow it's normal path in these cases: Stop after issueing a tracedump (you don't want to see either) and be removed from memory. When JVM was started from the commandline, that behaviour is expected (and preferable). When embedded however, it may be not - since it means the running image is removed, because the JVM-executed code is part of that image.

My guess is that the JVM runs in a separate thread that takes over, so that would be the reason that the condition handler is ignored, and it will stop all threads up to DCL in case of some condition - including ^C.

To prevent this, consider to run the Java code in a subprocess, executing a commandprocedure that will take control until it is finished for whatever reason. Let it return on ^C with an error. Or create a subprocess constantly reading it's input from a mailbox (or socket) and return status information, until requested to stop.
Willem Grooters
OpenVMS Developer & System Manager
Ralph Cabrera
Occasional Visitor

Re: JNI Option -Xrs Doesn't Seem to Work; Ctrl-C not ignored by JVM

More information: The condition code returned to my exception handler is 1620. When I do
$ write sys$output f$message(1620)
I get
$SYSTEM-F-CONTROLC, Operation completed under CTRL/C
In other words, the interrupted JVM made the condition FATAL, which caused my exception handler to fire and quit the application. I think I can intercept this condition and do a SS$_CONTINUE instead of SS$_RESIGNAL, but I'm not sure this is really the best/final solution.
Bojan Nemec
Honored Contributor

Re: JNI Option -Xrs Doesn't Seem to Work; Ctrl-C not ignored by JVM

Ralph,


Have you try to add a CTRL/C AST on your terminal. You do this with IO$_SETMODE!IO$M_CTRLCAST. See documentation:
http://h71000.www7.hp.com/doc/732FINAL/aa-pv6sf-tk/00/00/43-con.html#term-enable-ast

Bojan
Willem Grooters
Honored Contributor

Re: JNI Option -Xrs Doesn't Seem to Work; Ctrl-C not ignored by JVM

So it seems JVM _does_ return. That's new to me - and good news.
Your condition handler can cope with that error code: check this status and allow to continue if "1620" (use the name, not the value). You will need to unwind the stack to resume your normal processing as if the JAVA application finshed without a problem($UNWIND system service)

Willem
Willem Grooters
OpenVMS Developer & System Manager