|
||||||||
|
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 |
||||||||
Indeed, if I extend my Example Program with Carl Harris code, the Application shuts down correctly.
However, I think its unreasonable to ask the application programmer to anticipate that an end-user of his application
would like to configure a SocketAppender (or use logback at all).
BTW: This behaviour is not present in logback <=1.0.12.
After looking through the code of Logback and the API specification of the ThreadPoolExcecutor I suspect the only viable solution is to revert to using normal Threads instead of the background Tasks (e.g. Revert commit ee12a3eb23e4a85d12a90d0c75ca0e354b889c73)
for the SocketAppender.
Using timeouts when polling the BlockingQueue or trying to fix this by overriding finalize() do not feel right.