You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Ralph Goers (JIRA)" <ji...@apache.org> on 2014/03/13 19:05:43 UTC
[jira] [Comment Edited] (LOG4J2-568) Appender configuration did not
automatically detect changes to the configuration file
[ https://issues.apache.org/jira/browse/LOG4J2-568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13933650#comment-13933650 ]
Ralph Goers edited comment on LOG4J2-568 at 3/13/14 6:04 PM:
-------------------------------------------------------------
I am assuming that what you are saying is that you changed the value of the size attribute on the SizeBasedTriggeringPolicy while the app was running? If not I may be answering the wrong question.
Unfortunately, yes - it is probably expected. In order to not lose any data Appenders use a Manager to perform most of their work. Each manager has a "key" that consists of its name and any significant configuration attributes (fileName, ip and port for a socket, etc). The key usually doesn't contain all the configuration items. When you change the configuration a new Appender will be created in the new configuration, but if it finds an existing manager with the same key it will reuse it. If no Appender references a manager after reconfiguration it will be stopped and removed. Most objects, including Managers, are immutable after they are created to avoid threading issues.
The effect of this is that while you are logging if the same Appender exists in both configurations no data will be lost since the stream or other resource the manager is using isn't closed.
If you remove the appender from the configuration, reconfigure, then add the appender back and reconfigure, you should then see the change take effect. Of course, no data will be routed to the appender while it is removed from the configuration.
It may be possible to modify things so that some attributes can be updated during a reconfiguration. But that will probably have to be done on a case, by case basis.
was (Author: ralph.goers@dslextreme.com):
Unfortunately, yes - it is probably expected. In order to not lose any data Appenders use a Manager to perform most of their work. Each manager has a "key" that consists of its name and any significant configuration attributes (fileName, ip and port for a socket, etc). The key usually doesn't contain all the configuration items. When you change the configuration a new Appender will be created in the new configuration, but if it finds an existing manager with the same key it will reuse it. If no Appender references a manager after reconfiguration it will be stopped and removed. Most objects, including Managers, are immutable after they are created to avoid threading issues.
The effect of this is that while you are logging if the same Appender exists in both configurations no data will be lost since the stream or other resource the manager is using isn't closed.
If you remove the appender from the configuration, reconfigure, then add the appender back and reconfigure, you should then see the change take effect. Of course, no data will be routed to the appender while it is removed from the configuration.
It may be possible to modify things so that some attributes can be updated during a reconfiguration. But that will probably have to be done on a case, by case basis.
> Appender configuration did not automatically detect changes to the configuration file
> --------------------------------------------------------------------------------------
>
> Key: LOG4J2-568
> URL: https://issues.apache.org/jira/browse/LOG4J2-568
> Project: Log4j 2
> Issue Type: Test
> Components: Appenders, Configurators
> Affects Versions: 2.0-rc1
> Reporter: vibin
>
> "SizeBasedTriggeringPolicy" (size) attribute of the Appender did not detect the automatic changes to the file. I modified the configuration during run time did not detect the changes.
> Here is the configuration:
> <Policies>
> <TimeBasedTriggeringPolicy />
> <SizeBasedTriggeringPolicy size="5 KB" />
> </Policies>
> Is this expected ?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org