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: ClassCastException on 10 Jun 2010 23:35 On Fri, 11 Jun 2010 03:15:21 +0000, ClassCastException wrote: > 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; 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!
From: Mike Schilling on 10 Jun 2010 23:38 "ClassCastException" <zjkg3d9gj56(a)gmail.invalid> wrote in message news:hus9o8$g1n$6(a)news.eternal-september.org... > 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? 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.
From: ClassCastException on 11 Jun 2010 01:52 On Thu, 10 Jun 2010 20:38:23 -0700, Mike Schilling wrote: > "ClassCastException" <zjkg3d9gj56(a)gmail.invalid> wrote in message > news:hus9o8$g1n$6(a)news.eternal-september.org... >> 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? > > 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.
From: Mike Schilling on 11 Jun 2010 01:55 "ClassCastException" <zjkg3d9gj56(a)gmail.invalid> wrote in message news:husivb$hsb$3(a)news.eternal-september.org... > On Thu, 10 Jun 2010 20:38:23 -0700, Mike Schilling wrote: > >> "ClassCastException" <zjkg3d9gj56(a)gmail.invalid> wrote in message >> news:hus9o8$g1n$6(a)news.eternal-september.org... >>> 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? >> >> 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* A private instance field is a global variable? > > Well, anyway.
From: Lew on 11 Jun 2010 16:55
ClassCastException wrote: > 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." -- Lew |