Investigate ways to avoid deadlocks in cases where Logger is invoked recursively

XMLWordPrintable

    • Type: Enhancement
    • Resolution: Unresolved
    • Priority: P4
    • tbd
    • Affects Version/s: 8
    • Component/s: core-libs
    • None

      There has been a long email thread on core-libs-dev about deadlocks happening when Logger was recursively invoked by a custom formatter.
      However there are more subtle cases where the same kind of deadlocks could occur: for instance, when using a simple formatter, a recursive call to Logger may occur if one of the message parameters passed to the formatter is an object whose toString() invokes a methods that happens to do some logging.

      I believe we should at least recommend - as a general programming rule - to avoid calling Logger from within toString(), hashCode(), equals(), or j.u.l.Formatter. We should also investigate whether we could make handlers safer wrt to recursive logging.

            Assignee:
            Daniel Fuchs
            Reporter:
            Daniel Fuchs
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: