[JIRA] Created: (LBCLASSIC-316) SiftingAppender and the lifecycle of created appenders
SiftingAppender and the lifecycle of created appenders ------------------------------------------------------ Key: LBCLASSIC-316 URL: http://jira.qos.ch/browse/LBCLASSIC-316 Project: logback-classic Issue Type: Improvement Components: appender Affects Versions: 1.0.0 Environment: servlet container Reporter: Guus Bloemsma Assignee: Logback dev list I'm using SiftingAppender to create logfiles per servlet request. I wrote a servlet filter to add session and request id's into MDC. A custom appender (nested into SiftingAppender) buffers all logging events. Only when a WARN or ERROR occurred it writes all of them at the end of the servlet request to yet another nested appender. Logback made this surprisingly easy! This all works fine except for one little problem. The SiftingAppender creates a new custom appender for each request. It uses a AppenderTrackerImpl to keep track of them. That AppenderTrackerImpl holds on to those appenders for half an hour even though it is guaranteed that they won't be needed after the request. That is a lot of unused appenders! Being able to configure that timeout per SiftingAppender would be one solution. Another way would be to make the method ch.qos.logback.core.sift.AppenderTrackerImpl.isEntryStale(Entry, long) check whether the appender in the entry is stopped. In that case it should be treated as stale as well. My custom appender would simply stop itself once it is no longer used. BTW, I understand that I'm kind of abusing SiftingAppender. Maybe I should just make my own... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCLASSIC-316?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu reassigned LBCLASSIC-316: ------------------------------------ Assignee: Ceki Gulcu (was: Logback dev list)
SiftingAppender and the lifecycle of created appenders ------------------------------------------------------
Key: LBCLASSIC-316 URL: http://jira.qos.ch/browse/LBCLASSIC-316 Project: logback-classic Issue Type: Improvement Components: appender Affects Versions: 1.0.0 Environment: servlet container Reporter: Guus Bloemsma Assignee: Ceki Gulcu
I'm using SiftingAppender to create logfiles per servlet request. I wrote a servlet filter to add session and request id's into MDC. A custom appender (nested into SiftingAppender) buffers all logging events. Only when a WARN or ERROR occurred it writes all of them at the end of the servlet request to yet another nested appender. Logback made this surprisingly easy! This all works fine except for one little problem. The SiftingAppender creates a new custom appender for each request. It uses a AppenderTrackerImpl to keep track of them. That AppenderTrackerImpl holds on to those appenders for half an hour even though it is guaranteed that they won't be needed after the request. That is a lot of unused appenders! Being able to configure that timeout per SiftingAppender would be one solution. Another way would be to make the method ch.qos.logback.core.sift.AppenderTrackerImpl.isEntryStale(Entry, long) check whether the appender in the entry is stopped. In that case it should be treated as stale as well. My custom appender would simply stop itself once it is no longer used. BTW, I understand that I'm kind of abusing SiftingAppender. Maybe I should just make my own...
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCLASSIC-316?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu commented on LBCLASSIC-316: --------------------------------------
BTW, I understand that I'm kind of abusing SiftingAppender. Maybe I should just make my own...
Not at all. SiftingAppender should provide a way to deal with this problem.
SiftingAppender and the lifecycle of created appenders ------------------------------------------------------
Key: LBCLASSIC-316 URL: http://jira.qos.ch/browse/LBCLASSIC-316 Project: logback-classic Issue Type: Improvement Components: appender Affects Versions: 1.0.0 Environment: servlet container Reporter: Guus Bloemsma Assignee: Ceki Gulcu
I'm using SiftingAppender to create logfiles per servlet request. I wrote a servlet filter to add session and request id's into MDC. A custom appender (nested into SiftingAppender) buffers all logging events. Only when a WARN or ERROR occurred it writes all of them at the end of the servlet request to yet another nested appender. Logback made this surprisingly easy! This all works fine except for one little problem. The SiftingAppender creates a new custom appender for each request. It uses a AppenderTrackerImpl to keep track of them. That AppenderTrackerImpl holds on to those appenders for half an hour even though it is guaranteed that they won't be needed after the request. That is a lot of unused appenders! Being able to configure that timeout per SiftingAppender would be one solution. Another way would be to make the method ch.qos.logback.core.sift.AppenderTrackerImpl.isEntryStale(Entry, long) check whether the appender in the entry is stopped. In that case it should be treated as stale as well. My custom appender would simply stop itself once it is no longer used. BTW, I understand that I'm kind of abusing SiftingAppender. Maybe I should just make my own...
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCLASSIC-316?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu resolved LBCLASSIC-316. ---------------------------------- Fix Version/s: 1.0.1 Resolution: Fixed SiftingAppender will consider stale and consequently remove nested appenders which are closed or improperly started. See also https://github.com/ceki/logback/commit/1169a18f6aa
SiftingAppender and the lifecycle of created appenders ------------------------------------------------------
Key: LBCLASSIC-316 URL: http://jira.qos.ch/browse/LBCLASSIC-316 Project: logback-classic Issue Type: Improvement Components: appender Affects Versions: 1.0.0 Environment: servlet container Reporter: Guus Bloemsma Assignee: Ceki Gulcu Fix For: 1.0.1
I'm using SiftingAppender to create logfiles per servlet request. I wrote a servlet filter to add session and request id's into MDC. A custom appender (nested into SiftingAppender) buffers all logging events. Only when a WARN or ERROR occurred it writes all of them at the end of the servlet request to yet another nested appender. Logback made this surprisingly easy! This all works fine except for one little problem. The SiftingAppender creates a new custom appender for each request. It uses a AppenderTrackerImpl to keep track of them. That AppenderTrackerImpl holds on to those appenders for half an hour even though it is guaranteed that they won't be needed after the request. That is a lot of unused appenders! Being able to configure that timeout per SiftingAppender would be one solution. Another way would be to make the method ch.qos.logback.core.sift.AppenderTrackerImpl.isEntryStale(Entry, long) check whether the appender in the entry is stopped. In that case it should be treated as stale as well. My custom appender would simply stop itself once it is no longer used. BTW, I understand that I'm kind of abusing SiftingAppender. Maybe I should just make my own...
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
participants (2)
-
Ceki Gulcu (JIRA) -
Guus Bloemsma (JIRA)