Uploaded image for project: 'Log4j 2'
  1. Log4j 2
  2. LOG4J2-2269

Memory leaking of replacement parameters in case of enableThreadlocals=true

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.0.0
    • Component/s: Core
    • Labels:
      None

      Description

      Use case:
      1) I have a thread pool with quite large number of threads (around 100)
      2) Threads from the pool sometimes process some heavy objects. Threads are not actively writing into logs (so, a thread may process a task and does not log any message).
      3) As a part of processing for some objects in some non-frequently used branch a thread logged a message with heavy replacement parameters (parameterized log message is used).

      In this case such heavy replacement parameters are not garbage collected until another message will not written within the same thread because thread-local ReusableParameterizedMessage and MutableLogEvent objects keep references to the replacement parameters.

      Is it possible to cleanup such references when a message is released (for example as a part of org.apache.logging.log4j.message.ReusableMessageFactory#release and org.apache.logging.log4j.core.impl.ReusableLogEventFactory#release) to avoid such kind of leaks?

        Attachments

        1. heap_dump_references.png
          450 kB
          Dmitry Konstantinov
        2. heap_dump_threadLocals_false.hprof.zip
          1.28 MB
          Dmitry Konstantinov
        3. heap_dump_threadLocals_true.hprof.zip
          1.43 MB
          Dmitry Konstantinov
        4. test_to_reproduce.zip
          3 kB
          Dmitry Konstantinov

          Issue Links

            Activity

              People

              • Assignee:
                remkop@yahoo.com Remko Popma
                Reporter:
                dnk Dmitry Konstantinov
              • Votes:
                0 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: