We are migrating this Jira service to Github. Issue creation is no longer possible on this server and must be done on Github. However, you may browse issues without an account. Editing or commenting on existing issues requires an account.

Please support SLF4J/logback/reload4j projects via Github donations and sponsorship.

Uploaded image for project: 'logback'
  1. logback
  2. LOGBACK-579

SiftingAppender and the lifecycle of created appenders

Details

    • Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Major Major
    • 1.0.1
    • 1.0.0
    • logback-classic
    • None
    • servlet container

    Description

      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...

      Attachments

        Activity

          Loading...
          We are migrating this Jira service to Github. Issue creation is no longer possible on this server and must be done on Github. However, you may browse issues without an account. Editing or commenting on existing issues requires an account.

          Please support SLF4J/logback/reload4j projects via Github donations and sponsorship.

          Uploaded image for project: 'logback'
          1. logback
          2. LOGBACK-579

          SiftingAppender and the lifecycle of created appenders

          Details

            • Icon: Improvement Improvement
            • Resolution: Fixed
            • Icon: Major Major
            • 1.0.1
            • 1.0.0
            • logback-classic
            • None
            • servlet container

            Description

              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...

              Attachments

                Activity

                  People

                    ceki Ceki Gülcü
                    guus Guus Bloemsma
                    Votes:
                    0 Vote for this issue
                    Watchers:
                    1 Start watching this issue

                    Dates

                      Created:
                      Updated:
                      Resolved:

                      People

                        ceki Ceki Gülcü
                        guus Guus Bloemsma
                        Votes:
                        0 Vote for this issue
                        Watchers:
                        1 Start watching this issue

                        Dates

                          Created:
                          Updated:
                          Resolved: