#3 restart after threads has completed

closed
5
2002-06-10
2002-06-07
Tamás Jung
No

From version 2.2.7 (win) the wrapper recognizes
that "long running" threads has completed and
__stops__ the service.
How can I achieve the service __restarted__?
Think on a buggy multithreaded service, an http
server for example, whose handler theads may
completed because of unexpected errors.
(The wrapper.disable_shutdown_hook=TRUE
doesn't help in this case.)

Discussion

  • Leif Mortenson
    Leif Mortenson
    2002-06-07

    • priority: 5 --> 3
    • assigned_to: nobody --> mortenson
     
  • Leif Mortenson
    Leif Mortenson
    2002-06-07

    Logged In: YES
    user_id=228081

    That sounds like a problem with the Java program that you
    are running. Is it something that you wrote? or just a
    project that you are using.

    If you have control of the ThreadGroup that is being used to
    create the threads, you can subclass ThreadGroup and
    implement a new uncaughtException method to trap these
    errors. You could then call WrapperManager.restart() from
    that method if you want.

    Like you said though, the problem is with the application,
    not with the Wrapper. I would prefer that you came up with
    a way to have your application restart itself rather than
    the wrapper trying to figure out when to do so. :-)

    The wrapper.disable_shutdown_hook value does not have any
    affect on the behavior here. It is used to control what
    happens if the user code calls System.exit() to stop the
    application rather than calling WrapperManager.stop(). If
    it is true then the Wrapper will be told that the JVM wants
    to shutdown cleanly. If false, then the JVM will exit and
    the Wrapper will think that is an error and restart.

    Cheers,
    Leif

     
  • Tamás Jung
    Tamás Jung
    2002-06-10

    Logged In: YES
    user_id=559528

    From now I should jump to the feature request topic. I'm
    gonna try to persuade you to add new functionality to
    the wrapper.

    A self-managed failover mechanism can't be so reliable
    as an outer one. The Wrapper could be a second level
    protection against software bugs and runtime errors.
    The question is: Does it want to be that? Or it just want
    to save us from jvm bugs. Well, the service management
    of the OS should handle these failures (it might as well
    restart the whole system) but how can I indicate that its
    a failure while I want to independent from the Wrapper
    API? The exit code seems to be ineffective and only
    applicable in my own projects.

    >That sounds like a problem with the Java program that
    you
    >are running. Is it something that you wrote? or just a
    >project that you are using.
    Both, I'd use the Wrapper in several projects.

    >If you have control of the ThreadGroup that is being
    used to
    >create the threads, you can subclass ThreadGroup and
    >implement a new uncaughtException method to trap
    these
    >errors. You could then call WrapperManager.restart()
    from
    >that method if you want.
    Yes, but then my code would depend on the
    WrapperManager which is undesired of course. By the
    way, an explicit System.exit in this place would effects
    the same result with the disable_shutdown_hook
    property.

    >Like you said though, the problem is with the
    application,
    >not with the Wrapper. I would prefer that you came
    up with
    >a way to have your application restart itself rather than
    >the wrapper trying to figure out when to do so. :-)
    No, it shouldn't figure out anything, I'd like to tell it
    what to do. A new property, for example
    wrapper.recovery=NOTHING|RESTART could help.
    Anyway the problem is not with the application nor the
    Wrapper, that's the World where nothing is certain. :-)

    >The wrapper.disable_shutdown_hook value does not
    have any
    >affect on the behavior here. It is used to control what
    >happens if the user code calls System.exit() to stop the
    >application rather than calling WrapperManager.stop().
    If
    >it is true then the Wrapper will be told that the JVM
    wants
    >to shutdown cleanly. If false, then the JVM will exit
    and
    >the Wrapper will think that is an error and restart.
    I think, if all additional threads started by the Wrapper
    used the daemon flag, this property setting would cause
    what I want. Is it true?
    I've confused by what you wrote here. The
    documentation says this: If disabled (that is the value is
    TRUE, isn't it?), calls to System.exit() will be treated as if
    the JVM had crashed and the Service will be restarted.
    Doesn't it the contrary of the above statement?

    Thanks
    Tamas

     
  • Tamás Jung
    Tamás Jung
    2002-06-10

    • priority: 3 --> 5
     
  • Leif Mortenson
    Leif Mortenson
    2002-06-10

    Logged In: YES
    user_id=228081

    Ok, so let me understand your request. Currently, when all
    non-daemon threads have stopped, the Wrapper will exit the
    JVM along with the Wrapper. This is the way a JVM normally
    behaves as it means that the application is complete.

    You would like the ability to control what happens in this
    case? Maybe add a new parameter:

    wrapper.onthreadcompletion=EXIT | RESTART | CONTINUE

    Where EXIT is the default. Is this correct? I don't like
    the property name... But is this what you have in mind?

    About the wrapper.disable_shutdown_hook, you are correct.
    It is used to control what happens when the System.exit
    method is called.

    If disabled (ie true) Then the wrappers shutdown hook will
    not be registered with the system. So a call to System.exit
    will cause the JVM to exit without the wrapper being told.
    This would result in a restart of the JVM.

    If enabled (ie false, the default) Then the shutdown hook
    is registered and a System.exit call is made, then the JVM
    will shutdown. But before it does, the Wrapper's shutdown
    hook will be called, telling the Wrapper that the
    application really wants to exit.

    Cheers,
    Leif

     
  • Tamás Jung
    Tamás Jung
    2002-06-10

    • status: open --> closed
     
  • Tamás Jung
    Tamás Jung
    2002-06-10

    Logged In: YES
    user_id=559528

    Thank you for the immediate response.
    Yes, you understand well my request, but let me make
    some remarks.

    The wrapper.onthreadcompletion=CONTINUE doesn't
    seems to be very usefull.

    The silent completion of the the thread should be
    equivalent to an explicit System.exit(0). No doubt, from
    the Wrapper point of view it's absolutly different
    because of its achitecture which use embedded threads
    to controll the application. What I want to say is that the
    Wrapper should distinguish only "normal"
    and "abnormal" termination regardless of the manner
    the application reach its final state. Naturally it should
    support restarting after a "normal" termination as well.

    Thanks

    Tamas
    
     
  • Leif Mortenson
    Leif Mortenson
    2002-06-11

    Logged In: YES
    user_id=228081

    Can you do the honors of posting a Feature Request on this.
    Please describe what you want over there again, and put in
    a note pointing to this support issue.

    Should be easy to implement.

    Cheers,
    Leif