Best way to halt Java process?

[Todd]

Hello,

I have a Java process that when it is improperly configured, it needs
to halt (programmatically). My understanding was that
System.exit(status) was the way to do this. There has been some
grumbling that there may be another, better way to do this, but nobody
has an specifics. References have been made to Eclipse and JBoss, but
Google hasn't turned up any useful results.

Anybody here know anything about this? I know it is a bit ambiguous,
but I am searching the darkness with a penlight for answers to this.

Thanks,
Todd

 

[Alessio Stalla]

Hello,

I have a Java process that when it is improperly configured, it needs
to halt (programmatically).  My understanding was that
System.exit(status) was the way to do this.

It still is.

 There has been some
grumbling that there may be another, better way to do this, but nobody
has an specifics.  References have been made to Eclipse and JBoss, but
Google hasn't turned up any useful results.

Neither Eclipse nor JBoss are likely to have anything to do with
exiting an application.

Just keep in mind that System.exit kills the entire JVM, so if your
"process" is a webapp in a servlet container, you'll kill all the
other webapps and the container, too.

Regards,
Alessio

 

[Stefan Ram]

I have a Java process that when it is improperly configured, it needs
to halt (programmatically). My understanding was that
System.exit(status) was the way to do this. There has been some
grumbling that there may be another, better way to do this, but nobody
has an specifics.

I prefer, in a console application, to return from »main«,
and in a Swing application, to dispose all Swing resources.

 

[Todd]

Just keep in mind that System.exit kills the entire JVM, so if your
"process" is a webapp in a servlet container, you'll kill all the
other webapps and the container, too.

That's what I understood, but thanks for the reminder. For the
purposes of this process/application, failing to a safe-mode (in this
case where no further processing is allowed) is best, so halting the
JVM is reasonable.

Todd

 

[Todd]

  I prefer, in a console application, to return from »main«,
  and in a Swing application, to dispose all Swing resources.

This process is running in the background as a Windows service. In
the most likely scenario, the interface will have not yet
initialized. In the least likely scenario, there will be an interface
running in a browser, attempting to connect with this server process.
The server process failing to a safe state (not accepting further
input, halting processing - in this case) is expected.

With that in mind, since the use case presents abnormal situations,
what is your preferred exit strategy?

 

[Eric Sosman]

That's what I understood, but thanks for the reminder. For the
purposes of this process/application, failing to a safe-mode (in this
case where no further processing is allowed) is best, so halting the
JVM is reasonable.

Keep in mind that things like application servers and browsers
will not allow applets/servlets/whatnot to stop the JVM: They'll
install security managers, and System.exit() will wind up throwing
SecurityException. Assuming you don't catch it, this will cause the
thread that called System.exit() to terminate. But if you've launched
additional threads, they won't be affected by the intercepted attempt
to exit. Not necessarily a problem (especially in your case, where
I gather the problem is detected early and you might not have launched
a lot of threads yet), but something to be aware of.

 

[Joshua Maurice]

Hello,

I have a Java process that when it is improperly configured, it needs
to halt (programmatically).  My understanding was that
System.exit(status) was the way to do this.  There has been some
grumbling that there may be another, better way to do this, but nobody
has an specifics.  References have been made to Eclipse and JBoss, but
Google hasn't turned up any useful results.

Anybody here know anything about this?  I know it is a bit ambiguous,
but I am searching the darkness with a penlight for answers to this.

If you're in your own process, and this is like a sanity check
violation or something and you really want to die now, then Runtime
halt is what you want.
http://java.sun.com/javase/6/docs/api/java/lang/Runtime.html#halt(int)
Note that this comes with all of the usual caveats listed in its
description, such as exit hooks not running, etc., but that sounds
like a requirement for you, aka a good thing. Just be wary of any
between-execution invariants you might want maintained, as they may no
longer be.

 

[Arne Vajhøj]

I have a Java process that when it is improperly configured, it needs
to halt (programmatically). My understanding was that
System.exit(status) was the way to do this. There has been some
grumbling that there may be another, better way to do this, but nobody
has an specifics.

What should the "better" ways do that System.exit does not do?

Arne

 

[ClassCastException]

It still is.


Neither Eclipse nor JBoss are likely to have anything to do with exiting
an application.

Just keep in mind that System.exit kills the entire JVM, so if your
"process" is a webapp in a servlet container, you'll kill all the other
webapps and the container, too.

throw new Error();

This works if a) nothing in your own code's call chain catches generic
Error() (or worse, generic Throwable()) but b) any container inside the
JVM and outside your code does, in self-defense, catch unhandled
Throwables that bubble up from the contained things or hosts them in
separate threads and c) your code is single-threaded.

I think the usual situation will be that a) you don't catch Error and b)
servlet containers etc. run servlets etc. in separate threads and deal
with it gracefully if any of these threads abends. If you have multiple
threads, provide some interrupt mechanism that can be triggered.

Another, perhaps even safer option is to give your entry point method an
exception handler that catches everything, and anything it doesn't handle
in a more specific way gets logged, then it executes a simple return.

 

[Mike Schilling]

I think the usual situation will be that a) you don't catch Error and b)
servlet containers etc. run servlets etc. in separate threads and deal
with it gracefully if any of these threads abends. If you have multiple
threads, provide some interrupt mechanism that can be triggered.

A servlet container will handle each request in a separate thread, and
direct that thread to the servlet that should handle it. One request's
thread erroring horribly doesn't prevent further requests from being
processed by that same servlet. Preventing any further processing would
require some management operation that disables the servlet, or more likely
its containing web application.

 

[ClassCastException]

A servlet container will handle each request in a separate thread, and
direct that thread to the servlet that should handle it. One request's
thread erroring horribly doesn't prevent further requests from being
processed by that same servlet. Preventing any further processing would
require some management operation that disables the servlet, or more
likely its containing web application.

Euuww. That means you need to tell the servlet container to unregister
you, or else set a public static mutable error flag that makes all
subsequent instances prompt-fail, or something. Global variables. Ick!

Does the servlet<->container API/protocol/whatever not include an
explicit way for a servlet to signal a fatal error to the container? Let
alone to perform just-once initialization, prior to handling requests,
which can fail? It sounds like right now you'll have thread after thread
testing all this stuff and then quitting, or even succeeding, unless you
have some sort of

public static boolean working = null;

and code like

if (working == null) {
perform tests and set working to Boolean.TRUE or Boolean.FALSE;
}
if (working == Boolean.FALSE) {
scream and die;
}
do the work;

in your runnable to reduce the amortized overhead to a null-check,
dereference, and boolean test.

Now please pardon me while I go wash my hands very thoroughly.

 

[ClassCastException]

Euuww. That means you need to tell the servlet container to unregister
you, or else set a public static mutable error flag that makes all
subsequent instances prompt-fail, or something. Global variables. Ick!

Does the servlet<->container API/protocol/whatever not include an
explicit way for a servlet to signal a fatal error to the container? Let
alone to perform just-once initialization, prior to handling requests,
which can fail? It sounds like right now you'll have thread after thread
testing all this stuff and then quitting, or even succeeding, unless you
have some sort of

public static boolean working = null;

Bah, that should say

public static Boolean working = null;

of course.

and code like

if (working == null) {
perform tests and set working to Boolean.TRUE or Boolean.FALSE;
}
if (working == Boolean.FALSE) {
scream and die;
}
do the work;

in your runnable to reduce the amortized overhead to a null-check,
dereference, and boolean test.

Now please pardon me while I go wash my hands very thoroughly.

And now I need to go wash 'em again. Bah!

 

[Mike Schilling]

Euuww. That means you need to tell the servlet container to unregister
you, or else set a public static mutable error flag that makes all
subsequent instances prompt-fail, or something. Global variables. Ick!

Does the servlet<->container API/protocol/whatever not include an
explicit way for a servlet to signal a fatal error to the container? Let
alone to perform just-once initialization, prior to handling requests,
which can fail?

Yeah, that you can do. There's an init() method, and if it throws an
exception the servlet is never enabled (at least, in containers I know of.
Not sure if that's part of the spec.) But even without that, there's no need
for anything but a private field used by the (single) instance of the
servlet class. Multiple threads -- single instance.

 

[ClassCastException]

Yeah, that you can do. There's an init() method, and if it throws an
exception the servlet is never enabled (at least, in containers I know
of. Not sure if that's part of the spec.)

Ah, then Todd should probably be doing these checks in the init() method
and throwing an exception if they fail.

But even without that, there's no need for anything but a private field
used by the (single) instance of the servlet class. Multiple threads
-- single instance.

Global variables by any other name ... *sigh*

Well, anyway.

 

[Mike Schilling]

Ah, then Todd should probably be doing these checks in the init() method
and throwing an exception if they fail.


Global variables by any other name ... *sigh*

A private instance field is a global variable?

 

[Lew]

I think the usual situation will be that a) you don't catch Error and b)
servlet containers etc. run servlets etc. in separate threads and deal
with it gracefully if any of these threads abends. If you have multiple
threads, provide some interrupt mechanism that can be triggered.

<http://java.sun.com/javase/6/docs/api/java/lang/Error.html>
"An Error is a subclass of Throwable that indicates serious problems that a
reasonable application should not try to catch."

 

[Arne Vajhøj]

Global variables by any other name ... *sigh*

No.

public static is a global variable - private not-static is not.

Arne

 

[Arne Vajhøj]

Yeah, that you can do. There's an init() method, and if it throws an
exception the servlet is never enabled (at least, in containers I know
of. Not sure if that's part of the spec.)

The servlet specs say:

<quote>
During initialization, the servlet instance can throw an
UnavailableException or a
ServletException. In this case, the servlet must not be placed into
active service
and must be released by the servlet container. The destroy method is not
called as it
is considered unsuccessful initialization.
</quote>

so if the exception thrown is a ServletException, then there
are no servlet available.

Arne

 

[Mike Schilling]

The servlet specs say:

<quote>
During initialization, the servlet instance can throw an
UnavailableException or a
ServletException. In this case, the servlet must not be placed into active
service
and must be released by the servlet container. The destroy method is not
called as it
is considered unsuccessful initialization.
</quote>

so if the exception thrown is a ServletException, then there
are no servlet available.

Cool. I'd be surprised if, say, Tomcat enabled servlets for a web app whose
init() method threw a RuntimeException either.

 

[Arne Vajhøj]

Cool. I'd be surprised if, say, Tomcat enabled servlets for a web app
whose init() method threw a RuntimeException either.

Me too.

But give the specs, then I would consider it worth catching
and throwing a ServletException just be 100% compliant.

Arne