When a reconfiguration takes place a new configuration is first created. All the Filters, Appenders, etc named in the configuration will be created. However, when the Appender calls getManager() it may find that one already exists with the name it is searching for. If so, that manager's use count will be incremented and the new Appender will reference it. Then the old configuration is stopped. During this time Appenders will call the release method on the manager and the manager's use count will be decremented. A manager doesn't actually stop until its use count is decremented to 0. This means database connections, sockets, streams, etc will all continue on into the new Appenders. If the new configuration no longer has a particular appender then the use count on that manager will decrement to zero and it will be stopped.
Ralph On Apr 28, 2013, at 9:52 PM, Nick Williams wrote: > Guys, > > I'm almost ready to submit a patch for JDBC/JPA/MongoDB/CouchDB, but I'd like > a little bit of instruction on something. I want to make sure I'm > understanding things correctly, because I'm getting ... strange ... results > when reloading configuration in between unit tests. > > So, if you have an Appender that has a Manager, and than appender has written > events, and LoggerContext.reconfigure() is called, what is done with the > existing Appender and Manager instances? Basically, can someone explain this > whole lifecycle? I want to make sure I'm using this pattern right. > > Thanks, > > Nick --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
