Log4j 2
  1. Log4j 2
  2. LOG4J2-83

Please provide means to disable MDC functionality on a global level.

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0-beta2
    • Component/s: None
    • Labels:
      None

      Description

      Disabling MDC evaluation can have drastic effects on event size while sending them over the wire or dumping them to disk.

      When disabled, all calls to MDC-related methods will instead call NOP implementations, i.e. no ThreadLocals would be used at all.

        Issue Links

          Activity

          Hide
          Ralph Goers added a comment -

          I am not convinced that completely disabling the MDC is a good idea as it could lead to application breakage. However, I am convinced that having the ThreadContext map be null in the LogEvent when there are no items in the Map is a very good idea. I plan on making that change and also plan on changing the Map stored in the LogEvent to be immutable.

          Show
          Ralph Goers added a comment - I am not convinced that completely disabling the MDC is a good idea as it could lead to application breakage. However, I am convinced that having the ThreadContext map be null in the LogEvent when there are no items in the Map is a very good idea. I plan on making that change and also plan on changing the Map stored in the LogEvent to be immutable.
          Hide
          Ralph Goers added a comment -

          I have commit the change in revision 1389690 as described above. The Map in the LogEvent is now immutable and is null if the ThreadContextMap is empty.

          Show
          Ralph Goers added a comment - I have commit the change in revision 1389690 as described above. The Map in the LogEvent is now immutable and is null if the ThreadContextMap is empty.
          Hide
          Ralph Goers added a comment -

          Joern - are the changes made enough to resolve your concerns?

          Show
          Ralph Goers added a comment - Joern - are the changes made enough to resolve your concerns?
          Hide
          Joern Huxhorn added a comment -

          Not really since the map wouldn't be empty at all in my cases.

          We use MDC quite extensively, i.e. 10-15 key-value-pairs per event. We never ever read values from the MDC in our application code. The MDC is used purely for logging and not as some magic bucket for moving around objects across method calls.
          Because of this, it would be feasible to disable MDC handling altogether. I suspect that most code is using the MDC like this, i.e. only writing, never reading (I've never seen any MDC values of libraries in my events).

          Chances are quite high that an application would work exactly the same way with MDC disabled, just a lot faster. While disabling MDC could lead to application breakage if the application is indeed reading from the MDC I don't understand the problem about this. I'd just not disable the MDC in that case. This is comparable to pulling the network cable for an application that is using the network. Yep, it will cause breakage. Just don't do it in those cases.

          Show
          Joern Huxhorn added a comment - Not really since the map wouldn't be empty at all in my cases. We use MDC quite extensively, i.e. 10-15 key-value-pairs per event. We never ever read values from the MDC in our application code. The MDC is used purely for logging and not as some magic bucket for moving around objects across method calls. Because of this, it would be feasible to disable MDC handling altogether. I suspect that most code is using the MDC like this, i.e. only writing, never reading (I've never seen any MDC values of libraries in my events). Chances are quite high that an application would work exactly the same way with MDC disabled, just a lot faster. While disabling MDC could lead to application breakage if the application is indeed reading from the MDC I don't understand the problem about this. I'd just not disable the MDC in that case. This is comparable to pulling the network cable for an application that is using the network. Yep, it will cause breakage. Just don't do it in those cases.
          Hide
          Ralph Goers added a comment -

          I have added support for setting system properties named "disableThreadContext", "disableThreadContextMap" , and "disableThreadContextStack". If disableThreadContext is set to true, pushes and puts will be ignored and no HashMaps or ContextStacks will be created. Similarly, if disableThreadContextMap is set to true then puts to the ThreadContextMap will be ignored and no Map will be created. Finally, if disableThreadContextStack is set to true then pushes will be ignored and no ContextStack will be created.

          When these properties are set the ThreadLocals will still be created but will never have any values in them.

          Show
          Ralph Goers added a comment - I have added support for setting system properties named "disableThreadContext", "disableThreadContextMap" , and "disableThreadContextStack". If disableThreadContext is set to true, pushes and puts will be ignored and no HashMaps or ContextStacks will be created. Similarly, if disableThreadContextMap is set to true then puts to the ThreadContextMap will be ignored and no Map will be created. Finally, if disableThreadContextStack is set to true then pushes will be ignored and no ContextStack will be created. When these properties are set the ThreadLocals will still be created but will never have any values in them.
          Hide
          Ralph Goers added a comment -

          Please verify the fix and close it. If it doesn't fully implement what is required feel free to reopen it.

          Show
          Ralph Goers added a comment - Please verify the fix and close it. If it doesn't fully implement what is required feel free to reopen it.
          Hide
          Joern Huxhorn added a comment -

          Looks good.

          Show
          Joern Huxhorn added a comment - Looks good.

            People

            • Assignee:
              Ralph Goers
              Reporter:
              Joern Huxhorn
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development