[
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: [email protected]):
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: [email protected]
For additional commands, e-mail: [email protected]
