|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
Previous versions of SocketAppender used a dedicated Thread configured in daemon mode. This approach was replaced in 1.0.13 using the LoggerContext's ExecutorService. Using the ExecutorService has the advantage of allowing the context to manage all of the thread resources needed by Logback components. There are many features of Logback that depend on long-running background tasks; SocketAppender is just one. Logback's LoggerContext has included an ExecutorService for running such tasks for several versions now.
As you noted, there is no way that the application programmer can predict which Logback features an application end-user will choose to configure. As noted in [1], the only way for the application programmer to ensure that all resources held by Logback are released is to honor the LoggerContext's contract by invoking LoggerContext#stop.
[1] http://logback.qos.ch/manual/configuration.html#stopContext