Best way to halt Java process?
in [Java Programming]
|
Prev: encrypted javamail MimeMultipart
Next: Urgent DIRECT CLIENT Openings: 1.Websphere Portal - Developer, 2.ITIM-TAM Analyst, 3. IT Project Coordinator / Project Analyst
From: Joshua Maurice on 10 Jun 2010 14:54 On Jun 10, 7:52 am, Todd <todd.heident...(a)gmail.com> wrote: > 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%28int%29 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.
From: Arne Vajhøj on 10 Jun 2010 19:00 On 10-06-2010 10:52, Todd wrote: > 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
From: ClassCastException on 10 Jun 2010 22:31 On Thu, 10 Jun 2010 08:06:31 -0700, Alessio Stalla wrote: > On Jun 10, 4:52 pm, Todd <todd.heident...(a)gmail.com> wrote: >> 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. 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.
From: Mike Schilling on 10 Jun 2010 22:54 "ClassCastException" <zjkg3d9gj56(a)gmail.invalid> wrote in message news:hus76c$g1n$2(a)news.eternal-september.org... > 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.
From: ClassCastException on 10 Jun 2010 23:15
On Thu, 10 Jun 2010 19:54:51 -0700, Mike Schilling wrote: > "ClassCastException" <zjkg3d9gj56(a)gmail.invalid> wrote in message > news:hus76c$g1n$2(a)news.eternal-september.org... >> 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. 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. :-) |