I’ve been looking at the deadlock that is documented in LOG4J-982. It seems to me that the problem is that get/setConfigLocation and reconfigure are locking the whole LoggerContext. First, the history shows that I added get & setConfigLocation as part of LOG4J2-207. I think Remko actually wrote the code. I am not sure why these methods need to be synchronized. Wouldn’t it be enough for configLocation to be volatile?
Second, I don’t think locking the LoggerContext for the entirety a reconfigure is a good idea. reconfigure calls setConfiguration, which is also synchronized. It seems to me that while setConfiguration does need to be locked, it should be using a lock that specifically only prevents setConfiguration from being executed simultaneously from more than one thread. Thoughts? Ralph --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
