[jira] [Resolved] (LOG4J2-1101) Date based file appender
[
https://issues.apache.org/jira/browse/LOG4J2-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers resolved LOG4J2-1101.
-
Resolution: Fixed
Fix Version/s: 2.8
The fix for this has been committed in master. Please verify and close if it
works for you.
> Date based file appender
>
>
> Key: LOG4J2-1101
> URL: https://issues.apache.org/jira/browse/LOG4J2-1101
> Project: Log4j 2
> Issue Type: New Feature
> Components: Appenders
>Reporter: Haavar Valeur
>Assignee: Ralph Goers
> Fix For: 2.8
>
>
> I'd like to reintroduce the option of logging to a file that has the current
> date in it.
> For example, when the app starts up, it will start logging to
> myapp-20150821.log. At midnight, it starts logging to a new file named
> myapp-20150822.log.
> Log4j2's RollingFileAppender does not support this. In log4j2 the file
> appender will log to one file with a static file name, and then the content
> is moved over to another file.
> This used to be a feature in log4j 1.3, when using extras. I would configure
> it like this:
> {code}
> class="org.apache.log4j.rolling.RollingFileAppender">
> class="org.apache.log4j.rolling.TimeBasedRollingPolicy">
>
>
>
>
> {code}
> The only way I found that it would work in log4j2 is to use the following
> code, but that's pretty hacky:
> https://gist.github.com/tomaszalusky/b9109c0faddafe099835
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1101) Date based file appender
[
https://issues.apache.org/jira/browse/LOG4J2-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15823276#comment-15823276
]
ASF subversion and git services commented on LOG4J2-1101:
-
Commit 8e88deb3e7e09c5e3df9445d7930bc63b5c39f4b in logging-log4j2's branch
refs/heads/master from [~ralph_go...@dslextreme.com]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=8e88deb ]
LOG4J2-1101 - Add documentation. Add missing license headers
> Date based file appender
>
>
> Key: LOG4J2-1101
> URL: https://issues.apache.org/jira/browse/LOG4J2-1101
> Project: Log4j 2
> Issue Type: New Feature
> Components: Appenders
>Reporter: Haavar Valeur
>Assignee: Ralph Goers
>
> I'd like to reintroduce the option of logging to a file that has the current
> date in it.
> For example, when the app starts up, it will start logging to
> myapp-20150821.log. At midnight, it starts logging to a new file named
> myapp-20150822.log.
> Log4j2's RollingFileAppender does not support this. In log4j2 the file
> appender will log to one file with a static file name, and then the content
> is moved over to another file.
> This used to be a feature in log4j 1.3, when using extras. I would configure
> it like this:
> {code}
> class="org.apache.log4j.rolling.RollingFileAppender">
> class="org.apache.log4j.rolling.TimeBasedRollingPolicy">
>
>
>
>
> {code}
> The only way I found that it would work in log4j2 is to use the following
> code, but that's pretty hacky:
> https://gist.github.com/tomaszalusky/b9109c0faddafe099835
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1101) Date based file appender
[
https://issues.apache.org/jira/browse/LOG4J2-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15823275#comment-15823275
]
ASF subversion and git services commented on LOG4J2-1101:
-
Commit acd8a4d6e587ae58e0550ae75ab29b7cceb4c843 in logging-log4j2's branch
refs/heads/master from [~ralph_go...@dslextreme.com]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=acd8a4d ]
LOG4J2-1101 - RollingFileAppender now supports omitting the file name and
writing directly to the archive files.
> Date based file appender
>
>
> Key: LOG4J2-1101
> URL: https://issues.apache.org/jira/browse/LOG4J2-1101
> Project: Log4j 2
> Issue Type: New Feature
> Components: Appenders
>Reporter: Haavar Valeur
>Assignee: Ralph Goers
>
> I'd like to reintroduce the option of logging to a file that has the current
> date in it.
> For example, when the app starts up, it will start logging to
> myapp-20150821.log. At midnight, it starts logging to a new file named
> myapp-20150822.log.
> Log4j2's RollingFileAppender does not support this. In log4j2 the file
> appender will log to one file with a static file name, and then the content
> is moved over to another file.
> This used to be a feature in log4j 1.3, when using extras. I would configure
> it like this:
> {code}
> class="org.apache.log4j.rolling.RollingFileAppender">
> class="org.apache.log4j.rolling.TimeBasedRollingPolicy">
>
>
>
>
> {code}
> The only way I found that it would work in log4j2 is to use the following
> code, but that's pretty hacky:
> https://gist.github.com/tomaszalusky/b9109c0faddafe099835
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-1787) Document how to exclude transitive conflicting dependencies in Maven and Gradle
[ https://issues.apache.org/jira/browse/LOG4J2-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker closed LOG4J2-1787. --- Resolution: Fixed Fix Version/s: 2.8 It appears that the git2jira integration isn't enabled yet. Added to master. > Document how to exclude transitive conflicting dependencies in Maven and > Gradle > --- > > Key: LOG4J2-1787 > URL: https://issues.apache.org/jira/browse/LOG4J2-1787 > Project: Log4j 2 > Issue Type: Documentation > Components: Documentation >Reporter: Matt Sicker >Assignee: Matt Sicker > Fix For: 2.8 > > > Add documentation regarding how to transitively exclude conflicting > dependencies for each replacement module. This should cover: > * When I use log4j-core, I should exclude log4j 1.x and logback > * When I use log4j-1.2-api, I should exclude log4j 1.x and log4j-over-slf4j > * When I use log4j-jcl, I should exclude jcl-over-slf4j, but I still need > commons-logging > * When I use log4j-jul, I should exclude jul-to-slf4j > * When I use log4j-to-slf4j, I should exclude log4j-core -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-1787) Document how to exclude transitive conflicting dependencies in Maven and Gradle
Matt Sicker created LOG4J2-1787: --- Summary: Document how to exclude transitive conflicting dependencies in Maven and Gradle Key: LOG4J2-1787 URL: https://issues.apache.org/jira/browse/LOG4J2-1787 Project: Log4j 2 Issue Type: Documentation Components: Documentation Reporter: Matt Sicker Assignee: Matt Sicker Add documentation regarding how to transitively exclude conflicting dependencies for each replacement module. This should cover: * When I use log4j-core, I should exclude log4j 1.x and logback * When I use log4j-1.2-api, I should exclude log4j 1.x and log4j-over-slf4j * When I use log4j-jcl, I should exclude jcl-over-slf4j, but I still need commons-logging * When I use log4j-jul, I should exclude jul-to-slf4j * When I use log4j-to-slf4j, I should exclude log4j-core -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-1776) log4j-boot pom modules for dependency management
[
https://issues.apache.org/jira/browse/LOG4J2-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker resolved LOG4J2-1776.
-
Resolution: Fixed
Assignee: Matt Sicker
All the modules in that list have been added.
> log4j-boot pom modules for dependency management
>
>
> Key: LOG4J2-1776
> URL: https://issues.apache.org/jira/browse/LOG4J2-1776
> Project: Log4j 2
> Issue Type: New Feature
> Components: Boot
>Reporter: Matt Sicker
>Assignee: Matt Sicker
> Fix For: boot-1.0-alpha1
>
>
> This is the main feature for the Log4j Boot epic (LOG4J2-1775).
> {code}
> groupId: org.apache.logging.log4j.boot
> artifactId: log4j-boot-*
> {code}
> * core: just log4j-core basically
> * async (for AsyncLogger; brings in LMAX disruptor)
> * compat: log4j-slf4j-impl, log4j-jul, log4j-jcl, log4j-1.2-api
> * logback (for log4j-to-slf4j, slf4j-spi, logback; this helps aid migration
> to log4j-api and promotes it as a general use logging API)
> * advertiser-jmdns
> * appender-async-conversant
> * appender-async-jctools
> * appender-cassandra
> * appender-couchdb
> * appender-jms
> * appender-jpa
> * appender-kafka
> * appender-mongodb
> * appender-smtp
> * appender-zeromq
> * config-json
> * config-yaml
> * layout-csv
> * layout-jansi (for windows users and coloured log messages)
> * layout-json (unless this has been ported to not require jackson anymore?)
> * layout-xml
> * layout-yaml
> * script-groovy
> I may have missed a few, but the base set of starters should at least
> correspond to all optional dependencies in log4j-core or the addon modules.
> For the jms, jpa, and smtp (log4j-core) appenders, we could either make add
> in a default provider (e.g., ActiveMQ, Hibernate, and Sun Mail respectively)
> or split those into provider-specific starters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1776) log4j-boot pom modules for dependency management
[
https://issues.apache.org/jira/browse/LOG4J2-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15823038#comment-15823038
]
Matt Sicker commented on LOG4J2-1776:
-
As mentioned on the mailing lists, log4j-boot-logback is provided to encourage
logback users to use log4j-api and provide a migration path to log4j-core.
Several notable projects (e.g., Spring Boot, Akka, Play) use logback by default
nowadays, so it'd be good to emphasize that log4j-api is an improvement on
slf4j-api regardless of backend framework.
> log4j-boot pom modules for dependency management
>
>
> Key: LOG4J2-1776
> URL: https://issues.apache.org/jira/browse/LOG4J2-1776
> Project: Log4j 2
> Issue Type: New Feature
> Components: Boot
>Reporter: Matt Sicker
> Fix For: boot-1.0-alpha1
>
>
> This is the main feature for the Log4j Boot epic (LOG4J2-1775).
> {code}
> groupId: org.apache.logging.log4j.boot
> artifactId: log4j-boot-*
> {code}
> * core: just log4j-core basically
> * async (for AsyncLogger; brings in LMAX disruptor)
> * compat: log4j-slf4j-impl, log4j-jul, log4j-jcl, log4j-1.2-api
> * logback (for log4j-to-slf4j, slf4j-spi, logback; this helps aid migration
> to log4j-api and promotes it as a general use logging API)
> * advertiser-jmdns
> * appender-async-conversant
> * appender-async-jctools
> * appender-cassandra
> * appender-couchdb
> * appender-jms
> * appender-jpa
> * appender-kafka
> * appender-mongodb
> * appender-smtp
> * appender-zeromq
> * config-json
> * config-yaml
> * layout-csv
> * layout-jansi (for windows users and coloured log messages)
> * layout-json (unless this has been ported to not require jackson anymore?)
> * layout-xml
> * layout-yaml
> * script-groovy
> I may have missed a few, but the base set of starters should at least
> correspond to all optional dependencies in log4j-core or the addon modules.
> For the jms, jpa, and smtp (log4j-core) appenders, we could either make add
> in a default provider (e.g., ActiveMQ, Hibernate, and Sun Mail respectively)
> or split those into provider-specific starters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1785) Add Spring Boot integration to Log4j Boot
[ https://issues.apache.org/jira/browse/LOG4J2-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker updated LOG4J2-1785: Fix Version/s: boot-1.0-alpha1 > Add Spring Boot integration to Log4j Boot > - > > Key: LOG4J2-1785 > URL: https://issues.apache.org/jira/browse/LOG4J2-1785 > Project: Log4j 2 > Issue Type: New Feature > Components: Boot >Reporter: Matt Sicker >Assignee: Matt Sicker > Fix For: boot-1.0-alpha1 > > > The Spring Boot integration packaged by Spring for Log4j2 uses SLF4J > libraries instead of the Log4j ones. This module should use native Log4j > bridges and use native functionality wherever possible. > This should include sensible default config files ported from > spring-boot-starter-log4j2. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-1785) Add Spring Boot integration to Log4j Boot
[ https://issues.apache.org/jira/browse/LOG4J2-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker closed LOG4J2-1785. --- Closing with fix version set. > Add Spring Boot integration to Log4j Boot > - > > Key: LOG4J2-1785 > URL: https://issues.apache.org/jira/browse/LOG4J2-1785 > Project: Log4j 2 > Issue Type: New Feature > Components: Boot >Reporter: Matt Sicker >Assignee: Matt Sicker > Fix For: boot-1.0-alpha1 > > > The Spring Boot integration packaged by Spring for Log4j2 uses SLF4J > libraries instead of the Log4j ones. This module should use native Log4j > bridges and use native functionality wherever possible. > This should include sensible default config files ported from > spring-boot-starter-log4j2. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Reopened] (LOG4J2-1778) Add logging-log4j-boot git repo
[ https://issues.apache.org/jira/browse/LOG4J2-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker reopened LOG4J2-1778: - Reopening to set fix version. > Add logging-log4j-boot git repo > --- > > Key: LOG4J2-1778 > URL: https://issues.apache.org/jira/browse/LOG4J2-1778 > Project: Log4j 2 > Issue Type: New Git Repo > Components: Boot >Reporter: Matt Sicker >Assignee: Matt Sicker > Fix For: boot-1.0-alpha1 > > > Create a new git repository to host Log4j Boot. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1776) log4j-boot pom modules for dependency management
[
https://issues.apache.org/jira/browse/LOG4J2-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker updated LOG4J2-1776:
Fix Version/s: boot-1.0-alpha1
> log4j-boot pom modules for dependency management
>
>
> Key: LOG4J2-1776
> URL: https://issues.apache.org/jira/browse/LOG4J2-1776
> Project: Log4j 2
> Issue Type: New Feature
> Components: Boot
>Reporter: Matt Sicker
> Fix For: boot-1.0-alpha1
>
>
> This is the main feature for the Log4j Boot epic (LOG4J2-1775).
> {code}
> groupId: org.apache.logging.log4j.boot
> artifactId: log4j-boot-*
> {code}
> * core: just log4j-core basically
> * async (for AsyncLogger; brings in LMAX disruptor)
> * compat: log4j-slf4j-impl, log4j-jul, log4j-jcl, log4j-1.2-api
> * logback (for log4j-to-slf4j, slf4j-spi, logback; this helps aid migration
> to log4j-api and promotes it as a general use logging API)
> * advertiser-jmdns
> * appender-async-conversant
> * appender-async-jctools
> * appender-cassandra
> * appender-couchdb
> * appender-jms
> * appender-jpa
> * appender-kafka
> * appender-mongodb
> * appender-smtp
> * appender-zeromq
> * config-json
> * config-yaml
> * layout-csv
> * layout-jansi (for windows users and coloured log messages)
> * layout-json (unless this has been ported to not require jackson anymore?)
> * layout-xml
> * layout-yaml
> * script-groovy
> I may have missed a few, but the base set of starters should at least
> correspond to all optional dependencies in log4j-core or the addon modules.
> For the jms, jpa, and smtp (log4j-core) appenders, we could either make add
> in a default provider (e.g., ActiveMQ, Hibernate, and Sun Mail respectively)
> or split those into provider-specific starters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-1778) Add logging-log4j-boot git repo
[ https://issues.apache.org/jira/browse/LOG4J2-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker closed LOG4J2-1778. --- Resolution: Fixed Fix Version/s: boot-1.0-alpha1 Marking with fix version. > Add logging-log4j-boot git repo > --- > > Key: LOG4J2-1778 > URL: https://issues.apache.org/jira/browse/LOG4J2-1778 > Project: Log4j 2 > Issue Type: New Git Repo > Components: Boot >Reporter: Matt Sicker >Assignee: Matt Sicker > Fix For: boot-1.0-alpha1 > > > Create a new git repository to host Log4j Boot. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1777) Add JUnit categories to integration tests for use in log4j-boot module test suites
[
https://issues.apache.org/jira/browse/LOG4J2-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker updated LOG4J2-1777:
Fix Version/s: boot-1.0-alpha1
> Add JUnit categories to integration tests for use in log4j-boot module test
> suites
> --
>
> Key: LOG4J2-1777
> URL: https://issues.apache.org/jira/browse/LOG4J2-1777
> Project: Log4j 2
> Issue Type: Test
> Components: Boot
>Reporter: Matt Sicker
>Assignee: Matt Sicker
> Fix For: boot-1.0-alpha1
>
>
> Add JUnit {{@Category}}
> [annotations|https://github.com/junit-team/junit4/wiki/Categories] to the
> various integration tests that correspond to Log4j Boot modules. Also add
> test suites to log4j-boot modules themselves to run those tests as part of
> their build.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1783) Add site config for Log4j Boot
[ https://issues.apache.org/jira/browse/LOG4J2-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker updated LOG4J2-1783: Fix Version/s: boot-1.0-alpha1 > Add site config for Log4j Boot > -- > > Key: LOG4J2-1783 > URL: https://issues.apache.org/jira/browse/LOG4J2-1783 > Project: Log4j 2 > Issue Type: Documentation > Components: Boot >Reporter: Matt Sicker > Fix For: boot-1.0-alpha1 > > > Add necessary maven-site-plugin configuration to get a multimodule site > buildable correctly so that it can eventually be committed to svn and > deployed to logging.apache.org. > This should include a changelog configuration that generates from JIRA using > the "Boot" component if possible. Otherwise, a manual changelog will need to > be included like in the main log4j2 repository. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1783) Add site config for Log4j Boot
[ https://issues.apache.org/jira/browse/LOG4J2-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15823031#comment-15823031 ] Matt Sicker commented on LOG4J2-1783: - I've added a minimal site config so far. Still need to configure more reports, make sure the multi-module site build works as expected, then determining how to structure documentation. > Add site config for Log4j Boot > -- > > Key: LOG4J2-1783 > URL: https://issues.apache.org/jira/browse/LOG4J2-1783 > Project: Log4j 2 > Issue Type: Documentation > Components: Boot >Reporter: Matt Sicker > > Add necessary maven-site-plugin configuration to get a multimodule site > buildable correctly so that it can eventually be committed to svn and > deployed to logging.apache.org. > This should include a changelog configuration that generates from JIRA using > the "Boot" component if possible. Otherwise, a manual changelog will need to > be included like in the main log4j2 repository. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1784) Large values for max in DefaultRolloverStrategy blocks application
[ https://issues.apache.org/jira/browse/LOG4J2-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15823030#comment-15823030 ] Charles Hache commented on LOG4J2-1784: --- Thanks for the prompt replies! Changing the configuration status to Trace is a good idea that I overlooked in my haste. Thanks for the tip. Simply discovering that the logger was affecting the application was a revelation that took a long time to realize, especially since the symptoms it caused are the same ones I'm trying to debug (namely funny inconsistent timing in written CSV files). I did see the notes about renaming in the documentation, but I naively assumed that by choosing a max value that was large enough to never be hit I would sidestep any performance issues (since if the max is never reached, no renaming is ever done). Of course upon reflection it's obvious that any such implementation would have to look at the potential existence of the files before creating the new one. Now that I have a better understanding of how it is working, I can see that there isn't really a way to safely get around the issue completely (unreasonably large max sizes will always have the potential to cause this problem). I propose a few rough changes to the docs which, to me at least, would have made things a bit clearer: "When the ascending attribute is set to true (the default) then the counter will be incremented and the current log file will be renamed to include the counter value." This ideally would more clearly indicate that a counter is not really being incremented, but that all the files in the directory are going to be looked at and a new counter will be calculated. Maybe sometime like "...then a new counter will be calculated to be one larger than the existing largest in the target directory..." Maybe that's a bit verbose, but something along those lines. "Note that with this counting strategy specifying a large maximum value may entirely avoid renaming files." This could be amended to "...may entirely avoid renaming files, but note that the logging system needs to check for the possible existence of log files up to the maximum value which could cause performance issues for very large maximum values." Finally "Given that this rollover algorithm requires as many file renaming operations as the window size, large window sizes are discouraged." This could be changed to specify that it has to do file lookups as well (not just potential renaming), so maybe like "Given that this rollover algorithm requires as many file lookups (and potential renaming operations) as the window size, large window sizes are discouraged." Hopefully this helps. Thanks for all the great work! > Large values for max in DefaultRolloverStrategy blocks application > ------ > > Key: LOG4J2-1784 > URL: https://issues.apache.org/jira/browse/LOG4J2-1784 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.7 > Environment: Played around a lot in 2.5, once realized issue was > related to log4j, upgraded to 2.7 and confirmed it is still happening. Using > on a raspberry pi. >Reporter: Charles Hache >Assignee: Ralph Goers > > Hi all, > I'm trying to debug an application which is using log4j2 for logging. After > discovering that by default the RollingRandomAccessFile only kept the last 7 > logs using the counter, I found the DefaultRolloverStrategy option and set > the max to something like 9, so in theory I wouldn't have to worry about > it. > A couple days later I started looking at everything again (log files from > log4j, timestamped CSV files from the application, etc) I can see something > is going terribly wrong. What I'm finding is that when it comes time to > rotate the logs, it looks like the whole application hangs. I see the > following: > - All logging to the log file stops; > - All my data going to the CSV files stop; > - CPU usage goes to 100%; > - I cannot stop my application cleanly; > After a while (~4-5 minutes) everything goes back to normal (until the next > log rotation), but then the first lines of the logs have timestamps like this: > 2017-01-14 07:43:00,001 INFO > 2017-01-14 07:42:11,329 DEBUG > 2017-01-14 07:47:26,648 TRACE > 2017-01-14 07:47:26,695 INFO > 2017-01-14 07:47:26,697 TRACE > 2017-01-14 07:47:26,737 INFO > 2017-01-14 07:47:26,739 TRACE > 2017-01-14 07:47:26,741 TRACE > 2017-01-14 07:47:26,744 TRACE > 2017-01-14 07:47:26,768 TRACE
[jira] [Comment Edited] (LOG4J2-1784) Large values for max in DefaultRolloverStrategy blocks application
[ https://issues.apache.org/jira/browse/LOG4J2-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15823016#comment-15823016 ] Ralph Goers edited comment on LOG4J2-1784 at 1/15/17 3:25 AM: -- Actually, this is a known problem and the documentation clearly tells you not to do this. When the file rolls it looks for all the files it might have to clean up so it looks for all the files between the min value and the max value one by one. I have actually been working on an enhancement to the RollingFileAppender and while reviewing this code realized that it could be modified to use a DirectoryStream to get just the set of qualifying files to look at. After I get my current enhancement working I might look into this one. Actually, in looking at the documentation I notice that nothing is mentioned there. The javadoc for the DefaultRolloverStrategy does say however, "Given that this rollover algorithm requires as many file renaming operations as the window size, large window sizes are discouraged.". The change I mentioned above would do nothing to fix this, so if you really do get a large number of files things would still get very slow. was (Author: ralphgoers): Actually, this is a known problem and the documentation clearly tells you not to do this. When the file rolls it looks for all the files it might have to clean up so it looks for all the files between the min value and the max value one by one. I have actually been working on an enhancement to the RollingFileAppender and while reviewing this code realized that it could be modified to use a DirectoryStream to get just the set of qualifying files to look at. After I get my current enhancement working I might look into this one. > Large values for max in DefaultRolloverStrategy blocks application > -- > > Key: LOG4J2-1784 > URL: https://issues.apache.org/jira/browse/LOG4J2-1784 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.7 > Environment: Played around a lot in 2.5, once realized issue was > related to log4j, upgraded to 2.7 and confirmed it is still happening. Using > on a raspberry pi. >Reporter: Charles Hache >Assignee: Ralph Goers > > Hi all, > I'm trying to debug an application which is using log4j2 for logging. After > discovering that by default the RollingRandomAccessFile only kept the last 7 > logs using the counter, I found the DefaultRolloverStrategy option and set > the max to something like 9, so in theory I wouldn't have to worry about > it. > A couple days later I started looking at everything again (log files from > log4j, timestamped CSV files from the application, etc) I can see something > is going terribly wrong. What I'm finding is that when it comes time to > rotate the logs, it looks like the whole application hangs. I see the > following: > - All logging to the log file stops; > - All my data going to the CSV files stop; > - CPU usage goes to 100%; > - I cannot stop my application cleanly; > After a while (~4-5 minutes) everything goes back to normal (until the next > log rotation), but then the first lines of the logs have timestamps like this: > 2017-01-14 07:43:00,001 INFO > 2017-01-14 07:42:11,329 DEBUG > 2017-01-14 07:47:26,648 TRACE > 2017-01-14 07:47:26,695 INFO > 2017-01-14 07:47:26,697 TRACE > 2017-01-14 07:47:26,737 INFO > 2017-01-14 07:47:26,739 TRACE > 2017-01-14 07:47:26,741 TRACE > 2017-01-14 07:47:26,744 TRACE > 2017-01-14 07:47:26,768 TRACE > Of note is that there is a gap of a few minutes in the first couple lines of > the file (I'm not too concerned about the out-of-order timestamps as lots of > different threads are logging). The application always writes many (dozens, > maybe hundreds) of lines per second, so a gap of a couple minutes is > uncharacteristic. The rest of the log file looks normal (has no gaps, has > log lines every few milliseconds). From my specific log lines and where they > are w.r.t. each other, I looks to me like calls to the logger are blocking > (eg: in cases I'll have a couple log lines that usually log 1-2 milliseconds > apart, but when they occur at rollover time they'll be minutes apart). > I shrunk the file size rollover to something small (256K), which I hit in > maybe 15 seconds or so, and it is clearly reproducible. When I reduced the > default rollover strategy max file to 40, the problem when away and I can see > it rolling over the file practically inst
[jira] [Assigned] (LOG4J2-1784) Large values for max in DefaultRolloverStrategy blocks application
[ https://issues.apache.org/jira/browse/LOG4J2-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers reassigned LOG4J2-1784: --- Assignee: Ralph Goers > Large values for max in DefaultRolloverStrategy blocks application > -- > > Key: LOG4J2-1784 > URL: https://issues.apache.org/jira/browse/LOG4J2-1784 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.7 > Environment: Played around a lot in 2.5, once realized issue was > related to log4j, upgraded to 2.7 and confirmed it is still happening. Using > on a raspberry pi. >Reporter: Charles Hache >Assignee: Ralph Goers > > Hi all, > I'm trying to debug an application which is using log4j2 for logging. After > discovering that by default the RollingRandomAccessFile only kept the last 7 > logs using the counter, I found the DefaultRolloverStrategy option and set > the max to something like 9, so in theory I wouldn't have to worry about > it. > A couple days later I started looking at everything again (log files from > log4j, timestamped CSV files from the application, etc) I can see something > is going terribly wrong. What I'm finding is that when it comes time to > rotate the logs, it looks like the whole application hangs. I see the > following: > - All logging to the log file stops; > - All my data going to the CSV files stop; > - CPU usage goes to 100%; > - I cannot stop my application cleanly; > After a while (~4-5 minutes) everything goes back to normal (until the next > log rotation), but then the first lines of the logs have timestamps like this: > 2017-01-14 07:43:00,001 INFO > 2017-01-14 07:42:11,329 DEBUG > 2017-01-14 07:47:26,648 TRACE > 2017-01-14 07:47:26,695 INFO > 2017-01-14 07:47:26,697 TRACE > 2017-01-14 07:47:26,737 INFO > 2017-01-14 07:47:26,739 TRACE > 2017-01-14 07:47:26,741 TRACE > 2017-01-14 07:47:26,744 TRACE > 2017-01-14 07:47:26,768 TRACE > Of note is that there is a gap of a few minutes in the first couple lines of > the file (I'm not too concerned about the out-of-order timestamps as lots of > different threads are logging). The application always writes many (dozens, > maybe hundreds) of lines per second, so a gap of a couple minutes is > uncharacteristic. The rest of the log file looks normal (has no gaps, has > log lines every few milliseconds). From my specific log lines and where they > are w.r.t. each other, I looks to me like calls to the logger are blocking > (eg: in cases I'll have a couple log lines that usually log 1-2 milliseconds > apart, but when they occur at rollover time they'll be minutes apart). > I shrunk the file size rollover to something small (256K), which I hit in > maybe 15 seconds or so, and it is clearly reproducible. When I reduced the > default rollover strategy max file to 40, the problem when away and I can see > it rolling over the file practically instantly. > The documentation for the DefaultRolloverStrategy says "When the ascending > attribute is set to true (the default) then the counter will be incremented > and the current log file will be renamed to include the counter value. If the > counter hits the maximum value then the oldest file, which will have the > smallest counter, will be deleted, all other files will be renamed to have > their counter decremented and then the current file will be renamed to have > the maximum counter value. Note that with this counting strategy specifying a > large maximum value may entirely avoid renaming files." > I took this to mean that having a value so large that it would never be hit > would be more efficient, since it doesn't have to do anything, just keep > counting up. I'm wondering now if it's doing something like "check if > log-1.log exists... check if log-2.log exist ... check if log-9.log > exists" but I don't see any iobound activity in iotop or anything (although I > can't say for sure if FS calls to see if something exists would show up > there, for example). > This might not necessarily be a bug in the logger per se, but it would at > least be a documentation issue if there is some O(n) operation based on the > max value for the DefaultRolloverStrategy. > I'd usually dig deeper, but now I still have to debug the original issues > with the actual application. Let me know if there is any more info I should > provide or if there is anything else I can do! > Thanks, > Charles -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1784) Large values for max in DefaultRolloverStrategy blocks application
[ https://issues.apache.org/jira/browse/LOG4J2-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers updated LOG4J2-1784: Issue Type: Improvement (was: Bug) > Large values for max in DefaultRolloverStrategy blocks application > -- > > Key: LOG4J2-1784 > URL: https://issues.apache.org/jira/browse/LOG4J2-1784 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.7 > Environment: Played around a lot in 2.5, once realized issue was > related to log4j, upgraded to 2.7 and confirmed it is still happening. Using > on a raspberry pi. >Reporter: Charles Hache > > Hi all, > I'm trying to debug an application which is using log4j2 for logging. After > discovering that by default the RollingRandomAccessFile only kept the last 7 > logs using the counter, I found the DefaultRolloverStrategy option and set > the max to something like 9, so in theory I wouldn't have to worry about > it. > A couple days later I started looking at everything again (log files from > log4j, timestamped CSV files from the application, etc) I can see something > is going terribly wrong. What I'm finding is that when it comes time to > rotate the logs, it looks like the whole application hangs. I see the > following: > - All logging to the log file stops; > - All my data going to the CSV files stop; > - CPU usage goes to 100%; > - I cannot stop my application cleanly; > After a while (~4-5 minutes) everything goes back to normal (until the next > log rotation), but then the first lines of the logs have timestamps like this: > 2017-01-14 07:43:00,001 INFO > 2017-01-14 07:42:11,329 DEBUG > 2017-01-14 07:47:26,648 TRACE > 2017-01-14 07:47:26,695 INFO > 2017-01-14 07:47:26,697 TRACE > 2017-01-14 07:47:26,737 INFO > 2017-01-14 07:47:26,739 TRACE > 2017-01-14 07:47:26,741 TRACE > 2017-01-14 07:47:26,744 TRACE > 2017-01-14 07:47:26,768 TRACE > Of note is that there is a gap of a few minutes in the first couple lines of > the file (I'm not too concerned about the out-of-order timestamps as lots of > different threads are logging). The application always writes many (dozens, > maybe hundreds) of lines per second, so a gap of a couple minutes is > uncharacteristic. The rest of the log file looks normal (has no gaps, has > log lines every few milliseconds). From my specific log lines and where they > are w.r.t. each other, I looks to me like calls to the logger are blocking > (eg: in cases I'll have a couple log lines that usually log 1-2 milliseconds > apart, but when they occur at rollover time they'll be minutes apart). > I shrunk the file size rollover to something small (256K), which I hit in > maybe 15 seconds or so, and it is clearly reproducible. When I reduced the > default rollover strategy max file to 40, the problem when away and I can see > it rolling over the file practically instantly. > The documentation for the DefaultRolloverStrategy says "When the ascending > attribute is set to true (the default) then the counter will be incremented > and the current log file will be renamed to include the counter value. If the > counter hits the maximum value then the oldest file, which will have the > smallest counter, will be deleted, all other files will be renamed to have > their counter decremented and then the current file will be renamed to have > the maximum counter value. Note that with this counting strategy specifying a > large maximum value may entirely avoid renaming files." > I took this to mean that having a value so large that it would never be hit > would be more efficient, since it doesn't have to do anything, just keep > counting up. I'm wondering now if it's doing something like "check if > log-1.log exists... check if log-2.log exist ... check if log-9.log > exists" but I don't see any iobound activity in iotop or anything (although I > can't say for sure if FS calls to see if something exists would show up > there, for example). > This might not necessarily be a bug in the logger per se, but it would at > least be a documentation issue if there is some O(n) operation based on the > max value for the DefaultRolloverStrategy. > I'd usually dig deeper, but now I still have to debug the original issues > with the actual application. Let me know if there is any more info I should > provide or if there is anything else I can do! > Thanks, > Charles -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-1786) ConfigurationScheduler should preserve interrupt flag during stop
[
https://issues.apache.org/jira/browse/LOG4J2-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma closed LOG4J2-1786.
---
Resolution: Fixed
Fixed in master in commit 1f06ca4.
> ConfigurationScheduler should preserve interrupt flag during stop
> -
>
> Key: LOG4J2-1786
> URL: https://issues.apache.org/jira/browse/LOG4J2-1786
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.8
>
>
> ConfigurationScheduler catches InterruptedException but does not restore the
> interrupted flag. Should be:
> {code}
> ...
> } catch (InterruptedException ie) {
> ...
> // Preserve interrupt status
> Thread.currentThread().interrupt();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1786) ConfigurationScheduler should preserve interrupt flag during stop
[
https://issues.apache.org/jira/browse/LOG4J2-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-1786:
Summary: ConfigurationScheduler should preserve interrupt flag during stop
(was: ConfigurationScheduler should preserve interrupt flag during shutdown)
> ConfigurationScheduler should preserve interrupt flag during stop
> -
>
> Key: LOG4J2-1786
> URL: https://issues.apache.org/jira/browse/LOG4J2-1786
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.8
>
>
> ConfigurationScheduler catches InterruptedException but does not restore the
> interrupted flag. Should be:
> {code}
> ...
> } catch (InterruptedException ie) {
> ...
> // Preserve interrupt status
> Thread.currentThread().interrupt();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-1786) ConfigurationScheduler should preserve interrupt flag during shutdown
Remko Popma created LOG4J2-1786:
---
Summary: ConfigurationScheduler should preserve interrupt flag
during shutdown
Key: LOG4J2-1786
URL: https://issues.apache.org/jira/browse/LOG4J2-1786
Project: Log4j 2
Issue Type: Bug
Components: Core
Reporter: Remko Popma
Assignee: Remko Popma
Fix For: 2.8
ConfigurationScheduler catches InterruptedException but does not restore the
interrupted flag. Should be:
{code}
...
} catch (InterruptedException ie) {
...
// Preserve interrupt status
Thread.currentThread().interrupt();
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-1785) Add Spring Boot integration to Log4j Boot
[ https://issues.apache.org/jira/browse/LOG4J2-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker resolved LOG4J2-1785. - Resolution: Fixed Added to master. Not going to close until I have proper fix versions set for Boot. > Add Spring Boot integration to Log4j Boot > - > > Key: LOG4J2-1785 > URL: https://issues.apache.org/jira/browse/LOG4J2-1785 > Project: Log4j 2 > Issue Type: New Feature > Components: Boot >Reporter: Matt Sicker >Assignee: Matt Sicker > > The Spring Boot integration packaged by Spring for Log4j2 uses SLF4J > libraries instead of the Log4j ones. This module should use native Log4j > bridges and use native functionality wherever possible. > This should include sensible default config files ported from > spring-boot-starter-log4j2. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-1785) Add Spring Boot integration to Log4j Boot
Matt Sicker created LOG4J2-1785: --- Summary: Add Spring Boot integration to Log4j Boot Key: LOG4J2-1785 URL: https://issues.apache.org/jira/browse/LOG4J2-1785 Project: Log4j 2 Issue Type: New Feature Components: Boot Reporter: Matt Sicker Assignee: Matt Sicker The Spring Boot integration packaged by Spring for Log4j2 uses SLF4J libraries instead of the Log4j ones. This module should use native Log4j bridges and use native functionality wherever possible. This should include sensible default config files ported from spring-boot-starter-log4j2. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-1784) Large values for max in DefaultRolloverStrategy blocks application
[
https://issues.apache.org/jira/browse/LOG4J2-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15822991#comment-15822991
]
Remko Popma edited comment on LOG4J2-1784 at 1/14/17 11:32 PM:
---
During the rollover Log4j2 will log what it's doing to the internal status
logger. You can make the internal status logs print to the console by changing
{{}} in your configuration.
Large values for Max may cause a lot of rolled over files to remain which will
result in long scanning and renaming times. I agree we should document that
better. Suggestions welcome.
was (Author: rem...@yahoo.com):
During the rollover Log4j2 will log what it's doing to the internal status
logger. You can make the internal status logs print to the console by changing
{{}} in your configuration.
> Large values for max in DefaultRolloverStrategy blocks application
> --
>
> Key: LOG4J2-1784
> URL: https://issues.apache.org/jira/browse/LOG4J2-1784
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.7
> Environment: Played around a lot in 2.5, once realized issue was
> related to log4j, upgraded to 2.7 and confirmed it is still happening. Using
> on a raspberry pi.
>Reporter: Charles Hache
>
> Hi all,
> I'm trying to debug an application which is using log4j2 for logging. After
> discovering that by default the RollingRandomAccessFile only kept the last 7
> logs using the counter, I found the DefaultRolloverStrategy option and set
> the max to something like 9, so in theory I wouldn't have to worry about
> it.
> A couple days later I started looking at everything again (log files from
> log4j, timestamped CSV files from the application, etc) I can see something
> is going terribly wrong. What I'm finding is that when it comes time to
> rotate the logs, it looks like the whole application hangs. I see the
> following:
> - All logging to the log file stops;
> - All my data going to the CSV files stop;
> - CPU usage goes to 100%;
> - I cannot stop my application cleanly;
> After a while (~4-5 minutes) everything goes back to normal (until the next
> log rotation), but then the first lines of the logs have timestamps like this:
> 2017-01-14 07:43:00,001 INFO
> 2017-01-14 07:42:11,329 DEBUG
> 2017-01-14 07:47:26,648 TRACE
> 2017-01-14 07:47:26,695 INFO
> 2017-01-14 07:47:26,697 TRACE
> 2017-01-14 07:47:26,737 INFO
> 2017-01-14 07:47:26,739 TRACE
> 2017-01-14 07:47:26,741 TRACE
> 2017-01-14 07:47:26,744 TRACE
> 2017-01-14 07:47:26,768 TRACE
> Of note is that there is a gap of a few minutes in the first couple lines of
> the file (I'm not too concerned about the out-of-order timestamps as lots of
> different threads are logging). The application always writes many (dozens,
> maybe hundreds) of lines per second, so a gap of a couple minutes is
> uncharacteristic. The rest of the log file looks normal (has no gaps, has
> log lines every few milliseconds). From my specific log lines and where they
> are w.r.t. each other, I looks to me like calls to the logger are blocking
> (eg: in cases I'll have a couple log lines that usually log 1-2 milliseconds
> apart, but when they occur at rollover time they'll be minutes apart).
> I shrunk the file size rollover to something small (256K), which I hit in
> maybe 15 seconds or so, and it is clearly reproducible. When I reduced the
> default rollover strategy max file to 40, the problem when away and I can see
> it rolling over the file practically instantly.
> The documentation for the DefaultRolloverStrategy says "When the ascending
> attribute is set to true (the default) then the counter will be incremented
> and the current log file will be renamed to include the counter value. If the
> counter hits the maximum value then the oldest file, which will have the
> smallest counter, will be deleted, all other files will be renamed to have
> their counter decremented and then the current file will be renamed to have
> the maximum counter value. Note that with this counting strategy specifying a
> large maximum value may entirely avoid renaming files."
> I took this to mean that having a value so large that it would never be hit
> would be more efficient, since it doesn't have to do anything, just keep
> counting up. I'm wondering now if it's doing something like "check if
> log-1.log exists... check if log-2.log exist ... check if log-9.l
[jira] [Commented] (LOG4J2-1784) Large values for max in DefaultRolloverStrategy blocks application
[
https://issues.apache.org/jira/browse/LOG4J2-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15822991#comment-15822991
]
Remko Popma commented on LOG4J2-1784:
-
During the rollover Log4j2 will log what it's doing to the internal status
logger. You can make the internal status logs print to the console by changing
{{}} in your configuration.
> Large values for max in DefaultRolloverStrategy blocks application
> --
>
> Key: LOG4J2-1784
> URL: https://issues.apache.org/jira/browse/LOG4J2-1784
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.7
> Environment: Played around a lot in 2.5, once realized issue was
> related to log4j, upgraded to 2.7 and confirmed it is still happening. Using
> on a raspberry pi.
>Reporter: Charles Hache
>
> Hi all,
> I'm trying to debug an application which is using log4j2 for logging. After
> discovering that by default the RollingRandomAccessFile only kept the last 7
> logs using the counter, I found the DefaultRolloverStrategy option and set
> the max to something like 9, so in theory I wouldn't have to worry about
> it.
> A couple days later I started looking at everything again (log files from
> log4j, timestamped CSV files from the application, etc) I can see something
> is going terribly wrong. What I'm finding is that when it comes time to
> rotate the logs, it looks like the whole application hangs. I see the
> following:
> - All logging to the log file stops;
> - All my data going to the CSV files stop;
> - CPU usage goes to 100%;
> - I cannot stop my application cleanly;
> After a while (~4-5 minutes) everything goes back to normal (until the next
> log rotation), but then the first lines of the logs have timestamps like this:
> 2017-01-14 07:43:00,001 INFO
> 2017-01-14 07:42:11,329 DEBUG
> 2017-01-14 07:47:26,648 TRACE
> 2017-01-14 07:47:26,695 INFO
> 2017-01-14 07:47:26,697 TRACE
> 2017-01-14 07:47:26,737 INFO
> 2017-01-14 07:47:26,739 TRACE
> 2017-01-14 07:47:26,741 TRACE
> 2017-01-14 07:47:26,744 TRACE
> 2017-01-14 07:47:26,768 TRACE
> Of note is that there is a gap of a few minutes in the first couple lines of
> the file (I'm not too concerned about the out-of-order timestamps as lots of
> different threads are logging). The application always writes many (dozens,
> maybe hundreds) of lines per second, so a gap of a couple minutes is
> uncharacteristic. The rest of the log file looks normal (has no gaps, has
> log lines every few milliseconds). From my specific log lines and where they
> are w.r.t. each other, I looks to me like calls to the logger are blocking
> (eg: in cases I'll have a couple log lines that usually log 1-2 milliseconds
> apart, but when they occur at rollover time they'll be minutes apart).
> I shrunk the file size rollover to something small (256K), which I hit in
> maybe 15 seconds or so, and it is clearly reproducible. When I reduced the
> default rollover strategy max file to 40, the problem when away and I can see
> it rolling over the file practically instantly.
> The documentation for the DefaultRolloverStrategy says "When the ascending
> attribute is set to true (the default) then the counter will be incremented
> and the current log file will be renamed to include the counter value. If the
> counter hits the maximum value then the oldest file, which will have the
> smallest counter, will be deleted, all other files will be renamed to have
> their counter decremented and then the current file will be renamed to have
> the maximum counter value. Note that with this counting strategy specifying a
> large maximum value may entirely avoid renaming files."
> I took this to mean that having a value so large that it would never be hit
> would be more efficient, since it doesn't have to do anything, just keep
> counting up. I'm wondering now if it's doing something like "check if
> log-1.log exists... check if log-2.log exist ... check if log-9.log
> exists" but I don't see any iobound activity in iotop or anything (although I
> can't say for sure if FS calls to see if something exists would show up
> there, for example).
> This might not necessarily be a bug in the logger per se, but it would at
> least be a documentation issue if there is some O(n) operation based on the
> max value for the DefaultRoll
[jira] [Comment Edited] (LOG4J2-1784) Large values for max in DefaultRolloverStrategy blocks application
[
https://issues.apache.org/jira/browse/LOG4J2-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15822945#comment-15822945
]
Charles Hache edited comment on LOG4J2-1784 at 1/14/17 8:29 PM:
My config might be useful...:
{noformat}
%d %p %c{1.} [%t] %m%n
{noformat}
was (Author: chache):
My config might be useful...:
{norformat}
%d %p %c{1.} [%t] %m%n
{norformat}
> Large values for max in DefaultRolloverStrategy blocks application
> --
>
> Key: LOG4J2-1784
> URL: https://issues.apache.org/jira/browse/LOG4J2-1784
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.7
> Environment: Played around a lot in 2.5, once realized issue was
> related to log4j, upgraded to 2.7 and confirmed it is still happening. Using
> on a raspberry pi.
>Reporter: Charles Hache
>
> Hi all,
> I'm trying to debug an application which is using log4j2 for logging. After
> discovering that by default the RollingRandomAccessFile only kept the last 7
> logs using the counter, I found the DefaultRolloverStrategy option and set
> the max to something like 9, so in theory I wouldn't have to worry about
> it.
> A couple days later I started looking at everything again (log files from
> log4j, timestamped CSV files from the application, etc) I can see something
> is going terribly wrong. What I'm finding is that when it comes time to
> rotate the logs, it looks like the whole application hangs. I see the
> following:
> - All logging to the log file stops;
> - All my data going to the CSV files stop;
> - CPU usage goes to 100%;
> - I cannot stop my application cleanly;
> After a while (~4-5 minutes) everything goes back to normal (until the next
> log rotation), but then the first lines of the logs have timestamps like this:
> 2017-01-14 07:43:00,001 INFO
> 2017-01-14 07:42:11,329 DEBUG
> 2017-01-14 07:47:26,648 TRACE
> 2017-01-14 07:47:26,695 INFO
> 2017-01-14 07:47:26,697 TRACE
> 2017-01-14 07:47:26,737 INFO
> 2017-01-14 07:47:26,739 TRACE
> 2017-01-14 07:47:26,741 TRACE
> 2017-01-14 07:47:26,744 TRACE
> 2017-01-14 07:47:26,768 TRACE
> Of note is that there is a gap of a few minutes in the first couple lines of
> the file (I'm not too concerned about the out-of-order timestamps as lots of
> different threads are logging). The application always writes many (dozens,
> maybe hundreds) of lines per second, so a gap of a couple minutes is
> uncharacteristic. The rest of the log file looks normal (has no gaps, has
> log lines every few milliseconds). From my specific log lines and where they
> are w.r.t. each other, I looks to me like calls to the logger are blocking
> (eg: in cases I'll have a couple log lines that usually log 1-2 milliseconds
> apart, but when they occur at rollover time they'll be minutes apart).
> I shrunk the file size rollover to something small (256K), which I hit in
> maybe 15 seconds or so, and it is clearly reproducible. When I reduced the
> default rollover strategy max file to 40, the problem when away and I can see
> it rolling over the file practically instantly.
> The documentation for the DefaultRolloverStrategy says "When the ascending
> attribute is set to true (the default) then the counter will be incremented
> and the current log file will be renamed to include the counter value. If the
> counter hits the maximum value then the oldest file, which will have the
> smallest counter, will be deleted, all other files will be renamed to have
> their counter decremented and then the current file will be renamed to have
> the maximum counter value. No
[jira] [Comment Edited] (LOG4J2-1784) Large values for max in DefaultRolloverStrategy blocks application
[
https://issues.apache.org/jira/browse/LOG4J2-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15822945#comment-15822945
]
Charles Hache edited comment on LOG4J2-1784 at 1/14/17 8:28 PM:
My config might be useful...:
{norformat}
%d %p %c{1.} [%t] %m%n
{norformat}
was (Author: chache):
My config might be useful...:
%d %p %c{1.} [%t] %m%n
> Large values for max in DefaultRolloverStrategy blocks application
> --
>
> Key: LOG4J2-1784
> URL: https://issues.apache.org/jira/browse/LOG4J2-1784
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.7
> Environment: Played around a lot in 2.5, once realized issue was
> related to log4j, upgraded to 2.7 and confirmed it is still happening. Using
> on a raspberry pi.
>Reporter: Charles Hache
>
> Hi all,
> I'm trying to debug an application which is using log4j2 for logging. After
> discovering that by default the RollingRandomAccessFile only kept the last 7
> logs using the counter, I found the DefaultRolloverStrategy option and set
> the max to something like 9, so in theory I wouldn't have to worry about
> it.
> A couple days later I started looking at everything again (log files from
> log4j, timestamped CSV files from the application, etc) I can see something
> is going terribly wrong. What I'm finding is that when it comes time to
> rotate the logs, it looks like the whole application hangs. I see the
> following:
> - All logging to the log file stops;
> - All my data going to the CSV files stop;
> - CPU usage goes to 100%;
> - I cannot stop my application cleanly;
> After a while (~4-5 minutes) everything goes back to normal (until the next
> log rotation), but then the first lines of the logs have timestamps like this:
> 2017-01-14 07:43:00,001 INFO
> 2017-01-14 07:42:11,329 DEBUG
> 2017-01-14 07:47:26,648 TRACE
> 2017-01-14 07:47:26,695 INFO
> 2017-01-14 07:47:26,697 TRACE
> 2017-01-14 07:47:26,737 INFO
> 2017-01-14 07:47:26,739 TRACE
> 2017-01-14 07:47:26,741 TRACE
> 2017-01-14 07:47:26,744 TRACE
> 2017-01-14 07:47:26,768 TRACE
> Of note is that there is a gap of a few minutes in the first couple lines of
> the file (I'm not too concerned about the out-of-order timestamps as lots of
> different threads are logging). The application always writes many (dozens,
> maybe hundreds) of lines per second, so a gap of a couple minutes is
> uncharacteristic. The rest of the log file looks normal (has no gaps, has
> log lines every few milliseconds). From my specific log lines and where they
> are w.r.t. each other, I looks to me like calls to the logger are blocking
> (eg: in cases I'll have a couple log lines that usually log 1-2 milliseconds
> apart, but when they occur at rollover time they'll be minutes apart).
> I shrunk the file size rollover to something small (256K), which I hit in
> maybe 15 seconds or so, and it is clearly reproducible. When I reduced the
> default rollover strategy max file to 40, the problem when away and I can see
> it rolling over the file practically instantly.
> The documentation for the DefaultRolloverStrategy says "When the ascending
> attribute is set to true (the default) then the counter will be incremented
> and the current log file will be renamed to include the counter value. If the
> counter hits the maximum value then the oldest file, which will have the
> smallest counter, will be deleted, all other files will be renamed to have
> their counter decremented and then the current file will be renamed to have
> the maximum counter value. Note that with this counting s
[jira] [Commented] (LOG4J2-1784) Large values for max in DefaultRolloverStrategy blocks application
[
https://issues.apache.org/jira/browse/LOG4J2-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15822945#comment-15822945
]
Charles Hache commented on LOG4J2-1784:
---
My config might be useful...:
%d %p %c{1.} [%t] %m%n
> Large values for max in DefaultRolloverStrategy blocks application
> --
>
> Key: LOG4J2-1784
> URL: https://issues.apache.org/jira/browse/LOG4J2-1784
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.7
> Environment: Played around a lot in 2.5, once realized issue was
> related to log4j, upgraded to 2.7 and confirmed it is still happening. Using
> on a raspberry pi.
>Reporter: Charles Hache
>
> Hi all,
> I'm trying to debug an application which is using log4j2 for logging. After
> discovering that by default the RollingRandomAccessFile only kept the last 7
> logs using the counter, I found the DefaultRolloverStrategy option and set
> the max to something like 9, so in theory I wouldn't have to worry about
> it.
> A couple days later I started looking at everything again (log files from
> log4j, timestamped CSV files from the application, etc) I can see something
> is going terribly wrong. What I'm finding is that when it comes time to
> rotate the logs, it looks like the whole application hangs. I see the
> following:
> - All logging to the log file stops;
> - All my data going to the CSV files stop;
> - CPU usage goes to 100%;
> - I cannot stop my application cleanly;
> After a while (~4-5 minutes) everything goes back to normal (until the next
> log rotation), but then the first lines of the logs have timestamps like this:
> 2017-01-14 07:43:00,001 INFO
> 2017-01-14 07:42:11,329 DEBUG
> 2017-01-14 07:47:26,648 TRACE
> 2017-01-14 07:47:26,695 INFO
> 2017-01-14 07:47:26,697 TRACE
> 2017-01-14 07:47:26,737 INFO
> 2017-01-14 07:47:26,739 TRACE
> 2017-01-14 07:47:26,741 TRACE
> 2017-01-14 07:47:26,744 TRACE
> 2017-01-14 07:47:26,768 TRACE
> Of note is that there is a gap of a few minutes in the first couple lines of
> the file (I'm not too concerned about the out-of-order timestamps as lots of
> different threads are logging). The application always writes many (dozens,
> maybe hundreds) of lines per second, so a gap of a couple minutes is
> uncharacteristic. The rest of the log file looks normal (has no gaps, has
> log lines every few milliseconds). From my specific log lines and where they
> are w.r.t. each other, I looks to me like calls to the logger are blocking
> (eg: in cases I'll have a couple log lines that usually log 1-2 milliseconds
> apart, but when they occur at rollover time they'll be minutes apart).
> I shrunk the file size rollover to something small (256K), which I hit in
> maybe 15 seconds or so, and it is clearly reproducible. When I reduced the
> default rollover strategy max file to 40, the problem when away and I can see
> it rolling over the file practically instantly.
> The documentation for the DefaultRolloverStrategy says "When the ascending
> attribute is set to true (the default) then the counter will be incremented
> and the current log file will be renamed to include the counter value. If the
> counter hits the maximum value then the oldest file, which will have the
> smallest counter, will be deleted, all other files will be renamed to have
> their counter decremented and then the current file will be renamed to have
> the maximum counter value. Note that with this counting strategy specifying a
> large maximum value may entirely avoid renaming files."
> I took this to mean that having a value so large that it would never be hit
> would be more efficient, since it doesn't have to do anything, just keep
> counting up. I'm wondering now if it's doing something like "check if
> log-1.log exists... check if log-2.log exist ... check if log-9.log
> exists" but I don't see any iobound activity in iotop or anything (although I
> can't say for sure if FS calls to see if something exists
[jira] [Created] (LOG4J2-1784) Large values for max in DefaultRolloverStrategy blocks application
Charles Hache created LOG4J2-1784: - Summary: Large values for max in DefaultRolloverStrategy blocks application Key: LOG4J2-1784 URL: https://issues.apache.org/jira/browse/LOG4J2-1784 Project: Log4j 2 Issue Type: Bug Components: Appenders Affects Versions: 2.7 Environment: Played around a lot in 2.5, once realized issue was related to log4j, upgraded to 2.7 and confirmed it is still happening. Using on a raspberry pi. Reporter: Charles Hache Hi all, I'm trying to debug an application which is using log4j2 for logging. After discovering that by default the RollingRandomAccessFile only kept the last 7 logs using the counter, I found the DefaultRolloverStrategy option and set the max to something like 9, so in theory I wouldn't have to worry about it. A couple days later I started looking at everything again (log files from log4j, timestamped CSV files from the application, etc) I can see something is going terribly wrong. What I'm finding is that when it comes time to rotate the logs, it looks like the whole application hangs. I see the following: - All logging to the log file stops; - All my data going to the CSV files stop; - CPU usage goes to 100%; - I cannot stop my application cleanly; After a while (~4-5 minutes) everything goes back to normal (until the next log rotation), but then the first lines of the logs have timestamps like this: 2017-01-14 07:43:00,001 INFO 2017-01-14 07:42:11,329 DEBUG 2017-01-14 07:47:26,648 TRACE 2017-01-14 07:47:26,695 INFO 2017-01-14 07:47:26,697 TRACE 2017-01-14 07:47:26,737 INFO 2017-01-14 07:47:26,739 TRACE 2017-01-14 07:47:26,741 TRACE 2017-01-14 07:47:26,744 TRACE 2017-01-14 07:47:26,768 TRACE Of note is that there is a gap of a few minutes in the first couple lines of the file (I'm not too concerned about the out-of-order timestamps as lots of different threads are logging). The application always writes many (dozens, maybe hundreds) of lines per second, so a gap of a couple minutes is uncharacteristic. The rest of the log file looks normal (has no gaps, has log lines every few milliseconds). From my specific log lines and where they are w.r.t. each other, I looks to me like calls to the logger are blocking (eg: in cases I'll have a couple log lines that usually log 1-2 milliseconds apart, but when they occur at rollover time they'll be minutes apart). I shrunk the file size rollover to something small (256K), which I hit in maybe 15 seconds or so, and it is clearly reproducible. When I reduced the default rollover strategy max file to 40, the problem when away and I can see it rolling over the file practically instantly. The documentation for the DefaultRolloverStrategy says "When the ascending attribute is set to true (the default) then the counter will be incremented and the current log file will be renamed to include the counter value. If the counter hits the maximum value then the oldest file, which will have the smallest counter, will be deleted, all other files will be renamed to have their counter decremented and then the current file will be renamed to have the maximum counter value. Note that with this counting strategy specifying a large maximum value may entirely avoid renaming files." I took this to mean that having a value so large that it would never be hit would be more efficient, since it doesn't have to do anything, just keep counting up. I'm wondering now if it's doing something like "check if log-1.log exists... check if log-2.log exist ... check if log-9.log exists" but I don't see any iobound activity in iotop or anything (although I can't say for sure if FS calls to see if something exists would show up there, for example). This might not necessarily be a bug in the logger per se, but it would at least be a documentation issue if there is some O(n) operation based on the max value for the DefaultRolloverStrategy. I'd usually dig deeper, but now I still have to debug the original issues with the actual application. Let me know if there is any more info I should provide or if there is anything else I can do! Thanks, Charles -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1783) Add site config for Log4j Boot
[ https://issues.apache.org/jira/browse/LOG4J2-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker updated LOG4J2-1783: Description: Add necessary maven-site-plugin configuration to get a multimodule site buildable correctly so that it can eventually be committed to svn and deployed to logging.apache.org. This should include a changelog configuration that generates from JIRA using the "Boot" component if possible. Otherwise, a manual changelog will need to be included like in the main log4j2 repository. was:Add necessary maven-site-plugin configuration to get a multimodule site buildable correctly so that it can eventually be committed to svn and deployed to logging.apache.org. > Add site config for Log4j Boot > -- > > Key: LOG4J2-1783 > URL: https://issues.apache.org/jira/browse/LOG4J2-1783 > Project: Log4j 2 > Issue Type: Documentation > Components: Boot >Reporter: Matt Sicker > > Add necessary maven-site-plugin configuration to get a multimodule site > buildable correctly so that it can eventually be committed to svn and > deployed to logging.apache.org. > This should include a changelog configuration that generates from JIRA using > the "Boot" component if possible. Otherwise, a manual changelog will need to > be included like in the main log4j2 repository. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-1783) Add site config for Log4j Boot
Matt Sicker created LOG4J2-1783: --- Summary: Add site config for Log4j Boot Key: LOG4J2-1783 URL: https://issues.apache.org/jira/browse/LOG4J2-1783 Project: Log4j 2 Issue Type: Documentation Components: Boot Reporter: Matt Sicker Add necessary maven-site-plugin configuration to get a multimodule site buildable correctly so that it can eventually be committed to svn and deployed to logging.apache.org. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-1782) Upgrade to JCTools from 1.2.1 to 2.0.1
Matt Sicker created LOG4J2-1782: --- Summary: Upgrade to JCTools from 1.2.1 to 2.0.1 Key: LOG4J2-1782 URL: https://issues.apache.org/jira/browse/LOG4J2-1782 Project: Log4j 2 Issue Type: Dependency upgrade Components: Appenders Reporter: Matt Sicker Upgrade to JCTools version 2.0.1. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-1781) Update Conversant Disruptor from 1.2.7 to 1.2.10
[
https://issues.apache.org/jira/browse/LOG4J2-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker closed LOG4J2-1781.
---
Resolution: Fixed
Added to master.
> Update Conversant Disruptor from 1.2.7 to 1.2.10
>
>
> Key: LOG4J2-1781
> URL: https://issues.apache.org/jira/browse/LOG4J2-1781
> Project: Log4j 2
> Issue Type: Dependency upgrade
> Components: Appenders
>Reporter: Matt Sicker
>Assignee: Matt Sicker
> Fix For: 2.8
>
>
> The newer releases have also added a {{jdk7}} maven
> property for multi-jdk support.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-1781) Update Conversant Disruptor from 1.2.7 to 1.2.10
Matt Sicker created LOG4J2-1781:
---
Summary: Update Conversant Disruptor from 1.2.7 to 1.2.10
Key: LOG4J2-1781
URL: https://issues.apache.org/jira/browse/LOG4J2-1781
Project: Log4j 2
Issue Type: Dependency upgrade
Components: Appenders
Reporter: Matt Sicker
Assignee: Matt Sicker
Fix For: 2.8
The newer releases have also added a {{jdk7}} maven
property for multi-jdk support.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1776) log4j-boot pom modules for dependency management
[
https://issues.apache.org/jira/browse/LOG4J2-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker updated LOG4J2-1776:
Description:
This is the main feature for the Log4j Boot epic (LOG4J2-1775).
{code}
groupId: org.apache.logging.log4j.boot
artifactId: log4j-boot-*
{code}
* core: just log4j-core basically
* async (for AsyncLogger; brings in LMAX disruptor)
* compat: log4j-slf4j-impl, log4j-jul, log4j-jcl, log4j-1.2-api
* logback (for log4j-to-slf4j, slf4j-spi, logback; this helps aid migration to
log4j-api and promotes it as a general use logging API)
* advertiser-jmdns
* appender-async-conversant
* appender-async-jctools
* appender-cassandra
* appender-couchdb
* appender-jms
* appender-jpa
* appender-kafka
* appender-mongodb
* appender-smtp
* appender-zeromq
* config-json
* config-yaml
* layout-csv
* layout-jansi (for windows users and coloured log messages)
* layout-json (unless this has been ported to not require jackson anymore?)
* layout-xml
* layout-yaml
* script-groovy
I may have missed a few, but the base set of starters should at least
correspond to all optional dependencies in log4j-core or the addon modules. For
the jms, jpa, and smtp (log4j-core) appenders, we could either make add in a
default provider (e.g., ActiveMQ, Hibernate, and Sun Mail respectively) or
split those into provider-specific starters.
was:
This is the main feature for the Log4j Boot epic (LOG4J2-1775).
{code}
groupId: org.apache.logging.log4j.boot
artifactId: log4j-boot-*
{code}
* core: just log4j-core basically
* async (for AsyncLogger; brings in LMAX disruptor)
* log4j-spi: log4j-slf4j-impl, log4j-jul, log4j-jcl, log4j-1.2-api
* slf4j-spi: slf4j-impl, jcl-over-slf4j, jul-to-slf4j (same dependency set as
spring-boot-starter-log4j2)
* logback (for log4j-to-slf4j, slf4j-spi, logback; this helps aid migration to
log4j-api and promotes it as a general use logging API)
* advertiser-jmdns
* appender-async-conversant
* appender-async-jctools
* appender-cassandra
* appender-couchdb
* appender-jms
* appender-jpa
* appender-kafka
* appender-mongodb
* appender-smtp
* appender-zeromq
* config-json
* config-yaml
* layout-csv
* layout-jansi (for windows users and coloured log messages)
* layout-json (unless this has been ported to not require jackson anymore?)
* layout-xml
* layout-yaml
* script-groovy
I may have missed a few, but the base set of starters should at least
correspond to all optional dependencies in log4j-core or the addon modules. For
the jms, jpa, and smtp (log4j-core) appenders, we could either make add in a
default provider (e.g., ActiveMQ, Hibernate, and Sun Mail respectively) or
split those into provider-specific starters.
> log4j-boot pom modules for dependency management
>
>
> Key: LOG4J2-1776
> URL: https://issues.apache.org/jira/browse/LOG4J2-1776
> Project: Log4j 2
> Issue Type: New Feature
> Components: Boot
>Reporter: Matt Sicker
>
> This is the main feature for the Log4j Boot epic (LOG4J2-1775).
> {code}
> groupId: org.apache.logging.log4j.boot
> artifactId: log4j-boot-*
> {code}
> * core: just log4j-core basically
> * async (for AsyncLogger; brings in LMAX disruptor)
> * compat: log4j-slf4j-impl, log4j-jul, log4j-jcl, log4j-1.2-api
> * logback (for log4j-to-slf4j, slf4j-spi, logback; this helps aid migration
> to log4j-api and promotes it as a general use logging API)
> * advertiser-jmdns
> * appender-async-conversant
> * appender-async-jctools
> * appender-cassandra
> * appender-couchdb
> * appender-jms
> * appender-jpa
> * appender-kafka
> * appender-mongodb
> * appender-smtp
> * appender-zeromq
> * config-json
> * config-yaml
> * layout-csv
> * layout-jansi (for windows users and coloured log messages)
> * layout-json (unless this has been ported to not require jackson anymore?)
> * layout-xml
> * layout-yaml
> * script-groovy
> I may have missed a few, but the base set of starters should at least
> correspond to all optional dependencies in log4j-core or the addon modules.
> For the jms, jpa, and smtp (log4j-core) appenders, we could either make add
> in a default provider (e.g., ActiveMQ, Hibernate, and Sun Mail respectively)
> or split those into provider-specific starters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1694) Allow to easily add fields with fixed values to JSON output
[
https://issues.apache.org/jira/browse/LOG4J2-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15821805#comment-15821805
]
gpolaert commented on LOG4J2-1694:
--
Hello,
IMO, allow user to add `` is really useful.
So, is someone assigned to this issue? If no, I can work on it and submit a PR
if you want.
> Allow to easily add fields with fixed values to JSON output
> ---
>
> Key: LOG4J2-1694
> URL: https://issues.apache.org/jira/browse/LOG4J2-1694
> Project: Log4j 2
> Issue Type: Improvement
> Components: Layouts
>Affects Versions: 2.7
>Reporter: Raimar Falke
> Labels: extra-field, json
>
> The Logback JSON Encoder has a feature which allows to specify JSON fields
> with fixed values. Link:
> https://github.com/logstash/logstash-logback-encoder#loggingevent_custom_global
> Example:
> {noformat}
>
>
> {"appname":"myWebservice","roles":["customerorder","auth"],"buildinfo":{"version":"Version
>
> 0.1.0-SNAPSHOT","lastcommit":"75473700d5befa953c45f630c6d9105413c16fe1"}}
>
> {noformat}
> This is a very convenient way to specify fixed attributes like application,
> service or environment.
> So far I don't see such a possibility in log4j.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1748) RollingFile appender prevents a stand alone application to terminate for as long as 60 sec
[
https://issues.apache.org/jira/browse/LOG4J2-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15820805#comment-15820805
]
Mikael Ståldal commented on LOG4J2-1748:
I have a solution for this and LOG4J-1780, please review branch
LOG4J2-1748and1780-remove-ExecutorService-from-LoggerContext
> RollingFile appender prevents a stand alone application to terminate for as
> long as 60 sec
> --
>
> Key: LOG4J2-1748
> URL: https://issues.apache.org/jira/browse/LOG4J2-1748
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.7
> Environment: Java8, Windows
>Reporter: Daniele Demichelis
>Assignee: Remko Popma
> Labels: RollingFile, bug
> Fix For: 2.8
>
>
> This code reproduces what I think is a bug of Log4j2.
> It's a simple loop that logs 2000 messages with two appenders:
> a console appender and a rolling file appender that rolls the file
> every 5Kb. This limit is intentionally low to reproduce what I think is a bug.
> Here's the code.
> {code:java}
> package bug;
>
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.Logger;
>
> public class Example {
>
> private static final Logger logger =
> LogManager.getLogger(Example.class);
>
> public static void main(String[] args) throws InterruptedException {
> for(int i = 0; i<2000; i++){
> logger.info("This is log message #{}.", i);
> Thread.sleep(0);
> }
> }
>
> }
> {code}
> Here's the `log4j2.xml` configuration file.
> {code:xml}
>
>
>
>
>
>
> fileName="target/log4j2/roll-by-size/app.log"
>
> filePattern="target/log4j2/roll-by-size/app.%i.log.gz"
> ignoreExceptions="false"
> append="false">
>
> %d{-MM-dd HH:mm:ss} %p %m%n
>
>
>
> size="5 KB"/>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> What is strange is that when the application is launched you will see this
> logs in the console.
> {code}
> 2016-12-22 22:12:36 INFO This is log message #1993.
> 2016-12-22 22:12:36 INFO This is log message #1994.
> 2016-12-22 22:12:36 INFO This is log message #1995.
> 2016-12-22 22:12:36 INFO This is log message #1996.
> 2016-12-22 22:12:36 INFO This is log message #1997.
> 2016-12-22 22:12:36 INFO This is log message #1998.
> 2016-12-22 22:12:36 INFO This is log message #1999.
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]...
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=StatusLogger]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=ContextSelector]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Loggers,name=bug,
> org.apache.logging.log4j2:type=60199c81,component=Lo
> ggers,name=]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Appenders,name=roll-by-size,
> org.apache.logging.log4j2:type=60199c81,c
> omponent=Appenders,name=stdout]
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Unregistering but no MBeans
> found matching
> 'org.apache.logging.log4j2:type=60199c81,component=AsyncAppenders,name=*'
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Unregistering but no MBeans
> found matching
[jira] [Resolved] (LOG4J2-1780) Eliminate the use of the ExecutorServices in the LoggerContext
[
https://issues.apache.org/jira/browse/LOG4J2-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikael Ståldal resolved LOG4J2-1780.
Resolution: Fixed
Fix Version/s: 2.8
See branch LOG4J2-1748and1780-remove-ExecutorService-from-LoggerContext
> Eliminate the use of the ExecutorServices in the LoggerContext
> --
>
> Key: LOG4J2-1780
> URL: https://issues.apache.org/jira/browse/LOG4J2-1780
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.7
>Reporter: Mikael Ståldal
>Assignee: Mikael Ståldal
> Fix For: 2.8
>
>
> LoggerContext does not shut down old executor services when creating new ones
> during reconfiguration in {{LoggerContext.setConfiguration}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1780) Eliminate the use of the ExecutorServices in the LoggerContext
[
https://issues.apache.org/jira/browse/LOG4J2-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikael Ståldal updated LOG4J2-1780:
---
Summary: Eliminate the use of the ExecutorServices in the LoggerContext
(was: LoggerContext does not shut down old executor services when creating new
ones during reconfiguration)
> Eliminate the use of the ExecutorServices in the LoggerContext
> --
>
> Key: LOG4J2-1780
> URL: https://issues.apache.org/jira/browse/LOG4J2-1780
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.7
>Reporter: Mikael Ståldal
>Assignee: Mikael Ståldal
>
> LoggerContext does not shut down old executor services when creating new ones
> during reconfiguration in {{LoggerContext.setConfiguration}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Assigned] (LOG4J2-1780) LoggerContext does not shut down old executor services when creating new ones during reconfiguration
[
https://issues.apache.org/jira/browse/LOG4J2-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikael Ståldal reassigned LOG4J2-1780:
--
Assignee: Mikael Ståldal
> LoggerContext does not shut down old executor services when creating new ones
> during reconfiguration
>
>
> Key: LOG4J2-1780
> URL: https://issues.apache.org/jira/browse/LOG4J2-1780
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.7
>Reporter: Mikael Ståldal
>Assignee: Mikael Ståldal
>
> LoggerContext does not shut down old executor services when creating new ones
> during reconfiguration in {{LoggerContext.setConfiguration}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1748) RollingFile appender prevents a stand alone application to terminate for as long as 60 sec
[
https://issues.apache.org/jira/browse/LOG4J2-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15820759#comment-15820759
]
Mikael Ståldal commented on LOG4J2-1748:
I don't think it is that complicated to keep track of tasks in flight, just use
{{ExecutorService.awaitTermination(timeout, timeUnit)}}, as already done in
{{ExecutorServices.shutdown(timeout, timeUnit)}}. The only missing part is to
apply some default timeout (such as one second) when the {{timeout}} parameter
is zero (which it will be unless explicitly set by user).
> RollingFile appender prevents a stand alone application to terminate for as
> long as 60 sec
> --
>
> Key: LOG4J2-1748
> URL: https://issues.apache.org/jira/browse/LOG4J2-1748
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.7
> Environment: Java8, Windows
>Reporter: Daniele Demichelis
>Assignee: Remko Popma
> Labels: RollingFile, bug
> Fix For: 2.8
>
>
> This code reproduces what I think is a bug of Log4j2.
> It's a simple loop that logs 2000 messages with two appenders:
> a console appender and a rolling file appender that rolls the file
> every 5Kb. This limit is intentionally low to reproduce what I think is a bug.
> Here's the code.
> {code:java}
> package bug;
>
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.Logger;
>
> public class Example {
>
> private static final Logger logger =
> LogManager.getLogger(Example.class);
>
> public static void main(String[] args) throws InterruptedException {
> for(int i = 0; i<2000; i++){
> logger.info("This is log message #{}.", i);
> Thread.sleep(0);
> }
> }
>
> }
> {code}
> Here's the `log4j2.xml` configuration file.
> {code:xml}
>
>
>
>
>
>
> fileName="target/log4j2/roll-by-size/app.log"
>
> filePattern="target/log4j2/roll-by-size/app.%i.log.gz"
> ignoreExceptions="false"
> append="false">
>
> %d{-MM-dd HH:mm:ss} %p %m%n
>
>
>
> size="5 KB"/>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> What is strange is that when the application is launched you will see this
> logs in the console.
> {code}
> 2016-12-22 22:12:36 INFO This is log message #1993.
> 2016-12-22 22:12:36 INFO This is log message #1994.
> 2016-12-22 22:12:36 INFO This is log message #1995.
> 2016-12-22 22:12:36 INFO This is log message #1996.
> 2016-12-22 22:12:36 INFO This is log message #1997.
> 2016-12-22 22:12:36 INFO This is log message #1998.
> 2016-12-22 22:12:36 INFO This is log message #1999.
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]...
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=StatusLogger]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=ContextSelector]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Loggers,name=bug,
> org.apache.logging.log4j2:type=60199c81,component=Lo
> ggers,name=]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Appenders,name=roll-by-size,
> org.apache.logging.log4j2:type=60199c81,c
> omponent=Appenders,name=stdout]
> 2016-12-22 22:13:36,382 pool-1-th
[jira] [Commented] (LOG4J2-1748) RollingFile appender prevents a stand alone application to terminate for as long as 60 sec
[
https://issues.apache.org/jira/browse/LOG4J2-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15820692#comment-15820692
]
Remko Popma commented on LOG4J2-1748:
-
I disagree. We've seen problems in the past when the Async rollover actions
(the compression) was done in a daemon thread. A normal (unforced) shutdown
could result in corrupted compressed log files.
We either have a separate non-daemon ExecutorService, or spawn ad hoc
non-daemon threads, or we do something complicated where the Shutdown hook
tracks all Async tasks that are in flight.
Spawning ad hoc non-daemon threads for the async rollover tasks is probably
simplest.
> RollingFile appender prevents a stand alone application to terminate for as
> long as 60 sec
> --
>
> Key: LOG4J2-1748
> URL: https://issues.apache.org/jira/browse/LOG4J2-1748
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.7
> Environment: Java8, Windows
>Reporter: Daniele Demichelis
>Assignee: Remko Popma
> Labels: RollingFile, bug
> Fix For: 2.8
>
>
> This code reproduces what I think is a bug of Log4j2.
> It's a simple loop that logs 2000 messages with two appenders:
> a console appender and a rolling file appender that rolls the file
> every 5Kb. This limit is intentionally low to reproduce what I think is a bug.
> Here's the code.
> {code:java}
> package bug;
>
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.Logger;
>
> public class Example {
>
> private static final Logger logger =
> LogManager.getLogger(Example.class);
>
> public static void main(String[] args) throws InterruptedException {
> for(int i = 0; i<2000; i++){
> logger.info("This is log message #{}.", i);
> Thread.sleep(0);
> }
> }
>
> }
> {code}
> Here's the `log4j2.xml` configuration file.
> {code:xml}
>
>
>
>
>
>
> fileName="target/log4j2/roll-by-size/app.log"
>
> filePattern="target/log4j2/roll-by-size/app.%i.log.gz"
> ignoreExceptions="false"
> append="false">
>
> %d{-MM-dd HH:mm:ss} %p %m%n
>
>
>
> size="5 KB"/>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> What is strange is that when the application is launched you will see this
> logs in the console.
> {code}
> 2016-12-22 22:12:36 INFO This is log message #1993.
> 2016-12-22 22:12:36 INFO This is log message #1994.
> 2016-12-22 22:12:36 INFO This is log message #1995.
> 2016-12-22 22:12:36 INFO This is log message #1996.
> 2016-12-22 22:12:36 INFO This is log message #1997.
> 2016-12-22 22:12:36 INFO This is log message #1998.
> 2016-12-22 22:12:36 INFO This is log message #1999.
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]...
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=StatusLogger]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=ContextSelector]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Loggers,name=bug,
> org.apache.logging.log4j2:type=60199c81,component=Lo
> ggers,name=]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Appenders,name=roll-by-size,
> org.apache.logging.log4j2:
[jira] [Commented] (LOG4J2-1748) RollingFile appender prevents a stand alone application to terminate for as long as 60 sec
[
https://issues.apache.org/jira/browse/LOG4J2-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15820630#comment-15820630
]
Mikael Ståldal commented on LOG4J2-1748:
The root cause of the problem is using non-daemon threads. If we stop doing
that, this problem will go away. ConfigurationScheduler uses daemon threads,
which is good.
Those executor services added to LoggerContext have caused two issues already,
this one and LOG4J2-1780 (a potential resource leak).
If we remove them and use ConfigurationScheduler, as Ralph suggests, those two
issues will go away and we will not have to fix them separately.
> RollingFile appender prevents a stand alone application to terminate for as
> long as 60 sec
> --
>
> Key: LOG4J2-1748
> URL: https://issues.apache.org/jira/browse/LOG4J2-1748
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.7
> Environment: Java8, Windows
>Reporter: Daniele Demichelis
>Assignee: Remko Popma
> Labels: RollingFile, bug
> Fix For: 2.8
>
>
> This code reproduces what I think is a bug of Log4j2.
> It's a simple loop that logs 2000 messages with two appenders:
> a console appender and a rolling file appender that rolls the file
> every 5Kb. This limit is intentionally low to reproduce what I think is a bug.
> Here's the code.
> {code:java}
> package bug;
>
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.Logger;
>
> public class Example {
>
> private static final Logger logger =
> LogManager.getLogger(Example.class);
>
> public static void main(String[] args) throws InterruptedException {
> for(int i = 0; i<2000; i++){
> logger.info("This is log message #{}.", i);
> Thread.sleep(0);
> }
> }
>
> }
> {code}
> Here's the `log4j2.xml` configuration file.
> {code:xml}
>
>
>
>
>
>
> fileName="target/log4j2/roll-by-size/app.log"
>
> filePattern="target/log4j2/roll-by-size/app.%i.log.gz"
> ignoreExceptions="false"
> append="false">
>
> %d{-MM-dd HH:mm:ss} %p %m%n
>
>
>
> size="5 KB"/>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> What is strange is that when the application is launched you will see this
> logs in the console.
> {code}
> 2016-12-22 22:12:36 INFO This is log message #1993.
> 2016-12-22 22:12:36 INFO This is log message #1994.
> 2016-12-22 22:12:36 INFO This is log message #1995.
> 2016-12-22 22:12:36 INFO This is log message #1996.
> 2016-12-22 22:12:36 INFO This is log message #1997.
> 2016-12-22 22:12:36 INFO This is log message #1998.
> 2016-12-22 22:12:36 INFO This is log message #1999.
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]...
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=StatusLogger]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=ContextSelector]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Loggers,name=bug,
> org.apache.logging.log4j2:type=60199c81,component=Lo
> ggers,name=]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Appenders,name=roll-by-size,
> org.apache.logging.log4j2:type=60199c81,c
> ompo
[jira] [Commented] (LOG4J2-1748) RollingFile appender prevents a stand alone application to terminate for as long as 60 sec
[
https://issues.apache.org/jira/browse/LOG4J2-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15820604#comment-15820604
]
Mikael Ståldal commented on LOG4J2-1748:
Yes, I agree.
But while waiting for us to fix it, it can be useful to have a workaround. And
it is a simpler workaround than {{Configurator.shutdown()}} as previously
suggested.
> RollingFile appender prevents a stand alone application to terminate for as
> long as 60 sec
> --
>
> Key: LOG4J2-1748
> URL: https://issues.apache.org/jira/browse/LOG4J2-1748
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.7
> Environment: Java8, Windows
>Reporter: Daniele Demichelis
>Assignee: Remko Popma
> Labels: RollingFile, bug
> Fix For: 2.8
>
>
> This code reproduces what I think is a bug of Log4j2.
> It's a simple loop that logs 2000 messages with two appenders:
> a console appender and a rolling file appender that rolls the file
> every 5Kb. This limit is intentionally low to reproduce what I think is a bug.
> Here's the code.
> {code:java}
> package bug;
>
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.Logger;
>
> public class Example {
>
> private static final Logger logger =
> LogManager.getLogger(Example.class);
>
> public static void main(String[] args) throws InterruptedException {
> for(int i = 0; i<2000; i++){
> logger.info("This is log message #{}.", i);
> Thread.sleep(0);
> }
> }
>
> }
> {code}
> Here's the `log4j2.xml` configuration file.
> {code:xml}
>
>
>
>
>
>
> fileName="target/log4j2/roll-by-size/app.log"
>
> filePattern="target/log4j2/roll-by-size/app.%i.log.gz"
> ignoreExceptions="false"
> append="false">
>
> %d{-MM-dd HH:mm:ss} %p %m%n
>
>
>
> size="5 KB"/>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> What is strange is that when the application is launched you will see this
> logs in the console.
> {code}
> 2016-12-22 22:12:36 INFO This is log message #1993.
> 2016-12-22 22:12:36 INFO This is log message #1994.
> 2016-12-22 22:12:36 INFO This is log message #1995.
> 2016-12-22 22:12:36 INFO This is log message #1996.
> 2016-12-22 22:12:36 INFO This is log message #1997.
> 2016-12-22 22:12:36 INFO This is log message #1998.
> 2016-12-22 22:12:36 INFO This is log message #1999.
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]...
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=StatusLogger]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=ContextSelector]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Loggers,name=bug,
> org.apache.logging.log4j2:type=60199c81,component=Lo
> ggers,name=]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Appenders,name=roll-by-size,
> org.apache.logging.log4j2:type=60199c81,c
> omponent=Appenders,name=stdout]
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Unregistering but no MBeans
> found matching
> 'org.apache.logging.log4j2:type=60199c81,component=AsyncAppenders,name=*'
> 2016-12-22 22:13:36,382 pool-1-thread-1 T
[jira] [Commented] (LOG4J2-1381) Documentation for LoggerNameLevelRewritePolicy is wrong
[
https://issues.apache.org/jira/browse/LOG4J2-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15820397#comment-15820397
]
Travis Spencer commented on LOG4J2-1381:
While this area of the documentation is being updated, it would be _very_
helpful if it were pointed out that the rewrite policy _is_ an appender and
needs to be added to a logger like any other appender. Perhaps that's obvious
but it took a while to figure out. WIth the {{AppenderRef}} in the {{Rewrite}}
element, one may think that the rewriting is enabled by that. It's not though.
My suggestion is to:
1. At the beginning of the {{RewritePolicy}} section, add text such as:
{quote}
A {{RewritePolicy}} should be defined after the appender that it will rewrite
(as indicated by the {{AppenderRef}} child element). To use the
{{RewritePolicy}}, a logger should reference the policy like any other appender
(i.e., using an {{AppenderRef}} with the {{name}} given to the
{{RewritePolicy}}). See the sample configuration below for examples of both the
order in which things must be defined as well as how the {{RewritePolicy}}
should be referenced by a logger.
{quote}
2. Add an XML comment next to the sample configs like this:
{code:xml}
{code}
> Documentation for LoggerNameLevelRewritePolicy is wrong
> ---
>
> Key: LOG4J2-1381
> URL: https://issues.apache.org/jira/browse/LOG4J2-1381
> Project: Log4j 2
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 2.5
>Reporter: Remko Popma
> Fix For: 2.8
>
>
> The docs for [LoggerNameLevelRewritePolicy
> |http://logging.apache.org/log4j/2.x/manual/appenders.html#RewriteAppender]
> are wrong:
> * property {{loggerName}} (both in the parameter table and in the example
> configuration): looking at the code, this should be {{logger}} instead.
> * property {{LevelPair}} (in the parameter table) should be {{KeyValuePair}}
> instead. The example configuration is correct here.
> (Or should the code be modified to match the docs instead?)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1748) RollingFile appender prevents a stand alone application to terminate for as long as 60 sec
[
https://issues.apache.org/jira/browse/LOG4J2-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15820023#comment-15820023
]
Ralph Goers commented on LOG4J2-1748:
-
I have no problem using the ThreadFactory to create the thread.
As I pointed out in LOG4J2-1780, the reason for the name is that the
ConfigurationScheduler is "owned" by the Configuration, so the name makes that
relationship clear. It's purpose was to handle scheduling for anything
associated with a configuration (which is almost everything). The only thing it
really shouldn't handle is reconfiguration.
> RollingFile appender prevents a stand alone application to terminate for as
> long as 60 sec
> --
>
> Key: LOG4J2-1748
> URL: https://issues.apache.org/jira/browse/LOG4J2-1748
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.7
> Environment: Java8, Windows
>Reporter: Daniele Demichelis
>Assignee: Remko Popma
> Labels: RollingFile, bug
> Fix For: 2.8
>
>
> This code reproduces what I think is a bug of Log4j2.
> It's a simple loop that logs 2000 messages with two appenders:
> a console appender and a rolling file appender that rolls the file
> every 5Kb. This limit is intentionally low to reproduce what I think is a bug.
> Here's the code.
> {code:java}
> package bug;
>
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.Logger;
>
> public class Example {
>
> private static final Logger logger =
> LogManager.getLogger(Example.class);
>
> public static void main(String[] args) throws InterruptedException {
> for(int i = 0; i<2000; i++){
> logger.info("This is log message #{}.", i);
> Thread.sleep(0);
> }
> }
>
> }
> {code}
> Here's the `log4j2.xml` configuration file.
> {code:xml}
>
>
>
>
>
>
> fileName="target/log4j2/roll-by-size/app.log"
>
> filePattern="target/log4j2/roll-by-size/app.%i.log.gz"
> ignoreExceptions="false"
> append="false">
>
> %d{-MM-dd HH:mm:ss} %p %m%n
>
>
>
> size="5 KB"/>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> What is strange is that when the application is launched you will see this
> logs in the console.
> {code}
> 2016-12-22 22:12:36 INFO This is log message #1993.
> 2016-12-22 22:12:36 INFO This is log message #1994.
> 2016-12-22 22:12:36 INFO This is log message #1995.
> 2016-12-22 22:12:36 INFO This is log message #1996.
> 2016-12-22 22:12:36 INFO This is log message #1997.
> 2016-12-22 22:12:36 INFO This is log message #1998.
> 2016-12-22 22:12:36 INFO This is log message #1999.
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]...
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=StatusLogger]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=ContextSelector]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Loggers,name=bug,
> org.apache.logging.log4j2:type=60199c81,component=Lo
> ggers,name=]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Appenders,name=roll-by-size,
> org.apache.logging.log4j2:type=60199c81,c
> omponent=Appenders,name=stdout]
[jira] [Comment Edited] (LOG4J2-1748) RollingFile appender prevents a stand alone application to terminate for as long as 60 sec
[
https://issues.apache.org/jira/browse/LOG4J2-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15819620#comment-15819620
]
Remko Popma edited comment on LOG4J2-1748 at 1/12/17 12:52 AM:
---
If rollover compression is to take place in daemon threads with the shutdown
hook being aware of rollover actions that are in flight and holding off
shutdown until such actions complete, then it would be nice if the shutdown
hook would be able to print a message like "Log4j2 shutdown hook is waiting for
compress action to complete".
The current solution to use non-daemon threads for compression is a lot simpler
though.
To clarify, my solution to the problem this JIRA was raised for was to limit
the timeout to 1 sec. We can also decide not to try reusing these threads at
all and compress in an ad hoc non-daemon thread.
was (Author: rem...@yahoo.com):
If rollover compression is to take place in daemon threads with the shutdown
hook being aware of rollover actions that are in flight and holding off
shutdown until such actions complete, then it would be nice if the shutdown
hook would be able to print a message like "Log4j2 shutdown hook is waiting for
compress action to complete".
The current solution to use non-daemon threads for compression is a lot simpler
though.
> RollingFile appender prevents a stand alone application to terminate for as
> long as 60 sec
> --
>
> Key: LOG4J2-1748
> URL: https://issues.apache.org/jira/browse/LOG4J2-1748
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.7
> Environment: Java8, Windows
>Reporter: Daniele Demichelis
>Assignee: Remko Popma
> Labels: RollingFile, bug
> Fix For: 2.8
>
>
> This code reproduces what I think is a bug of Log4j2.
> It's a simple loop that logs 2000 messages with two appenders:
> a console appender and a rolling file appender that rolls the file
> every 5Kb. This limit is intentionally low to reproduce what I think is a bug.
> Here's the code.
> {code:java}
> package bug;
>
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.Logger;
>
> public class Example {
>
> private static final Logger logger =
> LogManager.getLogger(Example.class);
>
> public static void main(String[] args) throws InterruptedException {
> for(int i = 0; i<2000; i++){
> logger.info("This is log message #{}.", i);
> Thread.sleep(0);
> }
> }
>
> }
> {code}
> Here's the `log4j2.xml` configuration file.
> {code:xml}
>
>
>
>
>
>
> fileName="target/log4j2/roll-by-size/app.log"
>
> filePattern="target/log4j2/roll-by-size/app.%i.log.gz"
> ignoreExceptions="false"
> append="false">
>
> %d{-MM-dd HH:mm:ss} %p %m%n
>
>
>
> size="5 KB"/>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> What is strange is that when the application is launched you will see this
> logs in the console.
> {code}
> 2016-12-22 22:12:36 INFO This is log message #1993.
> 2016-12-22 22:12:36 INFO This is log message #1994.
> 2016-12-22 22:12:36 INFO This is log message #1995.
> 2016-12-22 22:12:36 INFO This is log message #1996.
> 2016-12-22 22:12:36 INFO This is log message #1997.
> 2016-12-22 22:12:36 INFO This is log message #1998.
> 2016-12-22 22:12:36 INFO This is log message #1999.
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]...
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81]
> 2016-12-22 22:13:36,381 pool-1-thre
[jira] [Comment Edited] (LOG4J2-1748) RollingFile appender prevents a stand alone application to terminate for as long as 60 sec
[
https://issues.apache.org/jira/browse/LOG4J2-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15819620#comment-15819620
]
Remko Popma edited comment on LOG4J2-1748 at 1/12/17 12:49 AM:
---
If rollover compression is to take place in daemon threads with the shutdown
hook being aware of rollover actions that are in flight and holding off
shutdown until such actions complete, then it would be nice if the shutdown
hook would be able to print a message like "Log4j2 shutdown hook is waiting for
compress action to complete".
The current solution to use non-daemon threads for compression is a lot simpler
though.
was (Author: rem...@yahoo.com):
It would be nice if the shutdown hook would be able to print a message like
"Log4j2 shutdown hook is waiting for compress action to complete ".
> RollingFile appender prevents a stand alone application to terminate for as
> long as 60 sec
> --
>
> Key: LOG4J2-1748
> URL: https://issues.apache.org/jira/browse/LOG4J2-1748
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.7
> Environment: Java8, Windows
>Reporter: Daniele Demichelis
>Assignee: Remko Popma
> Labels: RollingFile, bug
> Fix For: 2.8
>
>
> This code reproduces what I think is a bug of Log4j2.
> It's a simple loop that logs 2000 messages with two appenders:
> a console appender and a rolling file appender that rolls the file
> every 5Kb. This limit is intentionally low to reproduce what I think is a bug.
> Here's the code.
> {code:java}
> package bug;
>
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.Logger;
>
> public class Example {
>
> private static final Logger logger =
> LogManager.getLogger(Example.class);
>
> public static void main(String[] args) throws InterruptedException {
> for(int i = 0; i<2000; i++){
> logger.info("This is log message #{}.", i);
> Thread.sleep(0);
> }
> }
>
> }
> {code}
> Here's the `log4j2.xml` configuration file.
> {code:xml}
>
>
>
>
>
>
> fileName="target/log4j2/roll-by-size/app.log"
>
> filePattern="target/log4j2/roll-by-size/app.%i.log.gz"
> ignoreExceptions="false"
> append="false">
>
> %d{-MM-dd HH:mm:ss} %p %m%n
>
>
>
> size="5 KB"/>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> What is strange is that when the application is launched you will see this
> logs in the console.
> {code}
> 2016-12-22 22:12:36 INFO This is log message #1993.
> 2016-12-22 22:12:36 INFO This is log message #1994.
> 2016-12-22 22:12:36 INFO This is log message #1995.
> 2016-12-22 22:12:36 INFO This is log message #1996.
> 2016-12-22 22:12:36 INFO This is log message #1997.
> 2016-12-22 22:12:36 INFO This is log message #1998.
> 2016-12-22 22:12:36 INFO This is log message #1999.
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]...
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=StatusLogger]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=ContextSelector]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Loggers,name=bug,
> org.apache.logging.log4j2:type=60199c81,component=Lo
> ggers,name=]
[jira] [Commented] (LOG4J2-1748) RollingFile appender prevents a stand alone application to terminate for as long as 60 sec
[
https://issues.apache.org/jira/browse/LOG4J2-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15819620#comment-15819620
]
Remko Popma commented on LOG4J2-1748:
-
It would be nice if the shutdown hook would be able to print a message like
"Log4j2 shutdown hook is waiting for compress action to complete ".
> RollingFile appender prevents a stand alone application to terminate for as
> long as 60 sec
> --
>
> Key: LOG4J2-1748
> URL: https://issues.apache.org/jira/browse/LOG4J2-1748
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.7
> Environment: Java8, Windows
>Reporter: Daniele Demichelis
>Assignee: Remko Popma
> Labels: RollingFile, bug
> Fix For: 2.8
>
>
> This code reproduces what I think is a bug of Log4j2.
> It's a simple loop that logs 2000 messages with two appenders:
> a console appender and a rolling file appender that rolls the file
> every 5Kb. This limit is intentionally low to reproduce what I think is a bug.
> Here's the code.
> {code:java}
> package bug;
>
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.Logger;
>
> public class Example {
>
> private static final Logger logger =
> LogManager.getLogger(Example.class);
>
> public static void main(String[] args) throws InterruptedException {
> for(int i = 0; i<2000; i++){
> logger.info("This is log message #{}.", i);
> Thread.sleep(0);
> }
> }
>
> }
> {code}
> Here's the `log4j2.xml` configuration file.
> {code:xml}
>
>
>
>
>
>
> fileName="target/log4j2/roll-by-size/app.log"
>
> filePattern="target/log4j2/roll-by-size/app.%i.log.gz"
> ignoreExceptions="false"
> append="false">
>
> %d{-MM-dd HH:mm:ss} %p %m%n
>
>
>
> size="5 KB"/>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> What is strange is that when the application is launched you will see this
> logs in the console.
> {code}
> 2016-12-22 22:12:36 INFO This is log message #1993.
> 2016-12-22 22:12:36 INFO This is log message #1994.
> 2016-12-22 22:12:36 INFO This is log message #1995.
> 2016-12-22 22:12:36 INFO This is log message #1996.
> 2016-12-22 22:12:36 INFO This is log message #1997.
> 2016-12-22 22:12:36 INFO This is log message #1998.
> 2016-12-22 22:12:36 INFO This is log message #1999.
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]...
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=StatusLogger]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=ContextSelector]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Loggers,name=bug,
> org.apache.logging.log4j2:type=60199c81,component=Lo
> ggers,name=]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Appenders,name=roll-by-size,
> org.apache.logging.log4j2:type=60199c81,c
> omponent=Appenders,name=stdout]
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Unregistering but no MBeans
> found matching
> 'org.apache.logging.log4j2:type=60199c81,component=AsyncAppenders,name=*'
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Unregistering but no MBe
[jira] [Commented] (LOG4J2-1748) RollingFile appender prevents a stand alone application to terminate for as long as 60 sec
[
https://issues.apache.org/jira/browse/LOG4J2-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15819604#comment-15819604
]
Remko Popma commented on LOG4J2-1748:
-
Probably best to have only one ExecutorService.
Naming-wise, ConfigurationScheduler suggests a narrow scope. We should consider
renaming it if the role of this service is to be extended for general purpose
async work.
I don't object to creating ad hoc Threads, but agree with Gary that we want to
name Log4j threads uniformly so we want to go through our ThreadFactory and
create Log4jThreads.
> RollingFile appender prevents a stand alone application to terminate for as
> long as 60 sec
> --
>
> Key: LOG4J2-1748
> URL: https://issues.apache.org/jira/browse/LOG4J2-1748
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.7
> Environment: Java8, Windows
>Reporter: Daniele Demichelis
>Assignee: Remko Popma
> Labels: RollingFile, bug
> Fix For: 2.8
>
>
> This code reproduces what I think is a bug of Log4j2.
> It's a simple loop that logs 2000 messages with two appenders:
> a console appender and a rolling file appender that rolls the file
> every 5Kb. This limit is intentionally low to reproduce what I think is a bug.
> Here's the code.
> {code:java}
> package bug;
>
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.Logger;
>
> public class Example {
>
> private static final Logger logger =
> LogManager.getLogger(Example.class);
>
> public static void main(String[] args) throws InterruptedException {
> for(int i = 0; i<2000; i++){
> logger.info("This is log message #{}.", i);
> Thread.sleep(0);
> }
> }
>
> }
> {code}
> Here's the `log4j2.xml` configuration file.
> {code:xml}
>
>
>
>
>
>
> fileName="target/log4j2/roll-by-size/app.log"
>
> filePattern="target/log4j2/roll-by-size/app.%i.log.gz"
> ignoreExceptions="false"
> append="false">
>
> %d{-MM-dd HH:mm:ss} %p %m%n
>
>
>
> size="5 KB"/>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> What is strange is that when the application is launched you will see this
> logs in the console.
> {code}
> 2016-12-22 22:12:36 INFO This is log message #1993.
> 2016-12-22 22:12:36 INFO This is log message #1994.
> 2016-12-22 22:12:36 INFO This is log message #1995.
> 2016-12-22 22:12:36 INFO This is log message #1996.
> 2016-12-22 22:12:36 INFO This is log message #1997.
> 2016-12-22 22:12:36 INFO This is log message #1998.
> 2016-12-22 22:12:36 INFO This is log message #1999.
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]...
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=StatusLogger]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=ContextSelector]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Loggers,name=bug,
> org.apache.logging.log4j2:type=60199c81,component=Lo
> ggers,name=]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Appenders,name=roll-by-size,
> org.apache.logging.log4j2:type=60199c81,c
> omponent=Appenders,name=stdout]
> 2016-12-22 22:1
[jira] [Commented] (LOG4J2-1780) LoggerContext does not shut down old executor services when creating new ones during reconfiguration
[
https://issues.apache.org/jira/browse/LOG4J2-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15819347#comment-15819347
]
Ralph Goers commented on LOG4J2-1780:
-
I don't see the problem. It is owned by the Configuration so naming it that
makes perfect sense.
> LoggerContext does not shut down old executor services when creating new ones
> during reconfiguration
>
>
> Key: LOG4J2-1780
> URL: https://issues.apache.org/jira/browse/LOG4J2-1780
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.7
>Reporter: Mikael Ståldal
>
> LoggerContext does not shut down old executor services when creating new ones
> during reconfiguration in {{LoggerContext.setConfiguration}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1748) RollingFile appender prevents a stand alone application to terminate for as long as 60 sec
[
https://issues.apache.org/jira/browse/LOG4J2-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15819341#comment-15819341
]
Ralph Goers commented on LOG4J2-1748:
-
We have an ExecutorService. It is called ConfigurationScheduler.
RollingFileManager and KafkaManager should be using that.
It is OK to create a Thread where it makes more sense than having a service.
> RollingFile appender prevents a stand alone application to terminate for as
> long as 60 sec
> --
>
> Key: LOG4J2-1748
> URL: https://issues.apache.org/jira/browse/LOG4J2-1748
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.7
> Environment: Java8, Windows
>Reporter: Daniele Demichelis
>Assignee: Remko Popma
> Labels: RollingFile, bug
> Fix For: 2.8
>
>
> This code reproduces what I think is a bug of Log4j2.
> It's a simple loop that logs 2000 messages with two appenders:
> a console appender and a rolling file appender that rolls the file
> every 5Kb. This limit is intentionally low to reproduce what I think is a bug.
> Here's the code.
> {code:java}
> package bug;
>
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.Logger;
>
> public class Example {
>
> private static final Logger logger =
> LogManager.getLogger(Example.class);
>
> public static void main(String[] args) throws InterruptedException {
> for(int i = 0; i<2000; i++){
> logger.info("This is log message #{}.", i);
> Thread.sleep(0);
> }
> }
>
> }
> {code}
> Here's the `log4j2.xml` configuration file.
> {code:xml}
>
>
>
>
>
>
> fileName="target/log4j2/roll-by-size/app.log"
>
> filePattern="target/log4j2/roll-by-size/app.%i.log.gz"
> ignoreExceptions="false"
> append="false">
>
> %d{-MM-dd HH:mm:ss} %p %m%n
>
>
>
> size="5 KB"/>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> What is strange is that when the application is launched you will see this
> logs in the console.
> {code}
> 2016-12-22 22:12:36 INFO This is log message #1993.
> 2016-12-22 22:12:36 INFO This is log message #1994.
> 2016-12-22 22:12:36 INFO This is log message #1995.
> 2016-12-22 22:12:36 INFO This is log message #1996.
> 2016-12-22 22:12:36 INFO This is log message #1997.
> 2016-12-22 22:12:36 INFO This is log message #1998.
> 2016-12-22 22:12:36 INFO This is log message #1999.
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]...
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=StatusLogger]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=ContextSelector]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Loggers,name=bug,
> org.apache.logging.log4j2:type=60199c81,component=Lo
> ggers,name=]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Appenders,name=roll-by-size,
> org.apache.logging.log4j2:type=60199c81,c
> omponent=Appenders,name=stdout]
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Unregistering but no MBeans
> found matching
> 'org.apache.logging.log4j2:type=60199c81,component=AsyncAppenders,name=*'
> 2016-12-22 22:13:36,382 p
[jira] [Commented] (LOG4J2-1780) LoggerContext does not shut down old executor services when creating new ones during reconfiguration
[
https://issues.apache.org/jira/browse/LOG4J2-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15819340#comment-15819340
]
Gary Gregory commented on LOG4J2-1780:
--
Maybe the {{ConfigurationScheduler}} is misnamed because in my noggin, it does
not sound right that the "RollingFileManager should use the
ConfigurationScheduler to run the compression task."; that sounds like reuse
for convenience, not by design; a round hole/square peg deal.
> LoggerContext does not shut down old executor services when creating new ones
> during reconfiguration
>
>
> Key: LOG4J2-1780
> URL: https://issues.apache.org/jira/browse/LOG4J2-1780
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.7
>Reporter: Mikael Ståldal
>
> LoggerContext does not shut down old executor services when creating new ones
> during reconfiguration in {{LoggerContext.setConfiguration}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1748) RollingFile appender prevents a stand alone application to terminate for as long as 60 sec
[
https://issues.apache.org/jira/browse/LOG4J2-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15819329#comment-15819329
]
Gary Gregory commented on LOG4J2-1748:
--
Using executor services lets us centralize thread management instead of having
"new Thread()..." and "extends Thread" sprinkled here and there.
Using an executor service also let's us use easily a thread factory such that
we can uniformly create and use Log4j ThreadFactory and Log4jThread instances.
This let's us name threads nicely and uniformly instead on relying on each call
site to optionally name a thread.
The current users are: the rolling file manager, the Kafka manager, and the
file watcher.
I do not recall if I considered using or extending the configuration scheduler
for any of these use cases.
> RollingFile appender prevents a stand alone application to terminate for as
> long as 60 sec
> --
>
> Key: LOG4J2-1748
> URL: https://issues.apache.org/jira/browse/LOG4J2-1748
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.7
> Environment: Java8, Windows
>Reporter: Daniele Demichelis
>Assignee: Remko Popma
> Labels: RollingFile, bug
> Fix For: 2.8
>
>
> This code reproduces what I think is a bug of Log4j2.
> It's a simple loop that logs 2000 messages with two appenders:
> a console appender and a rolling file appender that rolls the file
> every 5Kb. This limit is intentionally low to reproduce what I think is a bug.
> Here's the code.
> {code:java}
> package bug;
>
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.Logger;
>
> public class Example {
>
> private static final Logger logger =
> LogManager.getLogger(Example.class);
>
> public static void main(String[] args) throws InterruptedException {
> for(int i = 0; i<2000; i++){
> logger.info("This is log message #{}.", i);
> Thread.sleep(0);
> }
> }
>
> }
> {code}
> Here's the `log4j2.xml` configuration file.
> {code:xml}
>
>
>
>
>
>
> fileName="target/log4j2/roll-by-size/app.log"
>
> filePattern="target/log4j2/roll-by-size/app.%i.log.gz"
> ignoreExceptions="false"
> append="false">
>
> %d{-MM-dd HH:mm:ss} %p %m%n
>
>
>
> size="5 KB"/>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> What is strange is that when the application is launched you will see this
> logs in the console.
> {code}
> 2016-12-22 22:12:36 INFO This is log message #1993.
> 2016-12-22 22:12:36 INFO This is log message #1994.
> 2016-12-22 22:12:36 INFO This is log message #1995.
> 2016-12-22 22:12:36 INFO This is log message #1996.
> 2016-12-22 22:12:36 INFO This is log message #1997.
> 2016-12-22 22:12:36 INFO This is log message #1998.
> 2016-12-22 22:12:36 INFO This is log message #1999.
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]...
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=StatusLogger]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=ContextSelector]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Loggers,name=bug,
> org.apache.logging.log4j2:type=60199c81,component=Lo
> ggers,name=]
> 2016-12-22 22:13:36,381
[jira] [Commented] (LOG4J2-1780) LoggerContext does not shut down old executor services when creating new ones during reconfiguration
[
https://issues.apache.org/jira/browse/LOG4J2-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15819309#comment-15819309
]
Ralph Goers commented on LOG4J2-1780:
-
The LoggerContext should not have any ExecutorServices declared in it. This
ticket should be modified to be "Eliminate the use of the ExecutorServices in
the LoggerContext". The ConfigurationFileWatcher should revert back to directly
spawning a thread when a reconfiguration is to occur. RollingFileManager should
use the ConfigurationScheduler to run the compression task.
> LoggerContext does not shut down old executor services when creating new ones
> during reconfiguration
>
>
> Key: LOG4J2-1780
> URL: https://issues.apache.org/jira/browse/LOG4J2-1780
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.7
>Reporter: Mikael Ståldal
>
> LoggerContext does not shut down old executor services when creating new ones
> during reconfiguration in {{LoggerContext.setConfiguration}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1748) RollingFile appender prevents a stand alone application to terminate for as long as 60 sec
[
https://issues.apache.org/jira/browse/LOG4J2-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15819275#comment-15819275
]
Ralph Goers commented on LOG4J2-1748:
-
Again, lets just get rid of these ExecutorService instances.
> RollingFile appender prevents a stand alone application to terminate for as
> long as 60 sec
> --
>
> Key: LOG4J2-1748
> URL: https://issues.apache.org/jira/browse/LOG4J2-1748
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.7
> Environment: Java8, Windows
>Reporter: Daniele Demichelis
>Assignee: Remko Popma
> Labels: RollingFile, bug
> Fix For: 2.8
>
>
> This code reproduces what I think is a bug of Log4j2.
> It's a simple loop that logs 2000 messages with two appenders:
> a console appender and a rolling file appender that rolls the file
> every 5Kb. This limit is intentionally low to reproduce what I think is a bug.
> Here's the code.
> {code:java}
> package bug;
>
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.Logger;
>
> public class Example {
>
> private static final Logger logger =
> LogManager.getLogger(Example.class);
>
> public static void main(String[] args) throws InterruptedException {
> for(int i = 0; i<2000; i++){
> logger.info("This is log message #{}.", i);
> Thread.sleep(0);
> }
> }
>
> }
> {code}
> Here's the `log4j2.xml` configuration file.
> {code:xml}
>
>
>
>
>
>
> fileName="target/log4j2/roll-by-size/app.log"
>
> filePattern="target/log4j2/roll-by-size/app.%i.log.gz"
> ignoreExceptions="false"
> append="false">
>
> %d{-MM-dd HH:mm:ss} %p %m%n
>
>
>
> size="5 KB"/>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> What is strange is that when the application is launched you will see this
> logs in the console.
> {code}
> 2016-12-22 22:12:36 INFO This is log message #1993.
> 2016-12-22 22:12:36 INFO This is log message #1994.
> 2016-12-22 22:12:36 INFO This is log message #1995.
> 2016-12-22 22:12:36 INFO This is log message #1996.
> 2016-12-22 22:12:36 INFO This is log message #1997.
> 2016-12-22 22:12:36 INFO This is log message #1998.
> 2016-12-22 22:12:36 INFO This is log message #1999.
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]...
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=StatusLogger]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=ContextSelector]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Loggers,name=bug,
> org.apache.logging.log4j2:type=60199c81,component=Lo
> ggers,name=]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Appenders,name=roll-by-size,
> org.apache.logging.log4j2:type=60199c81,c
> omponent=Appenders,name=stdout]
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Unregistering but no MBeans
> found matching
> 'org.apache.logging.log4j2:type=60199c81,component=AsyncAppenders,name=*'
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Unregistering but no MBeans
> found matching
> 'org.apache.logging.log4j2:type=60199c81,component=AsyncLog
[jira] [Commented] (LOG4J2-1748) RollingFile appender prevents a stand alone application to terminate for as long as 60 sec
[
https://issues.apache.org/jira/browse/LOG4J2-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15819273#comment-15819273
]
Ralph Goers commented on LOG4J2-1748:
-
I don't think that is a great recommendation.
> RollingFile appender prevents a stand alone application to terminate for as
> long as 60 sec
> --
>
> Key: LOG4J2-1748
> URL: https://issues.apache.org/jira/browse/LOG4J2-1748
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.7
> Environment: Java8, Windows
>Reporter: Daniele Demichelis
>Assignee: Remko Popma
> Labels: RollingFile, bug
> Fix For: 2.8
>
>
> This code reproduces what I think is a bug of Log4j2.
> It's a simple loop that logs 2000 messages with two appenders:
> a console appender and a rolling file appender that rolls the file
> every 5Kb. This limit is intentionally low to reproduce what I think is a bug.
> Here's the code.
> {code:java}
> package bug;
>
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.Logger;
>
> public class Example {
>
> private static final Logger logger =
> LogManager.getLogger(Example.class);
>
> public static void main(String[] args) throws InterruptedException {
> for(int i = 0; i<2000; i++){
> logger.info("This is log message #{}.", i);
> Thread.sleep(0);
> }
> }
>
> }
> {code}
> Here's the `log4j2.xml` configuration file.
> {code:xml}
>
>
>
>
>
>
> fileName="target/log4j2/roll-by-size/app.log"
>
> filePattern="target/log4j2/roll-by-size/app.%i.log.gz"
> ignoreExceptions="false"
> append="false">
>
> %d{-MM-dd HH:mm:ss} %p %m%n
>
>
>
> size="5 KB"/>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> What is strange is that when the application is launched you will see this
> logs in the console.
> {code}
> 2016-12-22 22:12:36 INFO This is log message #1993.
> 2016-12-22 22:12:36 INFO This is log message #1994.
> 2016-12-22 22:12:36 INFO This is log message #1995.
> 2016-12-22 22:12:36 INFO This is log message #1996.
> 2016-12-22 22:12:36 INFO This is log message #1997.
> 2016-12-22 22:12:36 INFO This is log message #1998.
> 2016-12-22 22:12:36 INFO This is log message #1999.
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]...
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=StatusLogger]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=ContextSelector]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Loggers,name=bug,
> org.apache.logging.log4j2:type=60199c81,component=Lo
> ggers,name=]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Appenders,name=roll-by-size,
> org.apache.logging.log4j2:type=60199c81,c
> omponent=Appenders,name=stdout]
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Unregistering but no MBeans
> found matching
> 'org.apache.logging.log4j2:type=60199c81,component=AsyncAppenders,name=*'
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Unregistering but no MBeans
> found matching
> 'org.apache.logging.log4j2:type=60199c81,component=AsyncLogg
[jira] [Comment Edited] (LOG4J2-1748) RollingFile appender prevents a stand alone application to terminate for as long as 60 sec
[
https://issues.apache.org/jira/browse/LOG4J2-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15819273#comment-15819273
]
Ralph Goers edited comment on LOG4J2-1748 at 1/11/17 9:44 PM:
--
I don't think that is a great recommendation. We should shut down cleanly.
was (Author: ralph.go...@dslextreme.com):
I don't think that is a great recommendation.
> RollingFile appender prevents a stand alone application to terminate for as
> long as 60 sec
> --
>
> Key: LOG4J2-1748
> URL: https://issues.apache.org/jira/browse/LOG4J2-1748
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.7
> Environment: Java8, Windows
>Reporter: Daniele Demichelis
>Assignee: Remko Popma
> Labels: RollingFile, bug
> Fix For: 2.8
>
>
> This code reproduces what I think is a bug of Log4j2.
> It's a simple loop that logs 2000 messages with two appenders:
> a console appender and a rolling file appender that rolls the file
> every 5Kb. This limit is intentionally low to reproduce what I think is a bug.
> Here's the code.
> {code:java}
> package bug;
>
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.Logger;
>
> public class Example {
>
> private static final Logger logger =
> LogManager.getLogger(Example.class);
>
> public static void main(String[] args) throws InterruptedException {
> for(int i = 0; i<2000; i++){
> logger.info("This is log message #{}.", i);
> Thread.sleep(0);
> }
> }
>
> }
> {code}
> Here's the `log4j2.xml` configuration file.
> {code:xml}
>
>
>
>
>
>
> fileName="target/log4j2/roll-by-size/app.log"
>
> filePattern="target/log4j2/roll-by-size/app.%i.log.gz"
> ignoreExceptions="false"
> append="false">
>
> %d{-MM-dd HH:mm:ss} %p %m%n
>
>
>
> size="5 KB"/>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> What is strange is that when the application is launched you will see this
> logs in the console.
> {code}
> 2016-12-22 22:12:36 INFO This is log message #1993.
> 2016-12-22 22:12:36 INFO This is log message #1994.
> 2016-12-22 22:12:36 INFO This is log message #1995.
> 2016-12-22 22:12:36 INFO This is log message #1996.
> 2016-12-22 22:12:36 INFO This is log message #1997.
> 2016-12-22 22:12:36 INFO This is log message #1998.
> 2016-12-22 22:12:36 INFO This is log message #1999.
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]...
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=StatusLogger]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=ContextSelector]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Loggers,name=bug,
> org.apache.logging.log4j2:type=60199c81,component=Lo
> ggers,name=]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Appenders,name=roll-by-size,
> org.apache.logging.log4j2:type=60199c81,c
> omponent=Appenders,name=stdout]
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Unregistering but no MBeans
> found matching
> 'org.apache.logging.log4j2:type=60199c81,component=AsyncAppenders,name=*'
> 2016
[jira] [Commented] (LOG4J2-1748) RollingFile appender prevents a stand alone application to terminate for as long as 60 sec
[
https://issues.apache.org/jira/browse/LOG4J2-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15819271#comment-15819271
]
Ralph Goers commented on LOG4J2-1748:
-
I don't know why those two ThreadPoolExecutors were added. The
ConfigurationScheduler was added to be the single place that Log4j schedules
work to be executed. I plan on modifying the RollingFileManager to use the
ConfigurationScheduler to perform the rollover. The only other thing using
those ExecutorServices is the configuration file Watcher. What is interesting
is that the WatchManager uses the ConfigurationScheduler to periodically check
for events - so naturally the check happens on a Thread owned by the
ConfigurationScheduler. When a file modification is found
ConfigurationFileWatcher schedules another Thread to run to perform the
reconfiguration. This used to be done by creating a Thread and running it. I
guess Gary decided it was better to have an ExecutorService for this.
Personally, I think this is wrong. The reconfiguration shouldn't happen in a
Thread owned by the ConfigurationScheduler because that will be stopped and
restarted during reconfiguration. But I see no point in creating an
ExecutorService to perform just this one task as it is overkill.
I don't think this problem would exist if these ExecutorServices weren't
present.
> RollingFile appender prevents a stand alone application to terminate for as
> long as 60 sec
> --
>
> Key: LOG4J2-1748
> URL: https://issues.apache.org/jira/browse/LOG4J2-1748
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.7
> Environment: Java8, Windows
>Reporter: Daniele Demichelis
>Assignee: Remko Popma
> Labels: RollingFile, bug
> Fix For: 2.8
>
>
> This code reproduces what I think is a bug of Log4j2.
> It's a simple loop that logs 2000 messages with two appenders:
> a console appender and a rolling file appender that rolls the file
> every 5Kb. This limit is intentionally low to reproduce what I think is a bug.
> Here's the code.
> {code:java}
> package bug;
>
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.Logger;
>
> public class Example {
>
> private static final Logger logger =
> LogManager.getLogger(Example.class);
>
> public static void main(String[] args) throws InterruptedException {
> for(int i = 0; i<2000; i++){
> logger.info("This is log message #{}.", i);
> Thread.sleep(0);
> }
> }
>
> }
> {code}
> Here's the `log4j2.xml` configuration file.
> {code:xml}
>
>
>
>
>
>
> fileName="target/log4j2/roll-by-size/app.log"
>
> filePattern="target/log4j2/roll-by-size/app.%i.log.gz"
> ignoreExceptions="false"
> append="false">
>
> %d{-MM-dd HH:mm:ss} %p %m%n
>
>
>
> size="5 KB"/>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> What is strange is that when the application is launched you will see this
> logs in the console.
> {code}
> 2016-12-22 22:12:36 INFO This is log message #1993.
> 2016-12-22 22:12:36 INFO This is log message #1994.
> 2016-12-22 22:12:36 INFO This is log message #1995.
> 2016-12-22 22:12:36 INFO This is log message #1996.
> 2016-12-22 22:12:36 INFO This is log message #1997.
> 2016-12-22 22:12:36 INFO This is log message #1998.
> 2016-12-22 22:12:36 INFO This is log message #1999.
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]...
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81]
> 2016-12-
[jira] [Commented] (LOG4J2-1776) log4j-boot pom modules for dependency management
[
https://issues.apache.org/jira/browse/LOG4J2-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15819217#comment-15819217
]
Mikael Ståldal commented on LOG4J2-1776:
Why do we have logback here?
> log4j-boot pom modules for dependency management
>
>
> Key: LOG4J2-1776
> URL: https://issues.apache.org/jira/browse/LOG4J2-1776
> Project: Log4j 2
> Issue Type: New Feature
> Components: Boot
>Reporter: Matt Sicker
>
> This is the main feature for the Log4j Boot epic (LOG4J2-1775).
> {code}
> groupId: org.apache.logging.log4j.boot
> artifactId: log4j-boot-*
> {code}
> * core: just log4j-core basically
> * async (for AsyncLogger; brings in LMAX disruptor)
> * log4j-spi: log4j-slf4j-impl, log4j-jul, log4j-jcl, log4j-1.2-api
> * slf4j-spi: slf4j-impl, jcl-over-slf4j, jul-to-slf4j (same dependency set as
> spring-boot-starter-log4j2)
> * logback (for log4j-to-slf4j, slf4j-spi, logback; this helps aid migration
> to log4j-api and promotes it as a general use logging API)
> * advertiser-jmdns
> * appender-async-conversant
> * appender-async-jctools
> * appender-cassandra
> * appender-couchdb
> * appender-jms
> * appender-jpa
> * appender-kafka
> * appender-mongodb
> * appender-smtp
> * appender-zeromq
> * config-json
> * config-yaml
> * layout-csv
> * layout-jansi (for windows users and coloured log messages)
> * layout-json (unless this has been ported to not require jackson anymore?)
> * layout-xml
> * layout-yaml
> * script-groovy
> I may have missed a few, but the base set of starters should at least
> correspond to all optional dependencies in log4j-core or the addon modules.
> For the jms, jpa, and smtp (log4j-core) appenders, we could either make add
> in a default provider (e.g., ActiveMQ, Hibernate, and Sun Mail respectively)
> or split those into provider-specific starters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1780) LoggerContext does not shut down old executor services when creating new ones during reconfiguration
[
https://issues.apache.org/jira/browse/LOG4J2-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15819168#comment-15819168
]
Mikael Ståldal commented on LOG4J2-1780:
Otherwise, an easy solution would be to create the executor services in start()
instead of in setConfiguration(). As far as I can see, creation of them is not
dependent on the configuration, so they need not to be recreated when
configuration is changed.
> LoggerContext does not shut down old executor services when creating new ones
> during reconfiguration
>
>
> Key: LOG4J2-1780
> URL: https://issues.apache.org/jira/browse/LOG4J2-1780
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.7
>Reporter: Mikael Ståldal
>
> LoggerContext does not shut down old executor services when creating new ones
> during reconfiguration in {{LoggerContext.setConfiguration}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1748) RollingFile appender prevents a stand alone application to terminate for as long as 60 sec
[
https://issues.apache.org/jira/browse/LOG4J2-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15819147#comment-15819147
]
Mikael Ståldal commented on LOG4J2-1748:
But I think the proper way to handle this is to have our shutdown hook wait for
the task to finish (with a timeout), as we currently do. Then we can safely do
it with a daemon thread.
A library like Log4j should not start non-daemon threads since that will
disrupt shutdown of the application, as shown by this bug. Remko's solution is
just a work-around for a more fundamental underlying problem.
> RollingFile appender prevents a stand alone application to terminate for as
> long as 60 sec
> --
>
> Key: LOG4J2-1748
> URL: https://issues.apache.org/jira/browse/LOG4J2-1748
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.7
> Environment: Java8, Windows
>Reporter: Daniele Demichelis
>Assignee: Remko Popma
> Labels: RollingFile, bug
> Fix For: 2.8
>
>
> This code reproduces what I think is a bug of Log4j2.
> It's a simple loop that logs 2000 messages with two appenders:
> a console appender and a rolling file appender that rolls the file
> every 5Kb. This limit is intentionally low to reproduce what I think is a bug.
> Here's the code.
> {code:java}
> package bug;
>
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.Logger;
>
> public class Example {
>
> private static final Logger logger =
> LogManager.getLogger(Example.class);
>
> public static void main(String[] args) throws InterruptedException {
> for(int i = 0; i<2000; i++){
> logger.info("This is log message #{}.", i);
> Thread.sleep(0);
> }
> }
>
> }
> {code}
> Here's the `log4j2.xml` configuration file.
> {code:xml}
>
>
>
>
>
>
> fileName="target/log4j2/roll-by-size/app.log"
>
> filePattern="target/log4j2/roll-by-size/app.%i.log.gz"
> ignoreExceptions="false"
> append="false">
>
> %d{-MM-dd HH:mm:ss} %p %m%n
>
>
>
> size="5 KB"/>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> What is strange is that when the application is launched you will see this
> logs in the console.
> {code}
> 2016-12-22 22:12:36 INFO This is log message #1993.
> 2016-12-22 22:12:36 INFO This is log message #1994.
> 2016-12-22 22:12:36 INFO This is log message #1995.
> 2016-12-22 22:12:36 INFO This is log message #1996.
> 2016-12-22 22:12:36 INFO This is log message #1997.
> 2016-12-22 22:12:36 INFO This is log message #1998.
> 2016-12-22 22:12:36 INFO This is log message #1999.
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]...
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=StatusLogger]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=ContextSelector]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Loggers,name=bug,
> org.apache.logging.log4j2:type=60199c81,component=Lo
> ggers,name=]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Appenders,name=roll-by-size,
> org.apache.logging.log4j2:type=60199c81,c
> omponent=Appenders,name=stdout]
> 2016-12-
[jira] [Commented] (LOG4J2-1748) RollingFile appender prevents a stand alone application to terminate for as long as 60 sec
[
https://issues.apache.org/jira/browse/LOG4J2-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15816578#comment-15816578
]
Gary Gregory commented on LOG4J2-1748:
--
Yep, IIRC, that is why I did it that way.
> RollingFile appender prevents a stand alone application to terminate for as
> long as 60 sec
> --
>
> Key: LOG4J2-1748
> URL: https://issues.apache.org/jira/browse/LOG4J2-1748
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.7
> Environment: Java8, Windows
>Reporter: Daniele Demichelis
>Assignee: Remko Popma
> Labels: RollingFile, bug
> Fix For: 2.8
>
>
> This code reproduces what I think is a bug of Log4j2.
> It's a simple loop that logs 2000 messages with two appenders:
> a console appender and a rolling file appender that rolls the file
> every 5Kb. This limit is intentionally low to reproduce what I think is a bug.
> Here's the code.
> {code:java}
> package bug;
>
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.Logger;
>
> public class Example {
>
> private static final Logger logger =
> LogManager.getLogger(Example.class);
>
> public static void main(String[] args) throws InterruptedException {
> for(int i = 0; i<2000; i++){
> logger.info("This is log message #{}.", i);
> Thread.sleep(0);
> }
> }
>
> }
> {code}
> Here's the `log4j2.xml` configuration file.
> {code:xml}
>
>
>
>
>
>
> fileName="target/log4j2/roll-by-size/app.log"
>
> filePattern="target/log4j2/roll-by-size/app.%i.log.gz"
> ignoreExceptions="false"
> append="false">
>
> %d{-MM-dd HH:mm:ss} %p %m%n
>
>
>
> size="5 KB"/>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> What is strange is that when the application is launched you will see this
> logs in the console.
> {code}
> 2016-12-22 22:12:36 INFO This is log message #1993.
> 2016-12-22 22:12:36 INFO This is log message #1994.
> 2016-12-22 22:12:36 INFO This is log message #1995.
> 2016-12-22 22:12:36 INFO This is log message #1996.
> 2016-12-22 22:12:36 INFO This is log message #1997.
> 2016-12-22 22:12:36 INFO This is log message #1998.
> 2016-12-22 22:12:36 INFO This is log message #1999.
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]...
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=StatusLogger]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=ContextSelector]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Loggers,name=bug,
> org.apache.logging.log4j2:type=60199c81,component=Lo
> ggers,name=]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Appenders,name=roll-by-size,
> org.apache.logging.log4j2:type=60199c81,c
> omponent=Appenders,name=stdout]
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Unregistering but no MBeans
> found matching
> 'org.apache.logging.log4j2:type=60199c81,component=AsyncAppenders,name=*'
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Unregistering but no MBeans
> found matching
> 'org.apache.logging.log4j2:type=60199c81,component=AsyncLoggerRin
[jira] [Commented] (LOG4J2-1748) RollingFile appender prevents a stand alone application to terminate for as long as 60 sec
[
https://issues.apache.org/jira/browse/LOG4J2-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15816488#comment-15816488
]
Remko Popma commented on LOG4J2-1748:
-
I believe (I could be wrong) that the non-daemon thread was introduced to
prevent the compress action from being interrupted if the application ended
immediately after a rollover.
True, if forcefully killed this may still happen, but it makes sense to do
compression in a non-daemon thread.
> RollingFile appender prevents a stand alone application to terminate for as
> long as 60 sec
> --
>
> Key: LOG4J2-1748
> URL: https://issues.apache.org/jira/browse/LOG4J2-1748
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.7
> Environment: Java8, Windows
>Reporter: Daniele Demichelis
>Assignee: Remko Popma
> Labels: RollingFile, bug
> Fix For: 2.8
>
>
> This code reproduces what I think is a bug of Log4j2.
> It's a simple loop that logs 2000 messages with two appenders:
> a console appender and a rolling file appender that rolls the file
> every 5Kb. This limit is intentionally low to reproduce what I think is a bug.
> Here's the code.
> {code:java}
> package bug;
>
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.Logger;
>
> public class Example {
>
> private static final Logger logger =
> LogManager.getLogger(Example.class);
>
> public static void main(String[] args) throws InterruptedException {
> for(int i = 0; i<2000; i++){
> logger.info("This is log message #{}.", i);
> Thread.sleep(0);
> }
> }
>
> }
> {code}
> Here's the `log4j2.xml` configuration file.
> {code:xml}
>
>
>
>
>
>
> fileName="target/log4j2/roll-by-size/app.log"
>
> filePattern="target/log4j2/roll-by-size/app.%i.log.gz"
> ignoreExceptions="false"
> append="false">
>
> %d{-MM-dd HH:mm:ss} %p %m%n
>
>
>
> size="5 KB"/>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> What is strange is that when the application is launched you will see this
> logs in the console.
> {code}
> 2016-12-22 22:12:36 INFO This is log message #1993.
> 2016-12-22 22:12:36 INFO This is log message #1994.
> 2016-12-22 22:12:36 INFO This is log message #1995.
> 2016-12-22 22:12:36 INFO This is log message #1996.
> 2016-12-22 22:12:36 INFO This is log message #1997.
> 2016-12-22 22:12:36 INFO This is log message #1998.
> 2016-12-22 22:12:36 INFO This is log message #1999.
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]...
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=StatusLogger]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=ContextSelector]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Loggers,name=bug,
> org.apache.logging.log4j2:type=60199c81,component=Lo
> ggers,name=]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Appenders,name=roll-by-size,
> org.apache.logging.log4j2:type=60199c81,c
> omponent=Appenders,name=stdout]
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Unregistering but no MBeans
> found matching
> 'org.apache.logging.
[jira] [Commented] (LOG4J2-1640) RollingFileAppender with CronTriggeringPolicy broken?
[
https://issues.apache.org/jira/browse/LOG4J2-1640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15816297#comment-15816297
]
Ralph Goers commented on LOG4J2-1640:
-
Yes, you would need to re-clone and re-build. If you want the rollover at
midnight then you can set your clock before starting the test application or
just let it roll at midnight. Otherwise you can change your pattern to have it
roll every hour or 2 instead of only at midnight.
> RollingFileAppender with CronTriggeringPolicy broken?
> -
>
> Key: LOG4J2-1640
> URL: https://issues.apache.org/jira/browse/LOG4J2-1640
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.7
> Environment: Mac OS X 10.11.6 running Eclipse Neon 4.6.0 with JDK
> 1.8.0_74
>Reporter: Chris McGee
> Labels: CronTriggeringPolicy, RollingFile, RollingFileAppender,
> newbie
> Fix For: 2.8
>
>
> If this isn't actually a bug, then I apologize for reporting it, but I cannot
> figure out how it could be anything else currently. Full disclosure: I am
> still a newbie.
> I've been using the log4j 2.6.x series for a while, but noticed that the
> CronTriggeringPolicy when used with RollingFileAppender causes that infinite
> rollover bug. I noted that this bug was to be fixed in 2.7, so I downloaded
> that the day it was released and replaced the 2.6 version with it. Now,
> however, without changing anything else in my code nor in my log4j2.xml file,
> I am getting exceptions regarding them.
> Here's the interesting bit: Since I was trying to see if the rollover would
> occur at midnight, I manually changed my computer's clock to just a minute
> before, logged some info, let it roll to past midnight, and let it log some
> more info. All of that info got logged into the main file; nothing rolled
> over. Here's the stacktrace from that execution:
> {noformat}
> 2016-10-10 09:40:47,521 main DEBUG Initializing configuration
> XmlConfiguration[location=/Users/apache/Dropbox/eclipse/workspace/ArtDept/bin/log4j2.xml]
> 2016-10-10 09:40:47,526 main DEBUG Installed script engines
> 2016-10-10 09:40:47,955 main DEBUG Oracle Nashorn Version: 1.8.0_74,
> Language: ECMAScript, Threading: Not Thread Safe, Compile: true, Names:
> {nashorn, Nashorn, js, JS, JavaScript, javascript, ECMAScript, ecmascript}
> 2016-10-10 09:40:48,307 main DEBUG AppleScriptEngine Version: 1.1, Language:
> AppleScript, Threading: Not Thread Safe, Compile: false, Names:
> {AppleScriptEngine, AppleScript, OSA}
> 2016-10-10 09:40:48,308 main DEBUG PluginManager 'Core' found 107 plugins
> 2016-10-10 09:40:48,308 main DEBUG PluginManager 'Level' found 0 plugins
> 2016-10-10 09:40:48,312 main DEBUG 2 starting Log4j2 ConfigurationScheduler
> threads
> 2016-10-10 09:40:48,314 main DEBUG Building Plugin[name=property,
> class=org.apache.logging.log4j.core.config.Property].
> 2016-10-10 09:40:48,323 main TRACE TypeConverterRegistry initializing.
> 2016-10-10 09:40:48,324 main DEBUG PluginManager 'TypeConverter' found 23
> plugins
> 2016-10-10 09:40:48,330 main DEBUG createProperty(name="filename",
> value="logs/artdept.log")
> 2016-10-10 09:40:48,330 main DEBUG Building Plugin[name=property,
> class=org.apache.logging.log4j.core.config.Property].
> 2016-10-10 09:40:48,331 main DEBUG createProperty(name="baseDir",
> value="/Volumes/ArtDept/ArtDept/Scripts/sky-artdept/logs")
> 2016-10-10 09:40:48,331 main DEBUG Building Plugin[name=properties,
> class=org.apache.logging.log4j.core.config.PropertiesPlugin].
> 2016-10-10 09:40:48,334 main DEBUG
> configureSubstitutor(={filename=logs/artdept.log,
> baseDir=/Volumes/ArtDept/ArtDept/Scripts/sky-artdept/logs},
> Configuration(/Users/apache/Dropbox/eclipse/workspace/ArtDept/bin/log4j2.xml))
> 2016-10-10 09:40:48,335 main DEBUG PluginManager 'Lookup' found 13 plugins
> 2016-10-10 09:40:48,335 main DEBUG Building Plugin[name=layout,
> class=org.apache.logging.log4j.core.layout.PatternLayout].
> 2016-10-10 09:40:48,341 main DEBUG
> PatternLayout$Builder(pattern="%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} -
> %msg%n", PatternSelector=null,
> Configuration(/Users/apache/Dropbox/eclipse/workspace/ArtDept/bin/log4j2.xml),
> Replace=null, charset="null", alwaysWriteExceptions="null",
> noConsoleNoAnsi="null", header="null", footer="null")
> 2016-10-10 09:40:48,341 main DEBUG PluginManager 'Converter
[jira] [Commented] (LOG4J2-1640) RollingFileAppender with CronTriggeringPolicy broken?
[
https://issues.apache.org/jira/browse/LOG4J2-1640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15816237#comment-15816237
]
Chris McGee commented on LOG4J2-1640:
-
Wow, a lot of new info to take in. I don't fully understand some of it, but it
sounds like you've made some changes that should correct the issues I've been
having. At this point, am I to assume that I need to re-clone and re-build your
repo, then try running it through my program again to see how it goes? (Except
this time, let it run overnight naturally rather than forcing a rollover with a
system clock change.)
> RollingFileAppender with CronTriggeringPolicy broken?
> -
>
> Key: LOG4J2-1640
> URL: https://issues.apache.org/jira/browse/LOG4J2-1640
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.7
> Environment: Mac OS X 10.11.6 running Eclipse Neon 4.6.0 with JDK
> 1.8.0_74
>Reporter: Chris McGee
> Labels: CronTriggeringPolicy, RollingFile, RollingFileAppender,
> newbie
> Fix For: 2.8
>
>
> If this isn't actually a bug, then I apologize for reporting it, but I cannot
> figure out how it could be anything else currently. Full disclosure: I am
> still a newbie.
> I've been using the log4j 2.6.x series for a while, but noticed that the
> CronTriggeringPolicy when used with RollingFileAppender causes that infinite
> rollover bug. I noted that this bug was to be fixed in 2.7, so I downloaded
> that the day it was released and replaced the 2.6 version with it. Now,
> however, without changing anything else in my code nor in my log4j2.xml file,
> I am getting exceptions regarding them.
> Here's the interesting bit: Since I was trying to see if the rollover would
> occur at midnight, I manually changed my computer's clock to just a minute
> before, logged some info, let it roll to past midnight, and let it log some
> more info. All of that info got logged into the main file; nothing rolled
> over. Here's the stacktrace from that execution:
> {noformat}
> 2016-10-10 09:40:47,521 main DEBUG Initializing configuration
> XmlConfiguration[location=/Users/apache/Dropbox/eclipse/workspace/ArtDept/bin/log4j2.xml]
> 2016-10-10 09:40:47,526 main DEBUG Installed script engines
> 2016-10-10 09:40:47,955 main DEBUG Oracle Nashorn Version: 1.8.0_74,
> Language: ECMAScript, Threading: Not Thread Safe, Compile: true, Names:
> {nashorn, Nashorn, js, JS, JavaScript, javascript, ECMAScript, ecmascript}
> 2016-10-10 09:40:48,307 main DEBUG AppleScriptEngine Version: 1.1, Language:
> AppleScript, Threading: Not Thread Safe, Compile: false, Names:
> {AppleScriptEngine, AppleScript, OSA}
> 2016-10-10 09:40:48,308 main DEBUG PluginManager 'Core' found 107 plugins
> 2016-10-10 09:40:48,308 main DEBUG PluginManager 'Level' found 0 plugins
> 2016-10-10 09:40:48,312 main DEBUG 2 starting Log4j2 ConfigurationScheduler
> threads
> 2016-10-10 09:40:48,314 main DEBUG Building Plugin[name=property,
> class=org.apache.logging.log4j.core.config.Property].
> 2016-10-10 09:40:48,323 main TRACE TypeConverterRegistry initializing.
> 2016-10-10 09:40:48,324 main DEBUG PluginManager 'TypeConverter' found 23
> plugins
> 2016-10-10 09:40:48,330 main DEBUG createProperty(name="filename",
> value="logs/artdept.log")
> 2016-10-10 09:40:48,330 main DEBUG Building Plugin[name=property,
> class=org.apache.logging.log4j.core.config.Property].
> 2016-10-10 09:40:48,331 main DEBUG createProperty(name="baseDir",
> value="/Volumes/ArtDept/ArtDept/Scripts/sky-artdept/logs")
> 2016-10-10 09:40:48,331 main DEBUG Building Plugin[name=properties,
> class=org.apache.logging.log4j.core.config.PropertiesPlugin].
> 2016-10-10 09:40:48,334 main DEBUG
> configureSubstitutor(={filename=logs/artdept.log,
> baseDir=/Volumes/ArtDept/ArtDept/Scripts/sky-artdept/logs},
> Configuration(/Users/apache/Dropbox/eclipse/workspace/ArtDept/bin/log4j2.xml))
> 2016-10-10 09:40:48,335 main DEBUG PluginManager 'Lookup' found 13 plugins
> 2016-10-10 09:40:48,335 main DEBUG Building Plugin[name=layout,
> class=org.apache.logging.log4j.core.layout.PatternLayout].
> 2016-10-10 09:40:48,341 main DEBUG
> PatternLayout$Builder(pattern="%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} -
> %msg%n", PatternSelector=null,
> Configuration(/Users/apache/Dropbox/eclipse/workspace/ArtDept/bin/log4j2.xml),
> Replace=null, charset="null", alwaysWriteExceptions="null",
> noConso
[jira] [Commented] (LOG4J2-1780) LoggerContext does not shut down old executor services when creating new ones during reconfiguration
[
https://issues.apache.org/jira/browse/LOG4J2-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15816238#comment-15816238
]
Gary Gregory commented on LOG4J2-1780:
--
What I think we need to consider here is if reconfiguring a {{LoggerContext}}
means that we should:
- stop it
- reconfigure it
- start it
The {{org.apache.logging.log4j.core.LoggerContext.stop(long, TimeUnit)}} method
stops all executors.
Right now, reconfiguring does not do that.
Callers of {{setConfiguration}} like the {{reconfigure}} methods could stop (if
needed) and start itself.
Needs more thought...
> LoggerContext does not shut down old executor services when creating new ones
> during reconfiguration
>
>
> Key: LOG4J2-1780
> URL: https://issues.apache.org/jira/browse/LOG4J2-1780
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.7
>Reporter: Mikael Ståldal
>
> LoggerContext does not shut down old executor services when creating new ones
> during reconfiguration in {{LoggerContext.setConfiguration}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1780) LoggerContext does not shut down old executor services when creating new ones during reconfiguration
[
https://issues.apache.org/jira/browse/LOG4J2-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15816212#comment-15816212
]
Mikael Ståldal commented on LOG4J2-1780:
Ping [~garydgregory]
> LoggerContext does not shut down old executor services when creating new ones
> during reconfiguration
>
>
> Key: LOG4J2-1780
> URL: https://issues.apache.org/jira/browse/LOG4J2-1780
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.7
>Reporter: Mikael Ståldal
>
> LoggerContext does not shut down old executor services when creating new ones
> during reconfiguration in {{LoggerContext.setConfiguration}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1748) RollingFile appender prevents a stand alone application to terminate for as long as 60 sec
[
https://issues.apache.org/jira/browse/LOG4J2-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15816208#comment-15816208
]
Mikael Ståldal commented on LOG4J2-1748:
Created a bug for the failure to shut down old ExecutorServices:
https://issues.apache.org/jira/browse/LOG4J2-1780
> RollingFile appender prevents a stand alone application to terminate for as
> long as 60 sec
> --
>
> Key: LOG4J2-1748
> URL: https://issues.apache.org/jira/browse/LOG4J2-1748
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.7
> Environment: Java8, Windows
>Reporter: Daniele Demichelis
>Assignee: Remko Popma
> Labels: RollingFile, bug
> Fix For: 2.8
>
>
> This code reproduces what I think is a bug of Log4j2.
> It's a simple loop that logs 2000 messages with two appenders:
> a console appender and a rolling file appender that rolls the file
> every 5Kb. This limit is intentionally low to reproduce what I think is a bug.
> Here's the code.
> {code:java}
> package bug;
>
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.Logger;
>
> public class Example {
>
> private static final Logger logger =
> LogManager.getLogger(Example.class);
>
> public static void main(String[] args) throws InterruptedException {
> for(int i = 0; i<2000; i++){
> logger.info("This is log message #{}.", i);
> Thread.sleep(0);
> }
> }
>
> }
> {code}
> Here's the `log4j2.xml` configuration file.
> {code:xml}
>
>
>
>
>
>
> fileName="target/log4j2/roll-by-size/app.log"
>
> filePattern="target/log4j2/roll-by-size/app.%i.log.gz"
> ignoreExceptions="false"
> append="false">
>
> %d{-MM-dd HH:mm:ss} %p %m%n
>
>
>
> size="5 KB"/>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> What is strange is that when the application is launched you will see this
> logs in the console.
> {code}
> 2016-12-22 22:12:36 INFO This is log message #1993.
> 2016-12-22 22:12:36 INFO This is log message #1994.
> 2016-12-22 22:12:36 INFO This is log message #1995.
> 2016-12-22 22:12:36 INFO This is log message #1996.
> 2016-12-22 22:12:36 INFO This is log message #1997.
> 2016-12-22 22:12:36 INFO This is log message #1998.
> 2016-12-22 22:12:36 INFO This is log message #1999.
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]...
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=StatusLogger]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=ContextSelector]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Loggers,name=bug,
> org.apache.logging.log4j2:type=60199c81,component=Lo
> ggers,name=]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Appenders,name=roll-by-size,
> org.apache.logging.log4j2:type=60199c81,c
> omponent=Appenders,name=stdout]
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Unregistering but no MBeans
> found matching
> 'org.apache.logging.log4j2:type=60199c81,component=AsyncAppenders,name=*'
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Unregistering but no MBeans
> found matching
> &#x
[jira] [Created] (LOG4J2-1780) LoggerContext does not shut down old executor services when creating new ones during reconfiguration
Mikael Ståldal created LOG4J2-1780:
--
Summary: LoggerContext does not shut down old executor services
when creating new ones during reconfiguration
Key: LOG4J2-1780
URL: https://issues.apache.org/jira/browse/LOG4J2-1780
Project: Log4j 2
Issue Type: Bug
Components: Core
Affects Versions: 2.7
Reporter: Mikael Ståldal
LoggerContext does not shut down old executor services when creating new ones
during reconfiguration in {{LoggerContext.setConfiguration}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-1748) RollingFile appender prevents a stand alone application to terminate for as long as 60 sec
[
https://issues.apache.org/jira/browse/LOG4J2-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15816150#comment-15816150
]
Mikael Ståldal edited comment on LOG4J2-1748 at 1/10/17 9:01 PM:
-
I am not sure that it will be dangerous to use a daemon thread since we have a
shutdown hook. According to
http://docs.oracle.com/javase/8/docs/api/java/lang/Runtime.html#addShutdownHook-java.lang.Thread-
:
{quote}
Note that daemon threads will continue to run during the shutdown sequence, as
will non-daemon threads if shutdown was initiated by invoking the exit method.
{quote}
If there is a risk for partial rollover with daemon threads, that risk exist
for non-daemon threads as well if the application exits with
{{System.exit(int)}} (which is a quite common thing to do I guess).
I suggest that we use daemon threads for both pools, and only treat them
differently when shutting down (as we currently do). Then Remko's fix can be
reverted.
was (Author: mikaelstaldal):
I am not sure that it will be dangerous to use a daemon thread since we have a
shutdown hook. According to
http://docs.oracle.com/javase/8/docs/api/java/lang/Runtime.html#addShutdownHook-java.lang.Thread-
:
{code}
Note that daemon threads will continue to run during the shutdown sequence, as
will non-daemon threads if shutdown was initiated by invoking the exit method.
{code}
If there is a risk for partial rollover with daemon threads, that risk exist
for non-daemon threads as well if the application exits with
{{System.exit(int)}} (which is a quite common thing to do I guess).
I suggest that we remove the non-daemon executor pool and only have a daemon
one. Then Remko's fix can be reverted.
> RollingFile appender prevents a stand alone application to terminate for as
> long as 60 sec
> --
>
> Key: LOG4J2-1748
> URL: https://issues.apache.org/jira/browse/LOG4J2-1748
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.7
> Environment: Java8, Windows
>Reporter: Daniele Demichelis
>Assignee: Remko Popma
> Labels: RollingFile, bug
> Fix For: 2.8
>
>
> This code reproduces what I think is a bug of Log4j2.
> It's a simple loop that logs 2000 messages with two appenders:
> a console appender and a rolling file appender that rolls the file
> every 5Kb. This limit is intentionally low to reproduce what I think is a bug.
> Here's the code.
> {code:java}
> package bug;
>
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.Logger;
>
> public class Example {
>
> private static final Logger logger =
> LogManager.getLogger(Example.class);
>
> public static void main(String[] args) throws InterruptedException {
> for(int i = 0; i<2000; i++){
> logger.info("This is log message #{}.", i);
> Thread.sleep(0);
> }
> }
>
> }
> {code}
> Here's the `log4j2.xml` configuration file.
> {code:xml}
>
>
>
>
>
>
> fileName="target/log4j2/roll-by-size/app.log"
>
> filePattern="target/log4j2/roll-by-size/app.%i.log.gz"
> ignoreExceptions="false"
> append="false">
>
> %d{-MM-dd HH:mm:ss} %p %m%n
>
>
>
> size="5 KB"/>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> What is strange is that when the application is launched you will see this
> logs in the console.
> {code}
> 2016-12-22 22:12:36 INFO This is log message #1993.
> 2016-12-22 22:12:36 INFO This is log message #1994.
> 2016-12-22 22:12:36 INFO This is log message #1995.
> 2016-12-22 22:12:36 INFO This is log message #1996.
> 2016-12-22 22:12:36 INFO This is log message #1997.
> 2016-12-22 22:12:36 INFO This is log message #1998.
> 2016-12-22 22:12:36 INFO This is log message #1999.
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
>
[jira] [Commented] (LOG4J2-1748) RollingFile appender prevents a stand alone application to terminate for as long as 60 sec
[
https://issues.apache.org/jira/browse/LOG4J2-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15816150#comment-15816150
]
Mikael Ståldal commented on LOG4J2-1748:
I am not sure that it will be dangerous to use a daemon thread since we have a
shutdown hook. According to
http://docs.oracle.com/javase/8/docs/api/java/lang/Runtime.html#addShutdownHook-java.lang.Thread-
:
{code}
Note that daemon threads will continue to run during the shutdown sequence, as
will non-daemon threads if shutdown was initiated by invoking the exit method.
{code}
If there is a risk for partial rollover with daemon threads, that risk exist
for non-daemon threads as well if the application exits with
{{System.exit(int)}} (which is a quite common thing to do I guess).
I suggest that we remove the non-daemon executor pool and only have a daemon
one. Then Remko's fix can be reverted.
> RollingFile appender prevents a stand alone application to terminate for as
> long as 60 sec
> --
>
> Key: LOG4J2-1748
> URL: https://issues.apache.org/jira/browse/LOG4J2-1748
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.7
> Environment: Java8, Windows
>Reporter: Daniele Demichelis
>Assignee: Remko Popma
> Labels: RollingFile, bug
> Fix For: 2.8
>
>
> This code reproduces what I think is a bug of Log4j2.
> It's a simple loop that logs 2000 messages with two appenders:
> a console appender and a rolling file appender that rolls the file
> every 5Kb. This limit is intentionally low to reproduce what I think is a bug.
> Here's the code.
> {code:java}
> package bug;
>
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.Logger;
>
> public class Example {
>
> private static final Logger logger =
> LogManager.getLogger(Example.class);
>
> public static void main(String[] args) throws InterruptedException {
> for(int i = 0; i<2000; i++){
> logger.info("This is log message #{}.", i);
> Thread.sleep(0);
> }
> }
>
> }
> {code}
> Here's the `log4j2.xml` configuration file.
> {code:xml}
>
>
>
>
>
>
> fileName="target/log4j2/roll-by-size/app.log"
>
> filePattern="target/log4j2/roll-by-size/app.%i.log.gz"
> ignoreExceptions="false"
> append="false">
>
> %d{-MM-dd HH:mm:ss} %p %m%n
>
>
>
> size="5 KB"/>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> What is strange is that when the application is launched you will see this
> logs in the console.
> {code}
> 2016-12-22 22:12:36 INFO This is log message #1993.
> 2016-12-22 22:12:36 INFO This is log message #1994.
> 2016-12-22 22:12:36 INFO This is log message #1995.
> 2016-12-22 22:12:36 INFO This is log message #1996.
> 2016-12-22 22:12:36 INFO This is log message #1997.
> 2016-12-22 22:12:36 INFO This is log message #1998.
> 2016-12-22 22:12:36 INFO This is log message #1999.
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]...
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=StatusLogger]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=ContextSelector]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Loggers,name=bug,
> org.apache.logging.lo
[jira] [Closed] (LOG4J2-1762) Add Builder to GelfLayout
[ https://issues.apache.org/jira/browse/LOG4J2-1762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikael Ståldal closed LOG4J2-1762. -- > Add Builder to GelfLayout > - > > Key: LOG4J2-1762 > URL: https://issues.apache.org/jira/browse/LOG4J2-1762 > Project: Log4j 2 > Issue Type: New Feature > Components: Layouts >Affects Versions: 2.7 >Reporter: Mikael Ståldal >Assignee: Mikael Ståldal > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-1769) JsonLayout Throwing Exceptions And Producing Broken Logs
[
https://issues.apache.org/jira/browse/LOG4J2-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Goodin closed LOG4J2-1769.
--
This is indeed fixed in the 2.7.1 SNAPSHOT.
> JsonLayout Throwing Exceptions And Producing Broken Logs
>
>
> Key: LOG4J2-1769
> URL: https://issues.apache.org/jira/browse/LOG4J2-1769
> Project: Log4j 2
> Issue Type: Bug
> Components: Layouts
>Affects Versions: 2.7
> Environment: All Platforms
>Reporter: Brandon Goodin
>Assignee: Remko Popma
> Fix For: 2.8
>
> Attachments: JSONLayoutIssuesTest.java, RequestStatistic.java,
> log4j2.xml
>
>
> In a multithreaded environment JsonLayout is throwing exceptions and
> producing fragmented logs. We were able to produce a test that demonstrates
> this. The following exceptions and broken logging are being seen.
> {code:title=IllegalArgumentException}
> 2017-01-06 16:57:59,173 Thread-98 ERROR An exception occurred processing
> Appender stdout java.lang.IllegalArgumentException
> at java.nio.Buffer.position(Buffer.java:244)
> at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:191)
> at
> org.apache.logging.log4j.core.layout.AbstractLayout.writeTo(AbstractLayout.java:179)
> at
> org.apache.logging.log4j.core.layout.AbstractLayout.encode(AbstractLayout.java:160)
> at
> org.apache.logging.log4j.core.layout.AbstractLayout.encode(AbstractLayout.java:36)
> at
> org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.directEncodeEvent(AbstractOutputStreamAppender.java:176)
> at
> org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.tryAppend(AbstractOutputStreamAppender.java:169)
> at
> org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.append(AbstractOutputStreamAppender.java:160)
> at
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppender0(AppenderControl.java:129)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppenderPreventRecursion(AppenderControl.java:120)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:84)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:447)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:432)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:416)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:402)
> at
> org.apache.logging.log4j.core.config.AwaitCompletionReliabilityStrategy.log(AwaitCompletionReliabilityStrategy.java:63)
> at org.apache.logging.log4j.core.Logger.logMessage(Logger.java:146)
> at
> org.apache.logging.log4j.spi.AbstractLogger.logMessageSafely(AbstractLogger.java:2091)
> at
> org.apache.logging.log4j.spi.AbstractLogger.logMessage(AbstractLogger.java:1988)
> at
> org.apache.logging.log4j.spi.AbstractLogger.logIfEnabled(AbstractLogger.java:1960)
> at
> org.apache.logging.log4j.spi.AbstractLogger.info(AbstractLogger.java:1297)
> at
> org.apache.logging.log4j.JSONLayoutIssuesTest$LoggingThread.run(JSONLayoutIssuesTest.java:54)
> {code}
> {code:title=BufferOverflowException}
> 2017-01-06 16:57:59,194 Thread-99 ERROR An exception occurred processing
> Appender stdout java.nio.BufferOverflowException
> at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:189)
> at
> org.apache.logging.log4j.core.layout.AbstractLayout.writeTo(AbstractLayout.java:179)
> at
> org.apache.logging.log4j.core.layout.AbstractLayout.encode(AbstractLayout.java:160)
> at
> org.apache.logging.log4j.core.layout.AbstractLayout.encode(AbstractLayout.java:36)
> at
> org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.directEncodeEvent(AbstractOutputStreamAppender.java:176)
> at
> org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.tryAppend(AbstractOutputStreamAppender.java:169)
> at
> org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.append(AbstractOutputStreamAppender.java:160)
> at
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppender0(AppenderControl.java:129)
> at
> org.apache.logging.l
[jira] [Commented] (LOG4J2-1769) JsonLayout Throwing Exceptions And Producing Broken Logs
[
https://issues.apache.org/jira/browse/LOG4J2-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15815651#comment-15815651
]
Brandon Goodin commented on LOG4J2-1769:
I tested against 2.7.1-SNAPSHOT on January 10th
(https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/log4j-api/2.7.1-SNAPSHOT/).
The tests ran successfully with no exceptions and no fragmented logs.
> JsonLayout Throwing Exceptions And Producing Broken Logs
>
>
> Key: LOG4J2-1769
> URL: https://issues.apache.org/jira/browse/LOG4J2-1769
> Project: Log4j 2
> Issue Type: Bug
> Components: Layouts
>Affects Versions: 2.7
> Environment: All Platforms
>Reporter: Brandon Goodin
>Assignee: Remko Popma
> Fix For: 2.8
>
> Attachments: JSONLayoutIssuesTest.java, RequestStatistic.java,
> log4j2.xml
>
>
> In a multithreaded environment JsonLayout is throwing exceptions and
> producing fragmented logs. We were able to produce a test that demonstrates
> this. The following exceptions and broken logging are being seen.
> {code:title=IllegalArgumentException}
> 2017-01-06 16:57:59,173 Thread-98 ERROR An exception occurred processing
> Appender stdout java.lang.IllegalArgumentException
> at java.nio.Buffer.position(Buffer.java:244)
> at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:191)
> at
> org.apache.logging.log4j.core.layout.AbstractLayout.writeTo(AbstractLayout.java:179)
> at
> org.apache.logging.log4j.core.layout.AbstractLayout.encode(AbstractLayout.java:160)
> at
> org.apache.logging.log4j.core.layout.AbstractLayout.encode(AbstractLayout.java:36)
> at
> org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.directEncodeEvent(AbstractOutputStreamAppender.java:176)
> at
> org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.tryAppend(AbstractOutputStreamAppender.java:169)
> at
> org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.append(AbstractOutputStreamAppender.java:160)
> at
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppender0(AppenderControl.java:129)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppenderPreventRecursion(AppenderControl.java:120)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:84)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:447)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:432)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:416)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:402)
> at
> org.apache.logging.log4j.core.config.AwaitCompletionReliabilityStrategy.log(AwaitCompletionReliabilityStrategy.java:63)
> at org.apache.logging.log4j.core.Logger.logMessage(Logger.java:146)
> at
> org.apache.logging.log4j.spi.AbstractLogger.logMessageSafely(AbstractLogger.java:2091)
> at
> org.apache.logging.log4j.spi.AbstractLogger.logMessage(AbstractLogger.java:1988)
> at
> org.apache.logging.log4j.spi.AbstractLogger.logIfEnabled(AbstractLogger.java:1960)
> at
> org.apache.logging.log4j.spi.AbstractLogger.info(AbstractLogger.java:1297)
> at
> org.apache.logging.log4j.JSONLayoutIssuesTest$LoggingThread.run(JSONLayoutIssuesTest.java:54)
> {code}
> {code:title=BufferOverflowException}
> 2017-01-06 16:57:59,194 Thread-99 ERROR An exception occurred processing
> Appender stdout java.nio.BufferOverflowException
> at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:189)
> at
> org.apache.logging.log4j.core.layout.AbstractLayout.writeTo(AbstractLayout.java:179)
> at
> org.apache.logging.log4j.core.layout.AbstractLayout.encode(AbstractLayout.java:160)
> at
> org.apache.logging.log4j.core.layout.AbstractLayout.encode(AbstractLayout.java:36)
> at
> org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.directEncodeEvent(AbstractOutputStreamAppender.java:176)
> at
> org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.tryAppend(AbstractOutputStreamAppender.java:169)
> at
> org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.append(AbstractO
[jira] [Closed] (LOG4J2-1779) AsyncLogger does not lookup properties
[
https://issues.apache.org/jira/browse/LOG4J2-1779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma closed LOG4J2-1779.
---
> AsyncLogger does not lookup properties
> --
>
> Key: LOG4J2-1779
> URL: https://issues.apache.org/jira/browse/LOG4J2-1779
> Project: Log4j 2
> Issue Type: Bug
> Components: Core, Lookups
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.8
>
>
> When copying configuration Properties into the context data map of each log
> event, property values that start with "${" should be treated as a Lookup and
> be resolved with {{StrSubstitutor.replace}}.
> AsyncLogger has a bug such that this lookup does not happen and the original
> value (starting with "${") is put in the contxt data map of the log event.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-1779) AsyncLogger does not lookup properties
[
https://issues.apache.org/jira/browse/LOG4J2-1779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma resolved LOG4J2-1779.
-
Resolution: Fixed
Fixed in commit a686a4e.
> AsyncLogger does not lookup properties
> --
>
> Key: LOG4J2-1779
> URL: https://issues.apache.org/jira/browse/LOG4J2-1779
> Project: Log4j 2
> Issue Type: Bug
> Components: Core, Lookups
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.8
>
>
> When copying configuration Properties into the context data map of each log
> event, property values that start with "${" should be treated as a Lookup and
> be resolved with {{StrSubstitutor.replace}}.
> AsyncLogger has a bug such that this lookup does not happen and the original
> value (starting with "${") is put in the contxt data map of the log event.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-1779) AsyncLogger does not lookup properties
Remko Popma created LOG4J2-1779:
---
Summary: AsyncLogger does not lookup properties
Key: LOG4J2-1779
URL: https://issues.apache.org/jira/browse/LOG4J2-1779
Project: Log4j 2
Issue Type: Bug
Components: Core, Lookups
Reporter: Remko Popma
Assignee: Remko Popma
Fix For: 2.8
When copying configuration Properties into the context data map of each log
event, property values that start with "${" should be treated as a Lookup and
be resolved with {{StrSubstitutor.replace}}.
AsyncLogger has a bug such that this lookup does not happen and the original
value (starting with "${") is put in the contxt data map of the log event.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1724) Using variables in GelfLayout's additional fields at runtime
[
https://issues.apache.org/jira/browse/LOG4J2-1724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15815008#comment-15815008
]
Alexander K. commented on LOG4J2-1724:
--
It works as expected. Thanks.
> Using variables in GelfLayout's additional fields at runtime
>
>
> Key: LOG4J2-1724
> URL: https://issues.apache.org/jira/browse/LOG4J2-1724
> Project: Log4j 2
> Issue Type: Improvement
> Components: Layouts
>Affects Versions: 2.6.2, 2.7
>Reporter: Alexander K.
>Assignee: Mikael Ståldal
> Fix For: 2.8
>
> Attachments: patchfile.txt, patchfile.txt
>
>
> Hello,
> I would like to suggest the following improvements for GelfLayout:
> 1. Using variables in additional fields at runtime. For example resolving
> "value": "$$\{ctx:key\}" at runtime as it is done in other places. Thus,
> custom lookups will be available as well.
> 2. Having an indicator includeThreadContext to control whether the contents
> of the ThreadContext should be included. Sometimes it is usable to include
> only some of its values and then it will be available using the first
> suggested improvement by specific variable resolution.
> 3. Resolving HOST attribute in case it is not provided by using for example
> InetAddress.getLocalHost().getHostName().
> Regards,
> Alexander
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-1724) Using variables in GelfLayout's additional fields at runtime
[
https://issues.apache.org/jira/browse/LOG4J2-1724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander K. closed LOG4J2-1724.
> Using variables in GelfLayout's additional fields at runtime
>
>
> Key: LOG4J2-1724
> URL: https://issues.apache.org/jira/browse/LOG4J2-1724
> Project: Log4j 2
> Issue Type: Improvement
> Components: Layouts
>Affects Versions: 2.6.2, 2.7
>Reporter: Alexander K.
>Assignee: Mikael Ståldal
> Fix For: 2.8
>
> Attachments: patchfile.txt, patchfile.txt
>
>
> Hello,
> I would like to suggest the following improvements for GelfLayout:
> 1. Using variables in additional fields at runtime. For example resolving
> "value": "$$\{ctx:key\}" at runtime as it is done in other places. Thus,
> custom lookups will be available as well.
> 2. Having an indicator includeThreadContext to control whether the contents
> of the ThreadContext should be included. Sometimes it is usable to include
> only some of its values and then it will be available using the first
> suggested improvement by specific variable resolution.
> 3. Resolving HOST attribute in case it is not provided by using for example
> InetAddress.getLocalHost().getHostName().
> Regards,
> Alexander
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1748) RollingFile appender prevents a stand alone application to terminate for as long as 60 sec
[
https://issues.apache.org/jira/browse/LOG4J2-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15814716#comment-15814716
]
Mikael Ståldal commented on LOG4J2-1748:
After looking more closely at this, I think it actually make sense to have this
separate. It is actually idle thread timeout, not shutdown timeout. It just
happen to delay shutdown in some cases (when the app doesn't to
{{System.exit(int)}}).
> RollingFile appender prevents a stand alone application to terminate for as
> long as 60 sec
> --
>
> Key: LOG4J2-1748
> URL: https://issues.apache.org/jira/browse/LOG4J2-1748
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.7
> Environment: Java8, Windows
>Reporter: Daniele Demichelis
>Assignee: Remko Popma
> Labels: RollingFile, bug
> Fix For: 2.8
>
>
> This code reproduces what I think is a bug of Log4j2.
> It's a simple loop that logs 2000 messages with two appenders:
> a console appender and a rolling file appender that rolls the file
> every 5Kb. This limit is intentionally low to reproduce what I think is a bug.
> Here's the code.
> {code:java}
> package bug;
>
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.Logger;
>
> public class Example {
>
> private static final Logger logger =
> LogManager.getLogger(Example.class);
>
> public static void main(String[] args) throws InterruptedException {
> for(int i = 0; i<2000; i++){
> logger.info("This is log message #{}.", i);
> Thread.sleep(0);
> }
> }
>
> }
> {code}
> Here's the `log4j2.xml` configuration file.
> {code:xml}
>
>
>
>
>
>
> fileName="target/log4j2/roll-by-size/app.log"
>
> filePattern="target/log4j2/roll-by-size/app.%i.log.gz"
> ignoreExceptions="false"
> append="false">
>
> %d{-MM-dd HH:mm:ss} %p %m%n
>
>
>
> size="5 KB"/>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> What is strange is that when the application is launched you will see this
> logs in the console.
> {code}
> 2016-12-22 22:12:36 INFO This is log message #1993.
> 2016-12-22 22:12:36 INFO This is log message #1994.
> 2016-12-22 22:12:36 INFO This is log message #1995.
> 2016-12-22 22:12:36 INFO This is log message #1996.
> 2016-12-22 22:12:36 INFO This is log message #1997.
> 2016-12-22 22:12:36 INFO This is log message #1998.
> 2016-12-22 22:12:36 INFO This is log message #1999.
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]...
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=StatusLogger]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=ContextSelector]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Loggers,name=bug,
> org.apache.logging.log4j2:type=60199c81,component=Lo
> ggers,name=]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Appenders,name=roll-by-size,
> org.apache.logging.log4j2:type=60199c81,c
> omponent=Appenders,name=stdout]
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Unregistering but no MBeans
> found matching
> 'org.apache.logging.log4j2:type=60199c81,component=AsyncAppe
[jira] [Commented] (LOG4J2-1748) RollingFile appender prevents a stand alone application to terminate for as long as 60 sec
[
https://issues.apache.org/jira/browse/LOG4J2-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15814711#comment-15814711
]
Mikael Ståldal commented on LOG4J2-1748:
A simple workaround is to add System.exit(0) at the end of the main method.
> RollingFile appender prevents a stand alone application to terminate for as
> long as 60 sec
> --
>
> Key: LOG4J2-1748
> URL: https://issues.apache.org/jira/browse/LOG4J2-1748
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.7
> Environment: Java8, Windows
>Reporter: Daniele Demichelis
>Assignee: Remko Popma
> Labels: RollingFile, bug
> Fix For: 2.8
>
>
> This code reproduces what I think is a bug of Log4j2.
> It's a simple loop that logs 2000 messages with two appenders:
> a console appender and a rolling file appender that rolls the file
> every 5Kb. This limit is intentionally low to reproduce what I think is a bug.
> Here's the code.
> {code:java}
> package bug;
>
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.Logger;
>
> public class Example {
>
> private static final Logger logger =
> LogManager.getLogger(Example.class);
>
> public static void main(String[] args) throws InterruptedException {
> for(int i = 0; i<2000; i++){
> logger.info("This is log message #{}.", i);
> Thread.sleep(0);
> }
> }
>
> }
> {code}
> Here's the `log4j2.xml` configuration file.
> {code:xml}
>
>
>
>
>
>
> fileName="target/log4j2/roll-by-size/app.log"
>
> filePattern="target/log4j2/roll-by-size/app.%i.log.gz"
> ignoreExceptions="false"
> append="false">
>
> %d{-MM-dd HH:mm:ss} %p %m%n
>
>
>
> size="5 KB"/>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> What is strange is that when the application is launched you will see this
> logs in the console.
> {code}
> 2016-12-22 22:12:36 INFO This is log message #1993.
> 2016-12-22 22:12:36 INFO This is log message #1994.
> 2016-12-22 22:12:36 INFO This is log message #1995.
> 2016-12-22 22:12:36 INFO This is log message #1996.
> 2016-12-22 22:12:36 INFO This is log message #1997.
> 2016-12-22 22:12:36 INFO This is log message #1998.
> 2016-12-22 22:12:36 INFO This is log message #1999.
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]...
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=StatusLogger]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=ContextSelector]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Loggers,name=bug,
> org.apache.logging.log4j2:type=60199c81,component=Lo
> ggers,name=]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Appenders,name=roll-by-size,
> org.apache.logging.log4j2:type=60199c81,c
> omponent=Appenders,name=stdout]
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Unregistering but no MBeans
> found matching
> 'org.apache.logging.log4j2:type=60199c81,component=AsyncAppenders,name=*'
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Unregistering but no MBeans
> found matching
> 'org.apache.logging.log4j2:type=6019
[jira] [Updated] (LOG4J2-1776) log4j-boot pom modules for dependency management
[
https://issues.apache.org/jira/browse/LOG4J2-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker updated LOG4J2-1776:
Description:
This is the main feature for the Log4j Boot epic (LOG4J2-1775).
{code}
groupId: org.apache.logging.log4j.boot
artifactId: log4j-boot-*
{code}
* core: just log4j-core basically
* async (for AsyncLogger; brings in LMAX disruptor)
* log4j-spi: log4j-slf4j-impl, log4j-jul, log4j-jcl, log4j-1.2-api
* slf4j-spi: slf4j-impl, jcl-over-slf4j, jul-to-slf4j (same dependency set as
spring-boot-starter-log4j2)
* logback (for log4j-to-slf4j, slf4j-spi, logback; this helps aid migration to
log4j-api and promotes it as a general use logging API)
* advertiser-jmdns
* appender-async-conversant
* appender-async-jctools
* appender-cassandra
* appender-couchdb
* appender-jms
* appender-jpa
* appender-kafka
* appender-mongodb
* appender-smtp
* appender-zeromq
* config-json
* config-yaml
* layout-csv
* layout-jansi (for windows users and coloured log messages)
* layout-json (unless this has been ported to not require jackson anymore?)
* layout-xml
* layout-yaml
* script-groovy
I may have missed a few, but the base set of starters should at least
correspond to all optional dependencies in log4j-core or the addon modules. For
the jms, jpa, and smtp (log4j-core) appenders, we could either make add in a
default provider (e.g., ActiveMQ, Hibernate, and Sun Mail respectively) or
split those into provider-specific starters.
was:
This is the main feature for the Log4j Boot epic (LOG4J2-1775).
{code}
groupId: org.apache.logging.log4j.boot
artifactId: log4j-boot-*
{code}
* core: just log4j-core basically
* async (for AsyncLogger; brings in LMAX disruptor)
* log4j-spi: log4j-slf4j-impl, log4j-jul, log4j-jcl, log4j-1.2-api
* slf4j-spi: slf4j-impl, jcl-over-slf4j, jul-to-slf4j (same dependency set as
spring-boot-starter-log4j2)
* logback (for log4j-to-slf4j, slf4j-spi, logback; this helps aid migration to
log4j-api and promotes it as a general use logging API)
* appender-async-conversant
* appender-async-jctools
* appender-cassandra
* appender-couchdb
* appender-jms
* appender-jpa
* appender-kafka
* appender-mongodb
* appender-smtp
* appender-zeromq
* config-json
* config-yaml
* layout-csv
* layout-jansi (for windows users and coloured log messages)
* layout-json (unless this has been ported to not require jackson anymore?)
* layout-xml
* layout-yaml
* script-groovy
I may have missed a few, but the base set of starters should at least
correspond to all optional dependencies in log4j-core or the addon modules. For
the jms, jpa, and smtp (log4j-core) appenders, we could either make add in a
default provider (e.g., ActiveMQ, Hibernate, and Sun Mail respectively) or
split those into provider-specific starters.
> log4j-boot pom modules for dependency management
>
>
> Key: LOG4J2-1776
> URL: https://issues.apache.org/jira/browse/LOG4J2-1776
> Project: Log4j 2
> Issue Type: New Feature
> Components: Boot
>Reporter: Matt Sicker
>
> This is the main feature for the Log4j Boot epic (LOG4J2-1775).
> {code}
> groupId: org.apache.logging.log4j.boot
> artifactId: log4j-boot-*
> {code}
> * core: just log4j-core basically
> * async (for AsyncLogger; brings in LMAX disruptor)
> * log4j-spi: log4j-slf4j-impl, log4j-jul, log4j-jcl, log4j-1.2-api
> * slf4j-spi: slf4j-impl, jcl-over-slf4j, jul-to-slf4j (same dependency set as
> spring-boot-starter-log4j2)
> * logback (for log4j-to-slf4j, slf4j-spi, logback; this helps aid migration
> to log4j-api and promotes it as a general use logging API)
> * advertiser-jmdns
> * appender-async-conversant
> * appender-async-jctools
> * appender-cassandra
> * appender-couchdb
> * appender-jms
> * appender-jpa
> * appender-kafka
> * appender-mongodb
> * appender-smtp
> * appender-zeromq
> * config-json
> * config-yaml
> * layout-csv
> * layout-jansi (for windows users and coloured log messages)
> * layout-json (unless this has been ported to not require jackson anymore?)
> * layout-xml
> * layout-yaml
> * script-groovy
> I may have missed a few, but the base set of starters should at least
> correspond to all optional dependencies in log4j-core or the addon modules.
> For the jms, jpa, and smtp (log4j-core) appenders, we could either make add
> in a default provider (e.g., ActiveMQ, Hibernate, and Sun Mail respectively)
> or split those into provider-specific starters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-1778) Add logging-log4j-boot git repo
[ https://issues.apache.org/jira/browse/LOG4J2-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker closed LOG4J2-1778. --- Resolution: Fixed https://git-wip-us.apache.org/repos/asf/logging-log4j-boot.git > Add logging-log4j-boot git repo > --- > > Key: LOG4J2-1778 > URL: https://issues.apache.org/jira/browse/LOG4J2-1778 > Project: Log4j 2 > Issue Type: New Git Repo > Components: Boot >Reporter: Matt Sicker >Assignee: Matt Sicker > > Create a new git repository to host Log4j Boot. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1777) Add JUnit categories to integration tests for use in log4j-boot module test suites
[
https://issues.apache.org/jira/browse/LOG4J2-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker updated LOG4J2-1777:
Description: Add JUnit {{@Category}}
[annotations|https://github.com/junit-team/junit4/wiki/Categories] to the
various integration tests that correspond to Log4j Boot modules. Also add test
suites to log4j-boot modules themselves to run those tests as part of their
build. (was: Add JUnit {{@Category}}
[annotations|https://github.com/junit-team/junit4/wiki/Categories] to the
various integration tests that correspond to Log4j Starter modules. Also add
test suites to log4j-starter modules themselves to run those tests as part of
their build.)
> Add JUnit categories to integration tests for use in log4j-boot module test
> suites
> --
>
> Key: LOG4J2-1777
> URL: https://issues.apache.org/jira/browse/LOG4J2-1777
> Project: Log4j 2
> Issue Type: Test
> Components: Boot
>Reporter: Matt Sicker
>Assignee: Matt Sicker
>
> Add JUnit {{@Category}}
> [annotations|https://github.com/junit-team/junit4/wiki/Categories] to the
> various integration tests that correspond to Log4j Boot modules. Also add
> test suites to log4j-boot modules themselves to run those tests as part of
> their build.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1777) Add JUnit categories to integration tests for use in log4j-boot module test suites
[
https://issues.apache.org/jira/browse/LOG4J2-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker updated LOG4J2-1777:
Summary: Add JUnit categories to integration tests for use in log4j-boot
module test suites (was: Add JUnit categories to integration tests for use in
log4j-starter module test suites)
> Add JUnit categories to integration tests for use in log4j-boot module test
> suites
> --
>
> Key: LOG4J2-1777
> URL: https://issues.apache.org/jira/browse/LOG4J2-1777
> Project: Log4j 2
> Issue Type: Test
> Components: Boot
>Reporter: Matt Sicker
>Assignee: Matt Sicker
>
> Add JUnit {{@Category}}
> [annotations|https://github.com/junit-team/junit4/wiki/Categories] to the
> various integration tests that correspond to Log4j Starter modules. Also add
> test suites to log4j-starter modules themselves to run those tests as part of
> their build.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Assigned] (LOG4J2-1777) Add JUnit categories to integration tests for use in log4j-starter module test suites
[
https://issues.apache.org/jira/browse/LOG4J2-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker reassigned LOG4J2-1777:
---
Assignee: Matt Sicker
> Add JUnit categories to integration tests for use in log4j-starter module
> test suites
> -
>
> Key: LOG4J2-1777
> URL: https://issues.apache.org/jira/browse/LOG4J2-1777
> Project: Log4j 2
> Issue Type: Test
> Components: Boot
>Reporter: Matt Sicker
>Assignee: Matt Sicker
>
> Add JUnit {{@Category}}
> [annotations|https://github.com/junit-team/junit4/wiki/Categories] to the
> various integration tests that correspond to Log4j Starter modules. Also add
> test suites to log4j-starter modules themselves to run those tests as part of
> their build.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-1778) Add logging-log4j-boot git repo
Matt Sicker created LOG4J2-1778: --- Summary: Add logging-log4j-boot git repo Key: LOG4J2-1778 URL: https://issues.apache.org/jira/browse/LOG4J2-1778 Project: Log4j 2 Issue Type: New Git Repo Components: Boot Reporter: Matt Sicker Assignee: Matt Sicker Create a new git repository to host Log4j Boot. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1775) Log4j Boot modules for easy dependency management
[ https://issues.apache.org/jira/browse/LOG4J2-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker updated LOG4J2-1775: Summary: Log4j Boot modules for easy dependency management (was: Add boot pom files for dependency management) > Log4j Boot modules for easy dependency management > - > > Key: LOG4J2-1775 > URL: https://issues.apache.org/jira/browse/LOG4J2-1775 > Project: Log4j 2 > Issue Type: Epic > Components: Boot, Documentation, Plugins >Reporter: Matt Sicker > Labels: build, documentation, features, maven, test > > Create what is essentially Log4j Boot for adding necessary dependencies to > support the various plugins while at the same time promoting the use of > log4j-api as a general purpose logging API standard. These modules would > categorise all the various natural dependency barriers for a sort of pseudo > module system that could also help in any necessary module metadata needed to > support Java 9 and OSGi, categorise integration style unit tests to help test > the starters themselves in an automated way, and organise the site in such a > way as to make it easier to integrate different git repositories as we > modularise the core in general. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1776) log4j-boot pom modules for dependency management
[
https://issues.apache.org/jira/browse/LOG4J2-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker updated LOG4J2-1776:
Description:
This is the main feature for the Log4j Boot epic (LOG4J2-1775).
{code}
groupId: org.apache.logging.log4j.boot
artifactId: log4j-boot-*
{code}
* core: just log4j-core basically
* async (for AsyncLogger; brings in LMAX disruptor)
* log4j-spi: log4j-slf4j-impl, log4j-jul, log4j-jcl, log4j-1.2-api
* slf4j-spi: slf4j-impl, jcl-over-slf4j, jul-to-slf4j (same dependency set as
spring-boot-starter-log4j2)
* logback (for log4j-to-slf4j, slf4j-spi, logback; this helps aid migration to
log4j-api and promotes it as a general use logging API)
* appender-async-conversant
* appender-async-jctools
* appender-cassandra
* appender-couchdb
* appender-jms
* appender-jpa
* appender-kafka
* appender-mongodb
* appender-smtp
* appender-zeromq
* config-json
* config-yaml
* layout-csv
* layout-jansi (for windows users and coloured log messages)
* layout-json (unless this has been ported to not require jackson anymore?)
* layout-xml
* layout-yaml
* script-groovy
I may have missed a few, but the base set of starters should at least
correspond to all optional dependencies in log4j-core or the addon modules. For
the jms, jpa, and smtp (log4j-core) appenders, we could either make add in a
default provider (e.g., ActiveMQ, Hibernate, and Sun Mail respectively) or
split those into provider-specific starters.
was:
This is the main feature for the Log4j Starter epic (LOG4J2-1775).
{code}
groupId: org.apache.logging.log4j.starter
artifactId: log4j-starter-*
{code}
* core: just log4j-core basically
* async (for AsyncLogger; brings in LMAX disruptor)
* log4j-spi: log4j-slf4j-impl, log4j-jul, log4j-jcl, log4j-1.2-api
* slf4j-spi: slf4j-impl, jcl-over-slf4j, jul-to-slf4j (same dependency set as
spring-boot-starter-log4j2)
* logback (for log4j-to-slf4j, slf4j-spi, logback; this helps aid migration to
log4j-api and promotes it as a general use logging API)
* appender-async-conversant
* appender-async-jctools
* appender-cassandra
* appender-couchdb
* appender-jms
* appender-jpa
* appender-kafka
* appender-mongodb
* appender-smtp
* appender-zeromq
* config-json
* config-yaml
* layout-csv
* layout-jansi (for windows users and coloured log messages)
* layout-json (unless this has been ported to not require jackson anymore?)
* layout-xml
* layout-yaml
* script-groovy
I may have missed a few, but the base set of starters should at least
correspond to all optional dependencies in log4j-core or the addon modules. For
the jms, jpa, and smtp (log4j-core) appenders, we could either make add in a
default provider (e.g., ActiveMQ, Hibernate, and Sun Mail respectively) or
split those into provider-specific starters.
> log4j-boot pom modules for dependency management
>
>
> Key: LOG4J2-1776
> URL: https://issues.apache.org/jira/browse/LOG4J2-1776
> Project: Log4j 2
> Issue Type: New Feature
> Components: Boot
>Reporter: Matt Sicker
>
> This is the main feature for the Log4j Boot epic (LOG4J2-1775).
> {code}
> groupId: org.apache.logging.log4j.boot
> artifactId: log4j-boot-*
> {code}
> * core: just log4j-core basically
> * async (for AsyncLogger; brings in LMAX disruptor)
> * log4j-spi: log4j-slf4j-impl, log4j-jul, log4j-jcl, log4j-1.2-api
> * slf4j-spi: slf4j-impl, jcl-over-slf4j, jul-to-slf4j (same dependency set as
> spring-boot-starter-log4j2)
> * logback (for log4j-to-slf4j, slf4j-spi, logback; this helps aid migration
> to log4j-api and promotes it as a general use logging API)
> * appender-async-conversant
> * appender-async-jctools
> * appender-cassandra
> * appender-couchdb
> * appender-jms
> * appender-jpa
> * appender-kafka
> * appender-mongodb
> * appender-smtp
> * appender-zeromq
> * config-json
> * config-yaml
> * layout-csv
> * layout-jansi (for windows users and coloured log messages)
> * layout-json (unless this has been ported to not require jackson anymore?)
> * layout-xml
> * layout-yaml
> * script-groovy
> I may have missed a few, but the base set of starters should at least
> correspond to all optional dependencies in log4j-core or the addon modules.
> For the jms, jpa, and smtp (log4j-core) appenders, we could either make add
> in a default provider (e.g., ActiveMQ, Hibernate, and Sun Mail respectively)
> or split those into provider-specific starters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1776) log4j-boot pom modules for dependency management
[
https://issues.apache.org/jira/browse/LOG4J2-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker updated LOG4J2-1776:
Summary: log4j-boot pom modules for dependency management (was:
log4j-starter pom modules for dependency management)
> log4j-boot pom modules for dependency management
>
>
> Key: LOG4J2-1776
> URL: https://issues.apache.org/jira/browse/LOG4J2-1776
> Project: Log4j 2
> Issue Type: New Feature
> Components: Boot
>Reporter: Matt Sicker
>
> This is the main feature for the Log4j Starter epic (LOG4J2-1775).
> {code}
> groupId: org.apache.logging.log4j.starter
> artifactId: log4j-starter-*
> {code}
> * core: just log4j-core basically
> * async (for AsyncLogger; brings in LMAX disruptor)
> * log4j-spi: log4j-slf4j-impl, log4j-jul, log4j-jcl, log4j-1.2-api
> * slf4j-spi: slf4j-impl, jcl-over-slf4j, jul-to-slf4j (same dependency set as
> spring-boot-starter-log4j2)
> * logback (for log4j-to-slf4j, slf4j-spi, logback; this helps aid migration
> to log4j-api and promotes it as a general use logging API)
> * appender-async-conversant
> * appender-async-jctools
> * appender-cassandra
> * appender-couchdb
> * appender-jms
> * appender-jpa
> * appender-kafka
> * appender-mongodb
> * appender-smtp
> * appender-zeromq
> * config-json
> * config-yaml
> * layout-csv
> * layout-jansi (for windows users and coloured log messages)
> * layout-json (unless this has been ported to not require jackson anymore?)
> * layout-xml
> * layout-yaml
> * script-groovy
> I may have missed a few, but the base set of starters should at least
> correspond to all optional dependencies in log4j-core or the addon modules.
> For the jms, jpa, and smtp (log4j-core) appenders, we could either make add
> in a default provider (e.g., ActiveMQ, Hibernate, and Sun Mail respectively)
> or split those into provider-specific starters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1775) Add boot pom files for dependency management
[ https://issues.apache.org/jira/browse/LOG4J2-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated LOG4J2-1775: - Summary: Add boot pom files for dependency management (was: Add starter pom files for dependency management) > Add boot pom files for dependency management > > > Key: LOG4J2-1775 > URL: https://issues.apache.org/jira/browse/LOG4J2-1775 > Project: Log4j 2 > Issue Type: Epic > Components: Boot, Documentation, Plugins >Reporter: Matt Sicker > Labels: build, documentation, features, maven, test > > Create what is essentially Log4j Boot for adding necessary dependencies to > support the various plugins while at the same time promoting the use of > log4j-api as a general purpose logging API standard. These modules would > categorise all the various natural dependency barriers for a sort of pseudo > module system that could also help in any necessary module metadata needed to > support Java 9 and OSGi, categorise integration style unit tests to help test > the starters themselves in an automated way, and organise the site in such a > way as to make it easier to integrate different git repositories as we > modularise the core in general. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1775) Add starter pom files for dependency management
[ https://issues.apache.org/jira/browse/LOG4J2-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker updated LOG4J2-1775: Epic Name: Log4j Boot (was: Log4j Starters) > Add starter pom files for dependency management > --- > > Key: LOG4J2-1775 > URL: https://issues.apache.org/jira/browse/LOG4J2-1775 > Project: Log4j 2 > Issue Type: Epic > Components: Documentation, Plugins, Starters >Reporter: Matt Sicker > Labels: build, documentation, features, maven, test > > Create what is essentially Log4j Boot for adding necessary dependencies to > support the various plugins while at the same time promoting the use of > log4j-api as a general purpose logging API standard. These modules would > categorise all the various natural dependency barriers for a sort of pseudo > module system that could also help in any necessary module metadata needed to > support Java 9 and OSGi, categorise integration style unit tests to help test > the starters themselves in an automated way, and organise the site in such a > way as to make it easier to integrate different git repositories as we > modularise the core in general. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1776) log4j-starter pom modules for dependency management
[
https://issues.apache.org/jira/browse/LOG4J2-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15813291#comment-15813291
]
Ralph Goers commented on LOG4J2-1776:
-
+1 for log4j-boot.
> log4j-starter pom modules for dependency management
> ---
>
> Key: LOG4J2-1776
> URL: https://issues.apache.org/jira/browse/LOG4J2-1776
> Project: Log4j 2
> Issue Type: New Feature
> Components: Starters
>Reporter: Matt Sicker
>
> This is the main feature for the Log4j Starter epic (LOG4J2-1775).
> {code}
> groupId: org.apache.logging.log4j.starter
> artifactId: log4j-starter-*
> {code}
> * core: just log4j-core basically
> * async (for AsyncLogger; brings in LMAX disruptor)
> * log4j-spi: log4j-slf4j-impl, log4j-jul, log4j-jcl, log4j-1.2-api
> * slf4j-spi: slf4j-impl, jcl-over-slf4j, jul-to-slf4j (same dependency set as
> spring-boot-starter-log4j2)
> * logback (for log4j-to-slf4j, slf4j-spi, logback; this helps aid migration
> to log4j-api and promotes it as a general use logging API)
> * appender-async-conversant
> * appender-async-jctools
> * appender-cassandra
> * appender-couchdb
> * appender-jms
> * appender-jpa
> * appender-kafka
> * appender-mongodb
> * appender-smtp
> * appender-zeromq
> * config-json
> * config-yaml
> * layout-csv
> * layout-jansi (for windows users and coloured log messages)
> * layout-json (unless this has been ported to not require jackson anymore?)
> * layout-xml
> * layout-yaml
> * script-groovy
> I may have missed a few, but the base set of starters should at least
> correspond to all optional dependencies in log4j-core or the addon modules.
> For the jms, jpa, and smtp (log4j-core) appenders, we could either make add
> in a default provider (e.g., ActiveMQ, Hibernate, and Sun Mail respectively)
> or split those into provider-specific starters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1776) log4j-starter pom modules for dependency management
[
https://issues.apache.org/jira/browse/LOG4J2-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15813255#comment-15813255
]
Matt Sicker commented on LOG4J2-1776:
-
For brevity's sake, "log4j-boot" is even better, plus it carries a connotation
that's pretty easy to understand in the current Java ecosystem.
> log4j-starter pom modules for dependency management
> ---
>
> Key: LOG4J2-1776
> URL: https://issues.apache.org/jira/browse/LOG4J2-1776
> Project: Log4j 2
> Issue Type: New Feature
> Components: Starters
>Reporter: Matt Sicker
>
> This is the main feature for the Log4j Starter epic (LOG4J2-1775).
> {code}
> groupId: org.apache.logging.log4j.starter
> artifactId: log4j-starter-*
> {code}
> * core: just log4j-core basically
> * async (for AsyncLogger; brings in LMAX disruptor)
> * log4j-spi: log4j-slf4j-impl, log4j-jul, log4j-jcl, log4j-1.2-api
> * slf4j-spi: slf4j-impl, jcl-over-slf4j, jul-to-slf4j (same dependency set as
> spring-boot-starter-log4j2)
> * logback (for log4j-to-slf4j, slf4j-spi, logback; this helps aid migration
> to log4j-api and promotes it as a general use logging API)
> * appender-async-conversant
> * appender-async-jctools
> * appender-cassandra
> * appender-couchdb
> * appender-jms
> * appender-jpa
> * appender-kafka
> * appender-mongodb
> * appender-smtp
> * appender-zeromq
> * config-json
> * config-yaml
> * layout-csv
> * layout-jansi (for windows users and coloured log messages)
> * layout-json (unless this has been ported to not require jackson anymore?)
> * layout-xml
> * layout-yaml
> * script-groovy
> I may have missed a few, but the base set of starters should at least
> correspond to all optional dependencies in log4j-core or the addon modules.
> For the jms, jpa, and smtp (log4j-core) appenders, we could either make add
> in a default provider (e.g., ActiveMQ, Hibernate, and Sun Mail respectively)
> or split those into provider-specific starters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1768) MDC.clear() is broken in Log4j-1_2-api = 2.4
[ https://issues.apache.org/jira/browse/LOG4J2-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15813191#comment-15813191 ] Gary Gregory commented on LOG4J2-1768: -- Please do try 2.7. Gary > MDC.clear() is broken in Log4j-1_2-api = 2.4 > > > Key: LOG4J2-1768 > URL: https://issues.apache.org/jira/browse/LOG4J2-1768 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.4 >Reporter: A >Priority: Blocker > > MDC.clear() seems to be broken in Log4j-1_2-api = 2.4 as it is not clearing > the entries in MDC. > Though, I have not tried in higher versions. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1776) log4j-starter pom modules for dependency management
[
https://issues.apache.org/jira/browse/LOG4J2-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15813100#comment-15813100
]
Gary Gregory commented on LOG4J2-1776:
--
Would the prefix "log4j-start" also be acceptable? It's a wee bit shorter.
Gary
> log4j-starter pom modules for dependency management
> ---
>
> Key: LOG4J2-1776
> URL: https://issues.apache.org/jira/browse/LOG4J2-1776
> Project: Log4j 2
> Issue Type: New Feature
> Components: Starters
>Reporter: Matt Sicker
>
> This is the main feature for the Log4j Starter epic (LOG4J2-1775).
> {code}
> groupId: org.apache.logging.log4j.starter
> artifactId: log4j-starter-*
> {code}
> * core: just log4j-core basically
> * async (for AsyncLogger; brings in LMAX disruptor)
> * log4j-spi: log4j-slf4j-impl, log4j-jul, log4j-jcl, log4j-1.2-api
> * slf4j-spi: slf4j-impl, jcl-over-slf4j, jul-to-slf4j (same dependency set as
> spring-boot-starter-log4j2)
> * logback (for log4j-to-slf4j, slf4j-spi, logback; this helps aid migration
> to log4j-api and promotes it as a general use logging API)
> * appender-async-conversant
> * appender-async-jctools
> * appender-cassandra
> * appender-couchdb
> * appender-jms
> * appender-jpa
> * appender-kafka
> * appender-mongodb
> * appender-smtp
> * appender-zeromq
> * config-json
> * config-yaml
> * layout-csv
> * layout-jansi (for windows users and coloured log messages)
> * layout-json (unless this has been ported to not require jackson anymore?)
> * layout-xml
> * layout-yaml
> * script-groovy
> I may have missed a few, but the base set of starters should at least
> correspond to all optional dependencies in log4j-core or the addon modules.
> For the jms, jpa, and smtp (log4j-core) appenders, we could either make add
> in a default provider (e.g., ActiveMQ, Hibernate, and Sun Mail respectively)
> or split those into provider-specific starters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1713) Allow for more general serialization of Log4j2 configurations
[ https://issues.apache.org/jira/browse/LOG4J2-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15812998#comment-15812998 ] Kurt Seidel commented on LOG4J2-1713: - Thanks for the reply. I think that answers my question. I am using the default ClassLoaderContextSelector, and as you point out, and as I have found, this only allows a single LoggerContext per ClassLoader. Most of our logging is done within the context of webapps, where each webapp has it's own log configuration, and the log4j2 jar files are bundled into the webapp's WEB-INF/lib. Creating a customized ContextSelector to solve my problem sounds like it would interfere with the ClassLoaderContextSelector required for proper isolated webapp logging, since this custom ContextSelector class is specified at the system level. I will likely go with using the Composite Configuration to deal with the common jars. > Allow for more general serialization of Log4j2 configurations > - > > Key: LOG4J2-1713 > URL: https://issues.apache.org/jira/browse/LOG4J2-1713 > Project: Log4j 2 > Issue Type: New Feature > Components: Configurators >Affects Versions: 2.7 >Reporter: Steve Cohen > > We want to implement the following system: > We would like to write an external program that reads several Log4j > Configuration Files, combines the configurations, and then outputs the > combined configuration to a new Log4j configuration file. This file can then > simply be dropped on a running log4j instance on a server, and cause an > update of the running configuration. > Existing APIs do not support this use case. There is nothing that supports > the serialization to XML of a loaded configuration. There is the new > ConfigurationBuilder.writeToXml() method in 2.7, but that's on > ConfigurationBuilder, not Configuration. Nor is it possible to take a > Configuration, and get a ConfigurationBuilder from it. Another way it could > work is having some sort of ConfigurationBuilder that accepted parameters of > type Logger, Appender, etc. These would enable Loggers and Appenders and > other Log4j2 objects to be copied from an existing configuration to a new one > being built. But this doesn't exist either. One would have to drill down > into each component, extract the necessary data, and add it to a builder. > In other words (H/T to Gary Gregory) > c1 = load config from XML file 1 (but do not apply the c1 configuration) > c2 = load config from XML file 2 (but do not apply the c2 configuration) > c3 = c1 + c2 (but do not apply the c3 configuration) write c3 to disk > In case you wonder, there is actually a use case behind this: > Imagine a Servlet web-app that, depending on request parameters, invokes one > of a number of possible EJBs (they could also be non-EJB POJOs, but for the > purposes of this discussion, we assume EJBs), in order to produce a response. > This is not a shopping cart but a back end system. We do NOT wish to deploy > these into a single EAR file but want separate deployment of each component, > and each component to have a separate logging configuration, deployable at > the same time as the component. Since Log4j allows only one configuration > context per class-loader, the ideal scheme would be there can only be one > configuration file. The only way to update it non-programatically is to drop > a new configuration in the correct location. In order to produce this, we > would like the separate logging configs deployed to some directory. A > separate program would read in all of these and add the loggers and appenders > to a new master configuration which would then be written out to disk and > copied to the proper location. The usual change mechanism would then load > the new configuration. The current configuration of the running system would > always match what is in this master configuration file, which is not the case > with programmatic configuration. > Without something like this, how is it possible to run multiple EJBs out of a > web-app that are separately deployable and have separately manageable logging > configurations? > One could manually of course parse the individual files on the XML level (or > JSON, YAML, whatever), combine them, and serialize the output. But since > log4j knows its own object model better than any xml parser, it makes sense > to have this capability within log4j. > And yes, I've thought of the fact that property-name, logger-name, > appender-name collisions are possible and could cause trouble. I would be > prepared to live with real res
[jira] [Commented] (LOG4J2-1640) RollingFileAppender with CronTriggeringPolicy broken?
[
https://issues.apache.org/jira/browse/LOG4J2-1640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15812875#comment-15812875
]
Matt Sicker commented on LOG4J2-1640:
-
Oh ok, got it.
> RollingFileAppender with CronTriggeringPolicy broken?
> -
>
> Key: LOG4J2-1640
> URL: https://issues.apache.org/jira/browse/LOG4J2-1640
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.7
> Environment: Mac OS X 10.11.6 running Eclipse Neon 4.6.0 with JDK
> 1.8.0_74
>Reporter: Chris McGee
> Labels: CronTriggeringPolicy, RollingFile, RollingFileAppender,
> newbie
> Fix For: 2.8
>
>
> If this isn't actually a bug, then I apologize for reporting it, but I cannot
> figure out how it could be anything else currently. Full disclosure: I am
> still a newbie.
> I've been using the log4j 2.6.x series for a while, but noticed that the
> CronTriggeringPolicy when used with RollingFileAppender causes that infinite
> rollover bug. I noted that this bug was to be fixed in 2.7, so I downloaded
> that the day it was released and replaced the 2.6 version with it. Now,
> however, without changing anything else in my code nor in my log4j2.xml file,
> I am getting exceptions regarding them.
> Here's the interesting bit: Since I was trying to see if the rollover would
> occur at midnight, I manually changed my computer's clock to just a minute
> before, logged some info, let it roll to past midnight, and let it log some
> more info. All of that info got logged into the main file; nothing rolled
> over. Here's the stacktrace from that execution:
> {noformat}
> 2016-10-10 09:40:47,521 main DEBUG Initializing configuration
> XmlConfiguration[location=/Users/apache/Dropbox/eclipse/workspace/ArtDept/bin/log4j2.xml]
> 2016-10-10 09:40:47,526 main DEBUG Installed script engines
> 2016-10-10 09:40:47,955 main DEBUG Oracle Nashorn Version: 1.8.0_74,
> Language: ECMAScript, Threading: Not Thread Safe, Compile: true, Names:
> {nashorn, Nashorn, js, JS, JavaScript, javascript, ECMAScript, ecmascript}
> 2016-10-10 09:40:48,307 main DEBUG AppleScriptEngine Version: 1.1, Language:
> AppleScript, Threading: Not Thread Safe, Compile: false, Names:
> {AppleScriptEngine, AppleScript, OSA}
> 2016-10-10 09:40:48,308 main DEBUG PluginManager 'Core' found 107 plugins
> 2016-10-10 09:40:48,308 main DEBUG PluginManager 'Level' found 0 plugins
> 2016-10-10 09:40:48,312 main DEBUG 2 starting Log4j2 ConfigurationScheduler
> threads
> 2016-10-10 09:40:48,314 main DEBUG Building Plugin[name=property,
> class=org.apache.logging.log4j.core.config.Property].
> 2016-10-10 09:40:48,323 main TRACE TypeConverterRegistry initializing.
> 2016-10-10 09:40:48,324 main DEBUG PluginManager 'TypeConverter' found 23
> plugins
> 2016-10-10 09:40:48,330 main DEBUG createProperty(name="filename",
> value="logs/artdept.log")
> 2016-10-10 09:40:48,330 main DEBUG Building Plugin[name=property,
> class=org.apache.logging.log4j.core.config.Property].
> 2016-10-10 09:40:48,331 main DEBUG createProperty(name="baseDir",
> value="/Volumes/ArtDept/ArtDept/Scripts/sky-artdept/logs")
> 2016-10-10 09:40:48,331 main DEBUG Building Plugin[name=properties,
> class=org.apache.logging.log4j.core.config.PropertiesPlugin].
> 2016-10-10 09:40:48,334 main DEBUG
> configureSubstitutor(={filename=logs/artdept.log,
> baseDir=/Volumes/ArtDept/ArtDept/Scripts/sky-artdept/logs},
> Configuration(/Users/apache/Dropbox/eclipse/workspace/ArtDept/bin/log4j2.xml))
> 2016-10-10 09:40:48,335 main DEBUG PluginManager 'Lookup' found 13 plugins
> 2016-10-10 09:40:48,335 main DEBUG Building Plugin[name=layout,
> class=org.apache.logging.log4j.core.layout.PatternLayout].
> 2016-10-10 09:40:48,341 main DEBUG
> PatternLayout$Builder(pattern="%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} -
> %msg%n", PatternSelector=null,
> Configuration(/Users/apache/Dropbox/eclipse/workspace/ArtDept/bin/log4j2.xml),
> Replace=null, charset="null", alwaysWriteExceptions="null",
> noConsoleNoAnsi="null", header="null", footer="null")
> 2016-10-10 09:40:48,341 main DEBUG PluginManager 'Converter' found 41 plugins
> 2016-10-10 09:40:48,342 main DEBUG Building Plugin[name=appender,
> class=org.apache.logging.log4j.core.appender.ConsoleAppender].
> 2016-10-10 09:40:48,347 main DEBUG
> ConsoleAppender$Builder(ta
