https://issues.apache.org/bugzilla/show_bug.cgi?id=41214
--- Comment #46 from Jason Marshall <[email protected]> --- I can see the deadlock from here. With nested Categories A->B->C While you're in B.callAppenders B is locked. If toObject() attempts to log, then C.callAppenders is invoked again. If someone else has already called C.callAppenders, you have a deadlock. One has C waiting for B, another has B waiting for C. The classical solution to this problem is to sort your locks and grab them in the same predictable order. The parent-child relationship -almost- solves the problem here, except for a couple problems. One, being able to rearrange your loggers while logging is happening, and the other is that pesky toObject() method. What you probably should do here is call parent.callAppenders while still holding your own lock. With deeply nested Categories this will widen your bottleneck but eliminate the deadlock. I won't be able to write to c.log while someone is still writing to b.log or a.log, and unfortunately it also breaks your emitNoAppenderWarning fallback, because callAppenders returns void. It's unclear to my why the parentage of a Category can be updated after it's created. It seems like it's an artifact of the evolution of the library. I'm not familiar with this aspect of Log4j but it seems that this is a case of premature publication. Add on a sprinkle of too much delegation and a dash of concurrency and you've got quite a soup here. I thought I had a patch proposal (that didn't break the API) but it turned out on further inspection to have the exact same failure mode. So instead of my help all I can offer is my sympathy. I now understand why this has been open for so long. I do think that if you pull some of the deprecated things out of this part of the API that it may be easier to fix. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
