*so I should include the connection information in my _DatabaseManagers' names...
Sent from my iPhone, so please forgive brief replies and frequent typos On Apr 29, 2013, at 8:34, Nicholas Williams <[email protected]> wrote: > 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>
smime.p7s
Description: S/MIME cryptographic signature
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
