logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicholas Williams <nicho...@nicholaswilliams.net>
Subject Re: Appenders + Managers + Reconfiguration
Date Mon, 29 Apr 2013 13:35:34 GMT
*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
<nicholas@nicholaswilliams.net> 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 <rgoers@apache.org> 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 <nicholas@nicholaswilliams.net>
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: log4j-dev-unsubscribe@logging.apache.org
>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> <smime.p7s>

Mime
View raw message