Oh! That makes sense! So I should include the connection information in my FileManager's name so that a new one gets created if the connection information changes. Right?
Nick Sent from my iPhone, so please forgive brief replies and frequent typos On Apr 29, 2013, at 8:30, Ralph Goers <[email protected]> wrote: > 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] >
smime.p7s
Description: S/MIME cryptographic signature
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
