Getting on the road, will ponder this afternoon... G
On Mon, Apr 6, 2015 at 9:02 AM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > 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 > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
