[logback-user] how to graceful shutdown logback with AsyncAppenders and without immediateFlush

[Gena Makhomed]

On 20.03.2014 17:17, Michael Reinhold wrote:

> All that being said, I'm not quite sure why you are resistant to a
> framework for implementing shutdown hooks. Is there a particular reason
> you object to the user being able to select which shutdown mechanism
> should be employed by Logback? I understand that you feel your solution
> covers most or all cases, but is it not possible that the end user of
> Logback may disagree and prefer to apply their own shutdown procedure or
> policy?

Right now what user can do inside logback shutdown hook - is just one 
action: calling LoggerContext.stop after stopping other app subsystems.

And, if user do graceful shutdown of other subsystems in shutdown hook
called "logback shutdown hook" - in fact they write own java code for
application shutdown hook, but falsely name it "logback shutdown hook"

This mismatch between name of logback shutdown hook and its role
of application shutdown hook is the main reason why I am resistant
to a creating yet one more framework for implementing shutdown hooks.

Second reason: framework for implementing shutdown hooks already exists.
it is Runtime.addShutdownHook() and Runtime.removeShutdownHook() methods

Third reason: if implement my proposed solution in logback,
the code of logback shutdown hook will look like this:

public void run() { loggerContext.switchToFailSafeMode(); }

If user want to call LoggerContext.stop in own application shutdown hook
it still can do it in own APPLICATION shutdown hook without any problems

Fourth reason:

I suppose additional attribute <configuration shutdownHook="false">
(with default value "true") can be added to logback, if some user need
completely turn off build-in logback shutdown hook and want to write
own application shutdown hook, using already existing framework for
implementing shutdown hooks from JVM. But right now this is looks
like premature optimization:

========================================================================

http://c2.com/cgi/wiki?PrematureOptimization

"Programmers waste enormous amounts of time thinking about, or worrying 
about, the speed of noncritical parts of their programs, and these 
attempts at efficiency actually have a strong negative impact when 
debugging and maintenance are considered. We should forget about small 
efficiencies, say about 97% of the time: premature optimization is the 
root of all evil. Yet we should not pass up our opportunities in that 
critical 3%."

========================================================================

Fifth reason:

see arguments from page
https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it

"Always implement things when you actually need them, never when you 
just foresee that you need them".

"Until the feature is actually needed, it is difficult to fully define 
what it should do and to test it. If the new feature is not properly 
defined and tested, it may not work correctly, even if it eventually is 
needed".

"Adding the new feature may suggest other new features. If these new 
features are implemented as well, this may result in a snowball effect 
towards feature creep".

> As a side question, how long would you estimate it would take to modify
> logback-core (and/or the other logback components) to implement your
> proposed solution?

I am not learn all details of code, but suppose that this is
not very difficult task. May be few weeks, if work in spare time
(need to read all sources of logback and understand internal logic).

> Are you currently working on implementing
> this switchToFailSafe functionality

Right now - not, because I don't know if this code will be accepted
or rejected, my first try was to ask about such idea - if idea accepted,
as the next step I can try to write patch with this idea implementation.

> or are you proposing that someone else from the logback community develop it?

I just proposing idea how to make logback graceful shutdown solution.
If this idea will be accepted and approved, then next step can be done.

If someone else from the logback community want
to code this idea - I have nothing against this.

-- 
Best regards,
  Gena