The FileManager includes the file name in its name. Likewise the SocketManager would include the host & port. So if the file name is changed the manager will be stopped.
Sent from my iPad On Apr 28, 2013, at 10:53 PM, Nick Williams <[email protected]> wrote: > Okay. So consider this scenario: Someone has the FileAppender configured to > write to file X. They change the configuration to write to file Y. Since the > FileManager already exists writing to file X, the FileManager won't be > stopped. Its use count will increase to 2 and the newly-configured > FileAppender will use it as well. The old FileAppender will stop and the > FileManager's use count will decrease back to 1, but it's being used by the > new FileAppender. The newly configured FileAppender is still writing to file > X, even though the configuration says File Y, because the FileManager hasn't > been reloaded. > > Do I understand that incorrectly? Am I missing something? > > Nick > > On Apr 29, 2013, at 12:47 AM, Ralph Goers wrote: > >> 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
