Re: org.apache.logging.log4j.core.config.Configurator.initialize(String, String)

[Remko Popma]

I thought Gary needed a way to detect that the specified location didn't work. 
But perhaps a warning message is sufficient. 

Sent from my iPhone

> On Apr 12, 2017, at 10:05, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> 
> I'd prefer an error message but then have it continue with the current 
> behavior.
> 
> Sent from my iPhone
> 
>> On Apr 11, 2017, at 5:47 PM, Remko Popma <remko.po...@gmail.com> wrote:
>> 
>> I can see both sides of the argument. 
>> 
>> Rather than changing the semantics of the existing method, what about adding 
>> a method `Configurator.initializeStrict(String, String)` which fails if the 
>> specified file doesn't exist? Not sure what the best way to fail is: return 
>> null or throw exception...
>> 
>> Sent from my iPhone
>> 
>>> On Apr 12, 2017, at 9:13, Gary Gregory <garydgreg...@gmail.com> wrote:
>>> 
>>> Hi All:
>>> 
>>> Using 2.8.2, I call 
>>> org.apache.logging.log4j.core.config.Configurator.initialize(String, 
>>> String) with a non-exiting file location.
>>> 
>>> The method does not return null because it found another log4j2.xml file on 
>>> my classpath. So I get a LoggerContext but not what I expect...
>>> 
>>> That does not sound right to me, it should return null, and then I can look 
>>> in the status logger to see what went wrong (if I happen to have it set to 
>>> DEBUG in the log4j2.xml file it did find.)
>>> 
>>> Thoughts?
>>> 
>>> Gary
>>> 
>>> -- 
>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
>>> Java Persistence with Hibernate, Second Edition 
>>> JUnit in Action, Second Edition 
>>> Spring Batch in Action 
>>> Blog: http://garygregory.wordpress.com 
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory

Re: org.apache.logging.log4j.core.config.Configurator.initialize(String, String)

[Remko Popma]

I can see both sides of the argument. 

Rather than changing the semantics of the existing method, what about adding a 
method `Configurator.initializeStrict(String, String)` which fails if the 
specified file doesn't exist? Not sure what the best way to fail is: return 
null or throw exception...

Sent from my iPhone

> On Apr 12, 2017, at 9:13, Gary Gregory  wrote:
> 
> Hi All:
> 
> Using 2.8.2, I call 
> org.apache.logging.log4j.core.config.Configurator.initialize(String, String) 
> with a non-exiting file location.
> 
> The method does not return null because it found another log4j2.xml file on 
> my classpath. So I get a LoggerContext but not what I expect...
> 
> That does not sound right to me, it should return null, and then I can look 
> in the status logger to see what went wrong (if I happen to have it set to 
> DEBUG in the log4j2.xml file it did find.)
> 
> Thoughts?
> 
> Gary
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
> Java Persistence with Hibernate, Second Edition 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com 
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

Re: Configuration file discovery

[Remko Popma]

A better error message sounds like a good idea.
If you make a Jira ticket for this, please make it part of the "ergonomics"
epic: https://issues.apache.org/jira/browse/LOG4J2-1811

On Tue, Apr 11, 2017 at 9:19 PM, Mikael Ståldal 
wrote:

> Some configuration file formats (JSON, YAML) require additional runtime
> dependencies. If a such dependency is missing, configuration file location
> will stop and not try other configuration files with lower priority.
>
> E.g. if I have both log4j2.json and log4j2.xml in classpath, but not
> Jackson (required for JSON config), then no configuration file will be
> loaded and I get this error:
>
> ERROR StatusLogger No log4j2 configuration file found. Using default
> configuration: logging only errors to the console. Set system property
> 'org.apache.logging.log4j.simplelog.StatusLogger.level' to TRACE to show
> Log4j2 internal initialization logging.
>
> When enabling status logging TRACE, I get a lot of logging (see below) and
> it's not so easy to figure out what went wrong.
>
> Would it make sense to emit a more explicit error message on WARN level
> when this occurs?
>
>
> DEBUG StatusLogger Loaded Provider Provider[priority=10,
> className=org.apache.logging.log4j.core.impl.Log4jContextFactory,
> url=jar:file:/home/mikes/.m2/repository/org/apache/logging/
> log4j/log4j-core/2.8.2/log4j-core-2.8.2.jar!/META-INF/log4j-provider.properties,
> classLoader=sun.misc.Launcher$AppClassLoader@18b4aac2]
> DEBUG StatusLogger Using ShutdownCallbackRegistry class
> org.apache.logging.log4j.core.util.DefaultShutdownCallbackRegistry
> DEBUG StatusLogger Not in a ServletContext environment, thus not loading
> WebLookup plugin.
> DEBUG StatusLogger AsyncLogger.ThreadNameStrategy=CACHED
> TRACE StatusLogger Using default SystemClock for timestamps.
> DEBUG StatusLogger Not in a ServletContext environment, thus not loading
> WebLookup plugin.
> DEBUG StatusLogger Took 0.096889 seconds to load 198 plugins from
> sun.misc.Launcher$AppClassLoader@18b4aac2
> DEBUG StatusLogger PluginManager 'Converter' found 41 plugins
> DEBUG StatusLogger Starting OutputStreamManager SYSTEM_OUT.false.false-1
> DEBUG StatusLogger Starting LoggerContext[name=18b4aac2,
> org.apache.logging.log4j.core.LoggerContext@6d8a00e3]...
> DEBUG StatusLogger Reconfiguration started for context[name=18b4aac2] at
> URI null (org.apache.logging.log4j.core.LoggerContext@6d8a00e3) with
> optional ClassLoader: null
> DEBUG StatusLogger Not in a ServletContext environment, thus not loading
> WebLookup plugin.
> DEBUG StatusLogger PluginManager 'ConfigurationFactory' found 4 plugins
> DEBUG StatusLogger Not in a ServletContext environment, thus not loading
> WebLookup plugin.
> DEBUG StatusLogger Not in a ServletContext environment, thus not loading
> WebLookup plugin.
> DEBUG StatusLogger Missing dependencies for Yaml support
> DEBUG StatusLogger Not in a ServletContext environment, thus not loading
> WebLookup plugin.
> DEBUG StatusLogger Missing dependencies for Json support
> DEBUG StatusLogger Not in a ServletContext environment, thus not loading
> WebLookup plugin.
> DEBUG StatusLogger Using configurationFactory
> org.apache.logging.log4j.core.config.ConfigurationFactory$Factory@3a82f6ef
> TRACE StatusLogger Trying to find [log4j2-test18b4aac2.properties] using
> context class loader sun.misc.Launcher$AppClassLoader@18b4aac2.
> TRACE StatusLogger Trying to find [log4j2-test18b4aac2.properties] using
> sun.misc.Launcher$AppClassLoader@18b4aac2 class loader.
> TRACE StatusLogger Trying to find [log4j2-test18b4aac2.properties] using
> sun.misc.Launcher$AppClassLoader@18b4aac2 class loader.
> TRACE StatusLogger Trying to find [log4j2-test18b4aac2.properties] using
> ClassLoader.getSystemResource().
> TRACE StatusLogger Trying to find [log4j2-test18b4aac2.yml] using context
> class loader sun.misc.Launcher$AppClassLoader@18b4aac2.
> TRACE StatusLogger Trying to find [log4j2-test18b4aac2.yml] using
> sun.misc.Launcher$AppClassLoader@18b4aac2 class loader.
> TRACE StatusLogger Trying to find [log4j2-test18b4aac2.yml] using
> sun.misc.Launcher$AppClassLoader@18b4aac2 class loader.
> TRACE StatusLogger Trying to find [log4j2-test18b4aac2.yml] using
> ClassLoader.getSystemResource().
> TRACE StatusLogger Trying to find [log4j2-test18b4aac2.yaml] using context
> class loader sun.misc.Launcher$AppClassLoader@18b4aac2.
> TRACE StatusLogger Trying to find [log4j2-test18b4aac2.yaml] using
> sun.misc.Launcher$AppClassLoader@18b4aac2 class loader.
> TRACE StatusLogger Trying to find [log4j2-test18b4aac2.yaml] using
> sun.misc.Launcher$AppClassLoader@18b4aac2 class loader.
> TRACE StatusLogger Trying to find [log4j2-test18b4aac2.yaml] using
> ClassLoader.getSystemResource().
> TRACE StatusLogger Trying to find [log4j2-test18b4aac2.json] using context
> class loader sun.misc.Launcher$AppClassLoader@18b4aac2.
> TRACE StatusLogger Trying to find [log4j2-test18b4aac2.json] using
> 

Re: [14/14] logging-log4j2 git commit: Update BOM

[Remko Popma]

Thanks!!

Sent from my iPhone

> On Apr 11, 2017, at 18:09, Mikael Ståldal <mikael.stal...@magine.com> wrote:
> 
> OK, moved now.
> 
>> On Mon, Apr 10, 2017 at 6:15 PM, Ralph Goers <ralph.go...@dslextreme.com> 
>> wrote:
>> Yes, that is the repo.  Initially, all it needs is a parent pom that 
>> references the module you created. We can move other stuff in later. It will 
>> need a web site of some kind but we can also worry about that later.
>> 
>> Ralph
>> 
>>> On Apr 10, 2017, at 9:11 AM, Mikael Ståldal <mikael.stal...@magine.com> 
>>> wrote:
>>> 
>>> Is it this repo? git://git.apache.org/logging-log4j-tools.git
>>> 
>>> It is currently empty (except two text files). I don't feel confident to do 
>>> the initial setup of the repository.
>>> 
>>>> On Mon, Apr 10, 2017 at 5:48 PM, Ralph Goers <ralph.go...@dslextreme.com> 
>>>> wrote:
>>>> I created a new git repo for log4j2-tools.  We should not create any more 
>>>> modules if we can avoid it.
>>>> 
>>>> Ralph
>>>> 
>>>>> On Apr 10, 2017, at 7:28 AM, Remko Popma <remko.po...@gmail.com> wrote:
>>>>> 
>>>>> I guess this is a matter of preference but we already have a lot of 
>>>>> modules.
>>>>> Having one for all standalone applications makes it easier for our users 
>>>>> to find things.
>>>>> 
>>>>>> On Mon, Apr 10, 2017 at 11:24 PM, Mikael Ståldal 
>>>>>> <mikael.stal...@magine.com> wrote:
>>>>>> Wouldn't it be better to have one for server and another for the other 
>>>>>> tools?
>>>>>> 
>>>>>>> On Mon, Apr 10, 2017 at 4:23 PM, Remko Popma <remko.po...@gmail.com> 
>>>>>>> wrote:
>>>>>>> I thought we were going to name this module log4j-tools instead of 
>>>>>>> log4j-server, so it can host all our standalone apps?
>>>>>>> 
>>>>>>>> On Mon, Apr 10, 2017 at 11:11 PM, <mi...@apache.org> wrote:
>>>>>>>> Update BOM
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
>>>>>>>> Commit: 
>>>>>>>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/fea17ad6
>>>>>>>> Tree: 
>>>>>>>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/fea17ad6
>>>>>>>> Diff: 
>>>>>>>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/fea17ad6
>>>>>>>> 
>>>>>>>> Branch: refs/heads/master
>>>>>>>> Commit: fea17ad6bdc47825ec5b58b9df9e031936182d79
>>>>>>>> Parents: 1051081
>>>>>>>> Author: Mikael Ståldal <mikael.stal...@magine.com>
>>>>>>>> Authored: Mon Apr 10 16:11:24 2017 +0200
>>>>>>>> Committer: Mikael Ståldal <mikael.stal...@magine.com>
>>>>>>>> Committed: Mon Apr 10 16:11:24 2017 +0200
>>>>>>>> 
>>>>>>>> --
>>>>>>>>  log4j-bom/pom.xml | 6 ++
>>>>>>>>  1 file changed, 6 insertions(+)
>>>>>>>> --
>>>>>>>> 
>>>>>>>> 
>>>>>>>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/fea17ad6/log4j-bom/pom.xml
>>>>>>>> --
>>>>>>>> diff --git a/log4j-bom/pom.xml b/log4j-bom/pom.xml
>>>>>>>> index 920f6a0..382f16e 100644
>>>>>>>> --- a/log4j-bom/pom.xml
>>>>>>>> +++ b/log4j-bom/pom.xml
>>>>>>>> @@ -96,6 +96,12 @@
>>>>>>>>  log4j-iostreams
>>>>>>>>  ${project.version}
>>>>>>>>
>>>>>>>> +  
>>>>>>>> +  
>>>>>>>> +org.apache.logging.log4j
>>>>>>>> +log4j-server
>>>>>>>> +${project.version}
>>>>>>>> + 

Re: [14/14] logging-log4j2 git commit: Update BOM

[Remko Popma]

I guess this is a matter of preference but we already have a lot of modules.
Having one for all standalone applications makes it easier for our users to
find things.

On Mon, Apr 10, 2017 at 11:24 PM, Mikael Ståldal <mikael.stal...@magine.com>
wrote:

> Wouldn't it be better to have one for server and another for the other
> tools?
>
> On Mon, Apr 10, 2017 at 4:23 PM, Remko Popma <remko.po...@gmail.com>
> wrote:
>
>> I thought we were going to name this module log4j-tools instead of
>> log4j-server, so it can host all our standalone apps?
>>
>> On Mon, Apr 10, 2017 at 11:11 PM, <mi...@apache.org> wrote:
>>
>>> Update BOM
>>>
>>>
>>> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
>>> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit
>>> /fea17ad6
>>> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/f
>>> ea17ad6
>>> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/f
>>> ea17ad6
>>>
>>> Branch: refs/heads/master
>>> Commit: fea17ad6bdc47825ec5b58b9df9e031936182d79
>>> Parents: 1051081
>>> Author: Mikael Ståldal <mikael.stal...@magine.com>
>>> Authored: Mon Apr 10 16:11:24 2017 +0200
>>> Committer: Mikael Ståldal <mikael.stal...@magine.com>
>>> Committed: Mon Apr 10 16:11:24 2017 +0200
>>>
>>> --
>>>  log4j-bom/pom.xml | 6 ++
>>>  1 file changed, 6 insertions(+)
>>> --
>>>
>>>
>>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/f
>>> ea17ad6/log4j-bom/pom.xml
>>> --
>>> diff --git a/log4j-bom/pom.xml b/log4j-bom/pom.xml
>>> index 920f6a0..382f16e 100644
>>> --- a/log4j-bom/pom.xml
>>> +++ b/log4j-bom/pom.xml
>>> @@ -96,6 +96,12 @@
>>>  log4j-iostreams
>>>  ${project.version}
>>>
>>> +  
>>> +  
>>> +org.apache.logging.log4j
>>> +log4j-server
>>> +${project.version}
>>> +  
>>>
>>>
>>>  org.apache.logging.log4j
>>>
>>>
>>
>
>
> --
> [image: MagineTV]
>
> *Mikael Ståldal*
> Senior software developer
>
> *Magine TV*
> mikael.stal...@magine.com
> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com
>
> Privileged and/or Confidential Information may be contained in this
> message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not
> copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply
> email.
>

Re: [14/14] logging-log4j2 git commit: Update BOM

[Remko Popma]

I thought we were going to name this module log4j-tools instead of
log4j-server, so it can host all our standalone apps?

On Mon, Apr 10, 2017 at 11:11 PM,  wrote:

> Update BOM
>
>
> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/
> commit/fea17ad6
> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/fea17ad6
> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/fea17ad6
>
> Branch: refs/heads/master
> Commit: fea17ad6bdc47825ec5b58b9df9e031936182d79
> Parents: 1051081
> Author: Mikael Ståldal 
> Authored: Mon Apr 10 16:11:24 2017 +0200
> Committer: Mikael Ståldal 
> Committed: Mon Apr 10 16:11:24 2017 +0200
>
> --
>  log4j-bom/pom.xml | 6 ++
>  1 file changed, 6 insertions(+)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/
> fea17ad6/log4j-bom/pom.xml
> --
> diff --git a/log4j-bom/pom.xml b/log4j-bom/pom.xml
> index 920f6a0..382f16e 100644
> --- a/log4j-bom/pom.xml
> +++ b/log4j-bom/pom.xml
> @@ -96,6 +96,12 @@
>  log4j-iostreams
>  ${project.version}
>
> +  
> +  
> +org.apache.logging.log4j
> +log4j-server
> +${project.version}
> +  
>
>
>  org.apache.logging.log4j
>
>

[jira] [Commented] (LOG4J2-1873) Implement UTF-8 encoding that doesn't use CharsetEncoder

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15962607#comment-15962607
 ] 

Remko Popma commented on LOG4J2-1873:
-

I'm open to ideas. 
We did something similar with core.util.StringEncoder for 8859-1 but that's not 
used on the garbage-free path. Would this be an enhancement or replacement of 
StringBuilderEncoder or something else entirely?


> Implement UTF-8 encoding that doesn't use CharsetEncoder
> 
>
> Key: LOG4J2-1873
> URL: https://issues.apache.org/jira/browse/LOG4J2-1873
> Project: Log4j 2
>  Issue Type: Improvement
>Reporter: Roman Leventov
>
> CharsetEncoder accepts only CharBuffers, and for the sake of being entirely 
> garbage-free we don't want to use CharBuffer.wrap(stringBuilder), when 
> encoding an event.
> That forces us to make additional data copy from StringBuilder to a 
> thread-local CharBuffer.
> This could be avoided by implementing UTF-8 encoding logic in log4j-core 
> itself, and not using CharsetEncoder.
> This issue is specifically about UTF-8 because it is used predominantly and 
> it's relatively easy to implement. There are also likely some open-source 
> Apache 2-compatible implementations in Java out there already that we could 
> just copy and adapt.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: [ANN] Log4j 2.8.2 released

[Remko Popma]

Blogged: https://blogs.apache.org/logging/entry/log4j-2-8-2-released

On Sun, Apr 9, 2017 at 1:53 AM, Matt Sicker  wrote:

> The Apache Log4j 2 team is pleased to announce the Log4j 2.8.2 release!
>
> Apache Log4j is a well known framework for logging application behavior.
> Log4j 2 is an upgrade to Log4j that provides significant improvements over
> its predecessor, Log4j 1.x, and provides many other modern features such as
> support for Markers, lambda expressions for lazy logging, property
> substitution using Lookups, multiple patterns on a PatternLayout and
> asynchronous Loggers. Another notable Log4j 2 feature is the ability to be
> "garbage-free" (avoid allocating temporary objects) while logging. In
> addition, Log4j 2 will not lose events while reconfiguring.
>
> This release primarily contains bugfixes and minor enhancements. More
> details on the new features and fixes are itemized below.
>
> Note that subsequent to the 2.6 release a minor source incompatibility was
> found due to the addition of new methods to the Logger interface. If you
> have code that does:
>
> logger.error(null, “This is the log message”, throwable);
>
> or similar with any log level you will get a compiler error saying the
> reference is ambiguous. To correct this either do:
>
> logger.error(“This is the log message”, throwable);
>
> or
>
> logger.error((Marker) null, “This is the log message”, throwable);
>
> The Log4j 2.8.2 API, as well as many core components, maintains binary
> compatibility with previous releases.
>
> GA
> Release 2.8.2
>
> Changes in this version include:
>
> New
> Features
>
>- LOG4J2-1863 : Add
>support for filtering input in TcpSocketServer and UdpSocketServer.
>- LOG4J2-1848 : Add
>JSON encoding support to EncodingPatternConverter %encode{}.
>- LOG4J2-1843 : Add
>support for appending common suffix to each line of throwable stack trace.
>Thanks to Zilong Song.
>- LOG4J2-1838 : Add
>support for appending common suffix to each line of extended and root
>throwable stack trace. Thanks to Zilong Song.
>
>
> Fixed
> Bugs
>
>- LOG4J2-1861 : Fix
>JavaDoc on org.apache.logging.log4j.ThreadContext about inheritance.
>- LOG4J2-1862 : Fix
>JavaDoc about @Order and OrderComparator ordering. Thanks to wangyuntao.
>- LOG4J2-1849 :
>Fixed daylight savings time issue with FixedDateFormat.
>- LOG4J2-1850 : Fix
>CassandraRule and unit tests on Windows. Thanks to Ludovic Hochet.
>- LOG4J2-1840 : Fix
>typo in %replace converter documentation. Thanks to Pradeep Balasundaram.
>- LOG4J2-1846 :
>Handle when LogEvent.getLoggerName() returns null in
>LoggerNameLevelRewritePolicy.
>- LOG4J2-1845 :
>Handle when LogEvent.getLoggerName() returns null in KafkaAppender.
>- LOG4J2-1853 : The
>default value of RandomAccessFileAppender.Builder append field is
>wrong. Thanks to wangyuntao.
>- LOG4J2-1835 : Fix
>documentation about the licensing for JeroMQ.
>- LOG4J2-1836 :
>Update the API version to 2.6.0.
>- LOG4J2-1831 :
>NullPointerException in HtmlLayout. Thanks to Edward Serebrinskiy.
>- LOG4J2-1820 :
>Log4j 2.8 can lose exceptions when a security manager is present. Thanks to
>Jason Tedor.
>
>
> 
> Changes
>
>- LOG4J2-1827 :
>Move integration tests to their own module to speed up build.
>- LOG4J2-1856 :
>Update Jackson from 2.8.6 to 2.8.7.
>
> --
>
> Apache Log4j 2.8.2 requires a minimum of Java 7 to build and run. Log4j
> 2.3 was the last release that supported Java 6.
>
> Basic compatibility with Log4j 1.x is provided through the log4j-1.2-api
> component, however it does not implement 

Re: Yet another logging facade

[Remko Popma]

Good find. I noticed that the document points to Apache Sling and says "uses 
the most common parts today used for logging: SLF4J for clients and logback for 
processing."  Seems like Sling decided that in 2013 and never looked back. 
Which is fine, but I believe Log4j2 has changed the landscape the last 4 years. 

Sent from my iPhone

> On Apr 7, 2017, at 6:08, Matt Sicker  wrote:
> 
> OSGi is looking at updating their logging API:
> 
> https://github.com/osgi/design/blob/master/rfcs/rfc0219/rfc-0219-LogService-Update.pdf
> 
> We might want to provide feedback.
> 
> -- 
> Matt Sicker 

Re: MessageLayout

[Remko Popma]

So, exceptions are swallowed and no newlines are rendered? Interesting. 
What's the use case?

Sent from my iPhone

> On Apr 4, 2017, at 7:30, Gary Gregory  wrote:
> 
> Hi All,
> 
> I am considering a new layout called "MessageLayout" which would be 
> synonymous with:. Thoughts? 
> 
> Gary
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
> Java Persistence with Hibernate, Second Edition 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com 
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

[jira] [Commented] (LOG4J2-1857) Listing all Loggers via JMX

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942847#comment-15942847
 ] 

Remko Popma commented on LOG4J2-1857:
-

Yes, good idea. I am swamped with other work. Can you provide a patch or pull 
request, ideally with unit tests?

I think the natural place to put this functionality is in 
{{org.apache.logging.log4j.jmx.gui.Client}} class in the {{log4j-jmx-gui}} 
module, similar to the existing method 
[{{getStatusLoggerAdmin}}|https://github.com/apache/logging-log4j2/blob/master/log4j-jmx-gui/src/main/java/org/apache/logging/log4j/jmx/gui/Client.java#L137].

> Listing all Loggers via JMX
> ---
>
> Key: LOG4J2-1857
> URL: https://issues.apache.org/jira/browse/LOG4J2-1857
> Project: Log4j 2
>  Issue Type: Question
>  Components: JMX
>Affects Versions: 2.6.1
>Reporter: Izek Greenfield
>
> How can I list all loggers via JMX / jolokia?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
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-1857) Listing all Loggers via JMX

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942847#comment-15942847
 ] 

Remko Popma edited comment on LOG4J2-1857 at 3/27/17 8:41 AM:
--

Yes, good idea. I am swamped with other work. Can you provide a patch or pull 
request, ideally with unit tests?

I think the natural place to put this functionality is in 
{{org.apache.logging.log4j.jmx.gui.Client}} class in the {{log4j-jmx-gui}} 
module, similar to the existing method [{{getStatusLoggerAdmin(String 
contextName)}}|https://github.com/apache/logging-log4j2/blob/master/log4j-jmx-gui/src/main/java/org/apache/logging/log4j/jmx/gui/Client.java#L137].


was (Author: rem...@yahoo.com):
Yes, good idea. I am swamped with other work. Can you provide a patch or pull 
request, ideally with unit tests?

I think the natural place to put this functionality is in 
{{org.apache.logging.log4j.jmx.gui.Client}} class in the {{log4j-jmx-gui}} 
module, similar to the existing method 
[{{getStatusLoggerAdmin}}|https://github.com/apache/logging-log4j2/blob/master/log4j-jmx-gui/src/main/java/org/apache/logging/log4j/jmx/gui/Client.java#L137].

> Listing all Loggers via JMX
> ---
>
> Key: LOG4J2-1857
> URL: https://issues.apache.org/jira/browse/LOG4J2-1857
> Project: Log4j 2
>  Issue Type: Question
>  Components: JMX
>Affects Versions: 2.6.1
>Reporter: Izek Greenfield
>
> How can I list all loggers via JMX / jolokia?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
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-1857) Listing all Loggers via JMX

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942265#comment-15942265
 ] 

Remko Popma edited comment on LOG4J2-1857 at 3/26/17 12:57 PM:
---

Does this work for you?

{code}
String serviceUrl = args[0]; // "host:port"
if (!serviceUrl.startsWith("service:jmx")) {
serviceUrl = "service:jmx:rmi:///jndi/rmi://" + args[0] + "/jmxrmi";
}
JMXServiceURL url = new JMXServiceURL(serviceUrl);
Properties props = System.getProperties();
Map<String, String> paramMap = new HashMap<>(props.size());
for (String key : props.stringPropertyNames()) {
paramMap.put(key, props.getProperty(key));
}
JMXConnector connector = JMXConnectorFactory.connect(url, paramMap);
Client client = new Client(connector);
MBeanServerConnection mbs = client.getConnection();

for (LoggerContextAdminMBean ctx : client.getLoggerContextAdmins()) {
String search = String.format(LoggerConfigAdminMBean.PATTERN, 
ctx.getName(), "*");
ObjectName pattern = new ObjectName(search);
Set found = mbs.queryNames(pattern, null);
for (ObjectName objectName : found) {
LoggerConfigAdminMBean proxy = JMX.newMBeanProxy(connection, //
objectName, //
LoggerConfigAdminMBean.class, true); // notificationBroadcaster

// TODO your logic here 
}
}
{code}


was (Author: rem...@yahoo.com):
Does this work for you?

{code}
String serviceUrl = args[0]; // "host:port"
if (!serviceUrl.startsWith("service:jmx")) {
serviceUrl = "service:jmx:rmi:///jndi/rmi://" + args[0] + "/jmxrmi";
}
final JMXServiceURL url = new JMXServiceURL(serviceUrl);
final Properties props = System.getProperties();
final Map<String, String> paramMap = new HashMap<>(props.size());
for (final String key : props.stringPropertyNames()) {
paramMap.put(key, props.getProperty(key));
}
final JMXConnector connector = JMXConnectorFactory.connect(url, 
paramMap);
final Client client = new Client(connector);
MBeanServerConnection mbs = client.getConnection();

for (final LoggerContextAdminMBean ctx : 
client.getLoggerContextAdmins()) {
String search = String.format(LoggerConfigAdminMBean.PATTERN, 
ctx.getName(), "*");
ObjectName pattern = new ObjectName(search);
Set found = mbs.queryNames(pattern, null);
for (final ObjectName objectName : found) {
final LoggerConfigAdminMBean proxy = 
JMX.newMBeanProxy(connection, //
objectName, //
LoggerConfigAdminMBean.class, true); // notificationBroadcaster

// TODO your logic here 
}
}

{code}

> Listing all Loggers via JMX
> ---
>
> Key: LOG4J2-1857
> URL: https://issues.apache.org/jira/browse/LOG4J2-1857
> Project: Log4j 2
>  Issue Type: Question
>  Components: JMX
>Affects Versions: 2.6.1
>Reporter: Izek Greenfield
>
> How can I list all loggers via JMX / jolokia?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1857) Listing all Loggers via JMX

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma updated LOG4J2-1857:

Description: How can I list all loggers via JMX / jolokia?  (was: Who I can 
list all logger via JMX / jolokia?)
Summary: Listing all Loggers via JMX  (was: List all Loger via JMx)

> Listing all Loggers via JMX
> ---
>
> Key: LOG4J2-1857
> URL: https://issues.apache.org/jira/browse/LOG4J2-1857
> Project: Log4j 2
>  Issue Type: Question
>  Components: JMX
>Affects Versions: 2.6.1
>Reporter: Izek Greenfield
>
> How can I list all loggers via JMX / jolokia?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1857) List all Loger via JMx

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942265#comment-15942265
 ] 

Remko Popma commented on LOG4J2-1857:
-

Does this work for you?

{code}
String serviceUrl = args[0]; // "host:port"
if (!serviceUrl.startsWith("service:jmx")) {
serviceUrl = "service:jmx:rmi:///jndi/rmi://" + args[0] + "/jmxrmi";
}
final JMXServiceURL url = new JMXServiceURL(serviceUrl);
final Properties props = System.getProperties();
final Map<String, String> paramMap = new HashMap<>(props.size());
for (final String key : props.stringPropertyNames()) {
paramMap.put(key, props.getProperty(key));
}
final JMXConnector connector = JMXConnectorFactory.connect(url, 
paramMap);
final Client client = new Client(connector);
MBeanServerConnection mbs = client.getConnection();

for (final LoggerContextAdminMBean ctx : 
client.getLoggerContextAdmins()) {
String search = String.format(LoggerConfigAdminMBean.PATTERN, 
ctx.getName(), "*");
ObjectName pattern = new ObjectName(search);
Set found = mbs.queryNames(pattern, null);
for (final ObjectName objectName : found) {
final LoggerConfigAdminMBean proxy = 
JMX.newMBeanProxy(connection, //
objectName, //
LoggerConfigAdminMBean.class, true); // notificationBroadcaster

// TODO your logic here 
}
}

{code}

> List all Loger via JMx
> --
>
> Key: LOG4J2-1857
> URL: https://issues.apache.org/jira/browse/LOG4J2-1857
> Project: Log4j 2
>  Issue Type: Question
>  Components: JMX
>Affects Versions: 2.6.1
>Reporter: Izek Greenfield
>
> Who I can list all logger via JMX / jolokia?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Closed] (LOG4J2-1370) Log4j2 cannot get env. variable

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma closed LOG4J2-1370.
---
Resolution: Resolved

User reported that a they could not reproduce the issue any more after 
upgrading Windows. 

> Log4j2 cannot get env. variable
> ---
>
> Key: LOG4J2-1370
> URL: https://issues.apache.org/jira/browse/LOG4J2-1370
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API
>Affects Versions: 2.5
>Reporter: Some dude
>Priority: Critical
>
> Please check issue here
> http://stackoverflow.com/questions/36693517/log4j2-cannot-get-env-variable



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Resolved] (LOG4J2-1849) Broken FixedDateFormat tests when daylight saving time starts

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma resolved LOG4J2-1849.
-
   Resolution: Fixed
Fix Version/s: 2.8.2

Fixed in commit c822338.

Please verify and close.

> Broken FixedDateFormat tests when daylight saving time starts
> -
>
> Key: LOG4J2-1849
> URL: https://issues.apache.org/jira/browse/LOG4J2-1849
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.8.1
>Reporter: Matt Sicker
>Assignee: Remko Popma
> Fix For: 2.8.2
>
>
> Today we started daylight saving time in the US, and the following tests 
> failed:
> {noformat}
> Failed tests:
>   FixedDateFormatTest.testFormatLong:162 ABSOLUTE(HH:mm:ss,SSS)/1489305608119 
> expected:<0[3]:00:08,119> but was:<0[2]:00:08,119>
>   FixedDateFormatTest.testFormatLongCharArrayInt:196 
> ABSOLUTE(HH:mm:ss,SSS)/1489305607930 expected:<0[3]:00:07,930> but 
> was:<0[2]:00:07,930>
>   FixedDateFormatTest.testFormatLongCharArrayInt_goingBackInTime:214 
> ABSOLUTE(HH:mm:ss,SSS)/1489381194091 expected:<2[3]:59:54,091> but 
> was:<2[2]:59:54,091>
>   FixedDateFormatTest.testFormatLong_goingBackInTime:178 
> ABSOLUTE(HH:mm:ss,SSS)/1489381194072 expected:<2[3]:59:54,072> but 
> was:<2[2]:59:54,072>
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: Java 9 support

[Remko Popma]

Sorry, no idea. A separate repo sounds cleaner, but I haven't spent as much
time as you thinking about this, so perhaps I'm wrong. It would be nice to
not require Java 9 unless you want to compile the StackWalker stuff...


On Thu, Mar 16, 2017 at 12:07 AM, Ralph Goers 
wrote:

> I know how to implement the StackWalker code but I don’t quite know how to
> get it into the build. The main build needs to keep using Java 7 but of
> course the StackWalker stuff needs to be compiled with Java 9. Technically,
> I know how I could do that except I have no idea how it would work in
> Jenkins. It would also mean that everyone would be required to have Java 9
> installed in order to do the build.
>
> An alternate approach would be to have the Java 9 specific classes in a
> separate repo with its own build. It would have to be “released” but we
> really wouldn’t need or want to release those jars to Maven Central as they
> would only be needed in the Log4j build - the classes would be copied into
> the Log4j jar.
>
> If any of you know we can set a Jenkins variable to point to the latest
> Java 9 version that could solve the problem.
>
> Ralph
>
> -
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>
>

[jira] [Updated] (LOG4J2-1841) Problems with consequences after LOG4J2-248

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma updated LOG4J2-1841:

Fix Version/s: 2.8.2

Setting fix version to prevent this issue from dropping below the horizon.

> Problems with consequences after LOG4J2-248
> ---
>
> Key: LOG4J2-1841
> URL: https://issues.apache.org/jira/browse/LOG4J2-1841
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Boot
>Affects Versions: 2.8
> Environment: Linux, Tomcat, WebApps
>Reporter: Seweryn Habdank-Wojewodzki
> Fix For: 2.8.2
>
>
> Situation till Log4j v. 2.5 (including it):
> 1. One instance of embedded Jetty (programatically started) WITHOUT 
> definition of the log4j.configurationFile variable.
> 2. WAR deployed on within this concrete instance of the embedded Jetty.
> 3. WAR internally contains own log4j2.xml file. So every Log4j instance, 
> which is global for the WebApp, but local for the Jetty, will search and use 
> configuration in own class path.
> Works in the way that every Web-App got own Log4j configuration and will 
> operate according to own definitions (appenders, layouts, loggers).
> In the Log4j v. 2.6 and later in the same setup we are observing the 
> following:
> Log4j in the applications are reporting problem that config file (log4j2.xml) 
> is not visible. Thus we got message, that Log4j will switch to backup mode 
> which will write only ERRORs in the console.
> We debuged that issue and found that change made in:
> https://issues.apache.org/jira/browse/LOG4J2-248
> seems to be the main reason.
> We cannot asses if this change was made only with respect to some PMD warning 
> or it has as well some design considerations in background.
> The consequence is that Web Server instance shall define 
> log4j.configurationFile variable, but also it means ALL WebApps within 
> Application Container will use one single configuration, what makes 
> definitely problem, as all WebApps providers must agree on ONE configuration 
> including appenders configuration, message Layout and so on.
> Consider this report and provide solution (or workaround) or maybe just 
> reasonable comment for the given system setup, please :-).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1849) Broken FixedDateFormat tests when daylight saving time starts

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15926127#comment-15926127
 ] 

Remko Popma commented on LOG4J2-1849:
-

Thanks for the test. I will need to modify it slightly because it passes for me 
(the default TimeZone for me is JST).

> Broken FixedDateFormat tests when daylight saving time starts
> -
>
> Key: LOG4J2-1849
> URL: https://issues.apache.org/jira/browse/LOG4J2-1849
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.8.1
>Reporter: Matt Sicker
>Assignee: Remko Popma
>
> Today we started daylight saving time in the US, and the following tests 
> failed:
> {noformat}
> Failed tests:
>   FixedDateFormatTest.testFormatLong:162 ABSOLUTE(HH:mm:ss,SSS)/1489305608119 
> expected:<0[3]:00:08,119> but was:<0[2]:00:08,119>
>   FixedDateFormatTest.testFormatLongCharArrayInt:196 
> ABSOLUTE(HH:mm:ss,SSS)/1489305607930 expected:<0[3]:00:07,930> but 
> was:<0[2]:00:07,930>
>   FixedDateFormatTest.testFormatLongCharArrayInt_goingBackInTime:214 
> ABSOLUTE(HH:mm:ss,SSS)/1489381194091 expected:<2[3]:59:54,091> but 
> was:<2[2]:59:54,091>
>   FixedDateFormatTest.testFormatLong_goingBackInTime:178 
> ABSOLUTE(HH:mm:ss,SSS)/1489381194072 expected:<2[3]:59:54,072> but 
> was:<2[2]:59:54,072>
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1849) Broken FixedDateFormat tests when daylight saving time starts

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15924232#comment-15924232
 ] 

Remko Popma commented on LOG4J2-1849:
-

I've started to look at this. The idea of FixedDateFormat is that by supporting 
a subset of the SimpleDateFormat functionality we could get significant 
performance gains. Of course daylight savings jumps need to be supported. 

FixedDateFormat currently stores the TimeZone but does not do anything with it. 
There is some pre-calculation that happens once every day to format the date 
portion. I'm thinking to add logic there to look ahead at the hours of the 
coming day and pre-calculate the DST savings as well.

If you're interested in making more contributions, I would really appreciate 
more repeatable test cases since our current tests only failed on the day that 
a DST change occurred.

> Broken FixedDateFormat tests when daylight saving time starts
> -
>
> Key: LOG4J2-1849
> URL: https://issues.apache.org/jira/browse/LOG4J2-1849
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.8.1
>Reporter: Matt Sicker
>Assignee: Remko Popma
>
> Today we started daylight saving time in the US, and the following tests 
> failed:
> {noformat}
> Failed tests:
>   FixedDateFormatTest.testFormatLong:162 ABSOLUTE(HH:mm:ss,SSS)/1489305608119 
> expected:<0[3]:00:08,119> but was:<0[2]:00:08,119>
>   FixedDateFormatTest.testFormatLongCharArrayInt:196 
> ABSOLUTE(HH:mm:ss,SSS)/1489305607930 expected:<0[3]:00:07,930> but 
> was:<0[2]:00:07,930>
>   FixedDateFormatTest.testFormatLongCharArrayInt_goingBackInTime:214 
> ABSOLUTE(HH:mm:ss,SSS)/1489381194091 expected:<2[3]:59:54,091> but 
> was:<2[2]:59:54,091>
>   FixedDateFormatTest.testFormatLong_goingBackInTime:178 
> ABSOLUTE(HH:mm:ss,SSS)/1489381194072 expected:<2[3]:59:54,072> but 
> was:<2[2]:59:54,072>
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Assigned] (LOG4J2-1849) Broken FixedDateFormat tests when daylight saving time starts

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma reassigned LOG4J2-1849:
---

Assignee: Remko Popma

> Broken FixedDateFormat tests when daylight saving time starts
> -
>
> Key: LOG4J2-1849
> URL: https://issues.apache.org/jira/browse/LOG4J2-1849
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.8.1
>Reporter: Matt Sicker
>Assignee: Remko Popma
>
> Today we started daylight saving time in the US, and the following tests 
> failed:
> {noformat}
> Failed tests:
>   FixedDateFormatTest.testFormatLong:162 ABSOLUTE(HH:mm:ss,SSS)/1489305608119 
> expected:<0[3]:00:08,119> but was:<0[2]:00:08,119>
>   FixedDateFormatTest.testFormatLongCharArrayInt:196 
> ABSOLUTE(HH:mm:ss,SSS)/1489305607930 expected:<0[3]:00:07,930> but 
> was:<0[2]:00:07,930>
>   FixedDateFormatTest.testFormatLongCharArrayInt_goingBackInTime:214 
> ABSOLUTE(HH:mm:ss,SSS)/1489381194091 expected:<2[3]:59:54,091> but 
> was:<2[2]:59:54,091>
>   FixedDateFormatTest.testFormatLong_goingBackInTime:178 
> ABSOLUTE(HH:mm:ss,SSS)/1489381194072 expected:<2[3]:59:54,072> but 
> was:<2[2]:59:54,072>
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
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-1359) Add support for Java 9 StackWalker API in ReflectionUtil

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15906209#comment-15906209
 ] 

Remko Popma edited comment on LOG4J2-1359 at 3/11/17 2:09 PM:
--

Is it possible to compile only one class with Java 9 and the rest with Java 7? 
Maybe have a module with Java 9-only functionality?

We currently delay walking the stack until we need to. Can we do something 
similar with capturing the stack? That is, only capture it when a) we're 
logging synchronously and one of the pattern converters asks for the caller 
location, or b) we're logging asynchronously and we're configured to capture a 
stack snapshot before handing over the log event details to the background 
thread? 

I don't understand what the openjdk devs are suggesting concretely. Can you 
give an example, or point me to something (a specific API, or an example, or an 
email) that would clarify?


was (Author: rem...@yahoo.com):
Is it possible to compile only one class with Java 9 and the rest with Java 7? 
Maybe have a module with Java 9-only functionality?

We currently delay walking the stack until we need to. Can we do something 
similar with capturing the stack? That is, only capture it when a) we're 
logging synchronously and one of the pattern converters asks for the caller 
location, or b) we're logging asynchronously and we're configured to capture a 
stack snapshot before handing over the log event details to the background 
thread? 

I don't understand what the openjdk devs are suggesting concretely. Can you 
point me to something (a specific API, or an example, or an email) that would 
clarify?

> Add support for Java 9 StackWalker API in ReflectionUtil
> 
>
> Key: LOG4J2-1359
> URL: https://issues.apache.org/jira/browse/LOG4J2-1359
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
> Environment: Java 1.9+
>Reporter: Matt Sicker
>Assignee: Ralph Goers
>  Labels: jdk9
>
> [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html]
> Based on the functional nature of this API, supporting it may require 
> compiling at least one class using javac 1.9 and reflectively loading it in 
> ReflectionUtil similar to how Spring supports newer JDK APIs.
> Without support for StackWalker, ReflectionUtil will fall back to using a 
> slower API in Java 1.9. This is because the Reflection class is a 
> sun-internal class which are no longer exported to non-JDK code without 
> setting special command line flags.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
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-1359) Add support for Java 9 StackWalker API in ReflectionUtil

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15906209#comment-15906209
 ] 

Remko Popma edited comment on LOG4J2-1359 at 3/11/17 2:05 PM:
--

Is it possible to compile only one class with Java 9 and the rest with Java 7? 
Maybe have a module with Java 9-only functionality?

We currently delay walking the stack until we need to. Can we do something 
similar with capturing the stack? That is, only capture it when a) we're 
logging synchronously and one of the pattern converters asks for the caller 
location, or b) we're logging asynchronously and we're configured to capture a 
stack snapshot before handing over the log event details to the background 
thread? 

I don't understand what the openjdk devs are suggesting concretely. Can you 
point me to something (a specific API, or an example, or an email) that would 
clarify?


was (Author: rem...@yahoo.com):
Is it possible to compile only one class with Java 9 and the rest with Java 7?

We currently delay walking the stack until we need to. Can we do something 
similar with capturing the stack? That is, only capture it when a) we're 
logging synchronously and one of the pattern converters asks for the caller 
location, or b) we're logging asynchronously and we're configured to capture a 
stack snapshot before handing over the log event details to the background 
thread? 

I don't understand what the openjdk devs are suggesting concretely. Can you 
point me to something (a specific API, or an example, or an email) that would 
clarify?

> Add support for Java 9 StackWalker API in ReflectionUtil
> 
>
> Key: LOG4J2-1359
> URL: https://issues.apache.org/jira/browse/LOG4J2-1359
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
> Environment: Java 1.9+
>Reporter: Matt Sicker
>Assignee: Ralph Goers
>  Labels: jdk9
>
> [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html]
> Based on the functional nature of this API, supporting it may require 
> compiling at least one class using javac 1.9 and reflectively loading it in 
> ReflectionUtil similar to how Spring supports newer JDK APIs.
> Without support for StackWalker, ReflectionUtil will fall back to using a 
> slower API in Java 1.9. This is because the Reflection class is a 
> sun-internal class which are no longer exported to non-JDK code without 
> setting special command line flags.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15906209#comment-15906209
 ] 

Remko Popma commented on LOG4J2-1359:
-

Is it possible to compile only one class with Java 9 and the rest with Java 7?

We currently delay walking the stack until we need to. Can we do something 
similar with capturing the stack? That is, only capture it when a) we're 
logging synchronously and one of the pattern converters asks for the caller 
location, or b) we're logging asynchronously and we're configured to capture a 
stack snapshot before handing over the log event details to the background 
thread? 

I don't understand what the openjdk devs are suggesting concretely. Can you 
point me to something (a specific API, or an example, or an email) that would 
clarify?

> Add support for Java 9 StackWalker API in ReflectionUtil
> 
>
> Key: LOG4J2-1359
> URL: https://issues.apache.org/jira/browse/LOG4J2-1359
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
> Environment: Java 1.9+
>Reporter: Matt Sicker
>Assignee: Ralph Goers
>  Labels: jdk9
>
> [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html]
> Based on the functional nature of this API, supporting it may require 
> compiling at least one class using javac 1.9 and reflectively loading it in 
> ReflectionUtil similar to how Spring supports newer JDK APIs.
> Without support for StackWalker, ReflectionUtil will fall back to using a 
> slower API in Java 1.9. This is because the Reflection class is a 
> sun-internal class which are no longer exported to non-JDK code without 
> setting special command line flags.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
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-1844) Not the correct value of the month in the log

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15905468#comment-15905468
 ] 

Remko Popma edited comment on LOG4J2-1844 at 3/10/17 5:46 PM:
--

I believe the specified pattern is wrong and should be {{%d\{-MM-dd 
HH:mm:ss.SSS\}}} instead: lowercase {{mm}} stands for "minutes", uppercase 
{{MM}} is needed if you want to express months.

Please close if this solves the problem, or re-open if I misunderstood.


was (Author: rem...@yahoo.com):
I believe the specified pattern is wrong and should be {{ %d\{-MM-dd 
HH:mm:ss.SSS\}}} instead: lowercase {{mm}} stands for "minutes", uppercase 
{{MM}} is needed if you want to express months.

Please close if this solves the problem, or re-open if I misunderstood.

> Not the correct value of the month in the log
> -
>
> Key: LOG4J2-1844
> URL: https://issues.apache.org/jira/browse/LOG4J2-1844
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API
>Affects Versions: 2.8.1
> Environment: windows RUS (v.7 and 8.1 is accurate)
> eclipse 4.5.2
> java jdk 1.8.0_74
>    Reporter: Vasiliy Ponomarenko
>Assignee: Remko Popma
>  Labels: month
>
> if pattern contains Month like {{%d\{-mm-dd HH:mm:ss.SSS\}}}
> log has wrong Month value
> Window 8.1 like Month value =  19 or 34 or 35 or 36
> 2017-19-10 16:19:05.535 \[main\] for date 2017-03-10 
> Window 7 like Month value = current value - 1
> 2017-02-10 16:19:05.535 \[main\] for date 2017-03-10 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Resolved] (LOG4J2-1844) Not the correct value of the month in the log

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma resolved LOG4J2-1844.
-
Resolution: Not A Problem

I believe the specified pattern is wrong and should be {{ %d\{-MM-dd 
HH:mm:ss.SSS\}}} instead: lowercase {{mm}} stands for "minutes", uppercase 
{{MM}} is needed if you want to express months.

Please close if this solves the problem, or re-open if I misunderstood.

> Not the correct value of the month in the log
> -
>
> Key: LOG4J2-1844
> URL: https://issues.apache.org/jira/browse/LOG4J2-1844
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API
>Affects Versions: 2.8.1
> Environment: windows RUS (v.7 and 8.1 is accurate)
> eclipse 4.5.2
> java jdk 1.8.0_74
>Reporter: Vasiliy Ponomarenko
>Assignee: Remko Popma
>  Labels: month
>
> if pattern contains Month like {{%d\{-mm-dd HH:mm:ss.SSS\}}}
> log has wrong Month value
> Window 8.1 like Month value =  19 or 34 or 35 or 36
> 2017-19-10 16:19:05.535 \[main\] for date 2017-03-10 
> Window 7 like Month value = current value - 1
> 2017-02-10 16:19:05.535 \[main\] for date 2017-03-10 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1844) Not the correct value of the month in the log

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma updated LOG4J2-1844:

Description: 
if pattern contains Month like {{%d\{-mm-dd HH:mm:ss.SSS\}}}
log has wrong Month value
Window 8.1 like Month value =  19 or 34 or 35 or 36
2017-19-10 16:19:05.535 \[main\] for date 2017-03-10 
Window 7 like Month value = current value - 1
2017-02-10 16:19:05.535 \[main\] for date 2017-03-10 

  was:
if pattern contains Month like %d{-mm-dd HH:mm:ss.SSS}
log has wrong Month value
Window 8.1 like Month value =  19 or 34 or 35 or 36
2017-19-10 16:19:05.535 [main] for date 2017-03-10 
Window 7 like Month value = current value - 1
2017-02-10 16:19:05.535 [main] for date 2017-03-10 


> Not the correct value of the month in the log
> -
>
> Key: LOG4J2-1844
> URL: https://issues.apache.org/jira/browse/LOG4J2-1844
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API
>Affects Versions: 2.8.1
> Environment: windows RUS (v.7 and 8.1 is accurate)
> eclipse 4.5.2
> java jdk 1.8.0_74
>Reporter: Vasiliy Ponomarenko
>Assignee: Remko Popma
>  Labels: month
>
> if pattern contains Month like {{%d\{-mm-dd HH:mm:ss.SSS\}}}
> log has wrong Month value
> Window 8.1 like Month value =  19 or 34 or 35 or 36
> 2017-19-10 16:19:05.535 \[main\] for date 2017-03-10 
> Window 7 like Month value = current value - 1
> 2017-02-10 16:19:05.535 \[main\] for date 2017-03-10 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Assigned] (LOG4J2-1844) Not the correct value of the month in the log

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma reassigned LOG4J2-1844:
---

Assignee: Remko Popma

> Not the correct value of the month in the log
> -
>
> Key: LOG4J2-1844
> URL: https://issues.apache.org/jira/browse/LOG4J2-1844
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API
>Affects Versions: 2.8.1
> Environment: windows RUS (v.7 and 8.1 is accurate)
> eclipse 4.5.2
> java jdk 1.8.0_74
>Reporter: Vasiliy Ponomarenko
>Assignee: Remko Popma
>  Labels: month
>
> if pattern contains Month like %d{-mm-dd HH:mm:ss.SSS}
> log has wrong Month value
> Window 8.1 like Month value =  19 or 34 or 35 or 36
> 2017-19-10 16:19:05.535 [main] for date 2017-03-10 
> Window 7 like Month value = current value - 1
> 2017-02-10 16:19:05.535 [main] for date 2017-03-10 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1841) Problems with consequences after LOG4J2-248

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15903193#comment-15903193
 ] 

Remko Popma commented on LOG4J2-1841:
-

Sounds like we should roll back LOG4J2-248. Matt, what do you think?

> Problems with consequences after LOG4J2-248
> ---
>
> Key: LOG4J2-1841
> URL: https://issues.apache.org/jira/browse/LOG4J2-1841
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Boot
>Affects Versions: 2.8
> Environment: Linux, Tomcat, WebApps
>Reporter: Seweryn Habdank-Wojewodzki
>
> Situation till Log4j v. 2.5 (including it):
> 1. One instance of embedded Jetty (programatically started) WITHOUT 
> definition of the log4j.configurationFile variable.
> 2. WAR deployed on within this concrete instance of the embedded Jetty.
> 3. WAR internally contains own log4j2.xml file. So every Log4j instance, 
> which is global for the WebApp, but local for the Jetty, will search and use 
> configuration in own class path.
> Works in the way that every Web-App got own Log4j configuration and will 
> operate according to own definitions (appenders, layouts, loggers).
> In the Log4j v. 2.6 and later in the same setup we are observing the 
> following:
> Log4j in the applications are reporting problem that config file (log4j2.xml) 
> is not visible. Thus we got message, that Log4j will switch to backup mode 
> which will write only ERRORs in the console.
> We debuged that issue and found that change made in:
> https://issues.apache.org/jira/browse/LOG4J2-248
> seems to be the main reason.
> We cannot asses if this change was made only with respect to some PMD warning 
> or it has as well some design considerations in background.
> The consequence is that Web Server instance shall define 
> log4j.configurationFile variable, but also it means ALL WebApps will use one 
> single configuration, what makes definitely problem, as all WebApps providers 
> must agree on ONE configuration including appenders configuration, message 
> Layout and so on.
> Consider this report and provide solution (or workaround) or maybe just 
> reasonable comment for the given system setup, please :-).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: [VOTE] Combine the project user and dev mailing lists into user@ and dev@

[Remko Popma]

log4j-dev@, log4php-dev@, log4net-dev@, log4cxx-dev@ -> d...@logging.apache.org

+1

log4j-user@, log4php-user@, log4net-user@, log4cxx-user@, general@ -> 
u...@logging.apache.org

Interesting discussion. I can see both pros and cons. How will this work for 
users currently subscribed to log4j-user@? Will they need to resubscribe or is 
this done with aliasing? If this is done with aliasing we can try it and easily 
undo it if it turns out it doesn't work well, and I would be +1 to give it a 
try. 


Sent from my iPhone

> On Mar 8, 2017, at 16:21, Matt Sicker  wrote:
> 
> I don't see much on the user mailing lists either. Sometimes I'll post 
> questions there myself, but I see other developers sticking to the dev lists 
> for their own user questions. It's interesting.
> 
>> On 8 March 2017 at 01:16, Dominik Psenner  wrote:
>> +1
>> 
>> I think that the activity on the user mailing lists is low enough such that 
>> the users are not dragged away, while at the same time they take advantages 
>> of the larger audience. Further it tightens the relationship between the 
>> logging subprojects.
>> 
>> 
>>> On 2017-03-08 06:12, Stefan Bodewig wrote:
>>> On 2017-03-08, Matt Sicker wrote:
>>> 
 I may be missing some mailing lists considering I just subscribed to half
 of them less than five minutes ago.
 This is a vote to merge the various Apache Logging Services mailing lists.
 The proposal is to combine them as follows:
 log4j-dev@, log4php-dev@, log4net-dev@, log4cxx-dev@ ->
 d...@logging.apache.org
>>> +1
>>> 
 log4j-user@, log4php-user@, log4net-user@, log4cxx-user@, general@ ->
 u...@logging.apache.org
>>> -1
>>> 
>>> I don't think the users would benefit from a shared list and would
>>> prefer to keep them separate (this is not a veto, just a vote).
>>> 
>>> Stefan
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>> 
> 
> 
> 
> -- 
> Matt Sicker 

Re: Roadmap for 2.8.1

[Remko Popma]

No objection from me to release log4j-scala. 

Do you have a versioning scheme that lets log4j-scala and log4j upgrade 
independently?

Sent from my iPhone

> On Mar 8, 2017, at 1:42, Mikael Ståldal <mikael.stal...@magine.com> wrote:
> 
> Can we release log4j-scala now? Or to we have to wait for the next release of 
> main repo with Scala modules removed? Should we remove the Scala modules from 
> main repo now?
> 
>> On Fri, Mar 3, 2017 at 5:16 PM, Matt Sicker <boa...@gmail.com> wrote:
>> The Scala language versions is already done the same standard way everyone 
>> implements Scala libraries (hence the strange naming scheme we already 
>> have). I'd imagine that the versions can be completely decoupled by 
>> specifying a minimum Log4j API version it requires (though should generally 
>> be whatever the latest was at release) and bumping its own version as new 
>> features or bugfixes are added. I'd like to see that follow semantic 
>> versioning properly, too.
>> 
>>> On 3 March 2017 at 06:15, Mikael Ståldal <mikael.stal...@magine.com> wrote:
>>> I guess the idea is that releases of Log4j 2 and log4j-scala should be 
>>> independent in both ways, right?
>>> 
>>> I think I have coordination between log4j-scala and Scala language covered 
>>> already.
>>> 
>>>> On Fri, Mar 3, 2017 at 10:19 AM, Remko Popma <remko.po...@gmail.com> wrote:
>>>> Mikael, you probably need to plan your versioning scheme to handle any 
>>>> combination of the following:
>>>> * log4j 2 releases: do you want to do a release for the log4j-scala 
>>>> modules every time? E.g., when we go from 2.8.1 to 2.8.2? My understanding 
>>>> is that once they are decoupled, the log4j-scala modules won't be released 
>>>> automatically with log4j anymore, someone needs to do the work for a 
>>>> log4j-scala release separately. 
>>>> * Scala releases: how do you want to sync up with Scala language versions? 
>>>> (I guess include major Scala version in the log4j-scala module 
>>>> version)
>>>> * log4j-scala module versions: enhancements to these modules, independent 
>>>> of the above 
>>>> 
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>>> On Mar 3, 2017, at 9:10, Mikael Ståldal <mikael.stal...@magine.com> wrote:
>>>>> 
>>>>> I would like to keep package and artifact names, and bump version to 11.0.
>>>>> 
>>>>>> On Mar 1, 2017 4:04 PM, "Matt Sicker" <boa...@gmail.com> wrote:
>>>>>> If you change artifact ids, it's generally a good idea to change 
>>>>>> packages, too. I've had issues in the past with Feign for instance 
>>>>>> because they changed groupId/artifactId at one point but kept the same 
>>>>>> API, so I had two copies on the classpath until I found out there was a 
>>>>>> duplicate and excluded them (though admittedly not a problem in OSGi 
>>>>>> environments :P).
>>>>>> 
>>>>>>> On 1 March 2017 at 07:47, Ralph Goers <ralph.go...@dslextreme.com> 
>>>>>>> wrote:
>>>>>>> You can do that, but that will probably confuse users too. I would 
>>>>>>> suggest changing the artifactId and then start at either 1.0 or 2.0.
>>>>>>> 
>>>>>>> Ralph
>>>>>>> 
>>>>>>>> On Mar 1, 2017, at 6:09 AM, Mikael Ståldal <mikael.stal...@magine.com> 
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> OK, but then at least we have to start with a version > 2.8.
>>>>>>>> 
>>>>>>>> On Wed, Mar 1, 2017 at 1:33 PM, Apache <ralph.go...@dslextreme.com> 
>>>>>>>> wrote:
>>>>>>>>> I guarantee if you try to keep the same versioning you will regret it.
>>>>>>>>> 
>>>>>>>>> Ralph
>>>>>>>>> 
>>>>>>>>>> On Mar 1, 2017, at 2:22 AM, Mikael Ståldal 
>>>>>>>>>> <mikael.stal...@magine.com> wrote:
>>>>>>>>>> 
>>>>>>>>>> I was under the impression that we were not ready to integrate the 
>>>>>>>>>> site from log4j-scala. That's why I considered the release of 
>>>>>>>>>> log4j-scala as delayed, since t

Re: Performance page for next release.

[Remko Popma]

I was thinking along similar lines about keeping the old results and adding a 
set of results for the later versions. On the other hand I want to avoid 
information overload. Let me think about how to present it. 

Sent from my iPhone

> On Mar 4, 2017, at 3:24, Gary Gregory <garydgreg...@gmail.com> wrote:
> 
> I think we should keep the current doc pages on the site perhaps under a 
> different heading. This would be interesting for people who cannot keep up 
> with the latest.
> 
> Gary
> 
>> On Fri, Mar 3, 2017 at 1:20 PM, Remko Popma <remko.po...@gmail.com> wrote:
>> Yes but only the JMH benchmarks. Is that acceptable?
>> 
>> The latency tests and the non-JMH Async Logger tests are too involved...
>> 
>> One thing to bear in mind, we carefully documented the versions of the 
>> libraries we compared against with our benchmark results. The fact that 
>> newer versions of these libraries are now available does not invalidate 
>> those results. It just means that our performance page is not up to date 
>> with the latest version. We can try to stay up to date but in my opinion 
>> it's okay to let some time elapse if we're busy with other things.
>> 
>> Anyway, if just the JMH tests are ok, I'll try to do this in the next month.
>> 
>> Remko
>> 
>> Sent from my iPhone
>> 
>> > On Mar 3, 2017, at 17:24, Ralph Goers <ralph.go...@dslextreme.com> wrote:
>> >
>> > Remko,
>> >
>> > Would it be possible for you to update the performance page for the next 
>> > release? I am uncomfortable with some of the results because I know they 
>> > have changed since 2.6.
>> >
>> > Ralph
>> >
>> > -
>> > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
>> > For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>> >
>> 
>> -
>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>> 
> 
> 
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
> Java Persistence with Hibernate, Second Edition 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com 
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

Re: Performance page for next release.

[Remko Popma]

Ok. I'll focus on those. 

Sent from my iPhone

> On Mar 3, 2017, at 22:49, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> 
> I am most concerned with the two things that have been most impacted - the 
> FileAppenderBenchmark and the MarkerFilterBenchmark.
> 
> Ralph
> 
>> On Mar 3, 2017, at 2:20 PM, Remko Popma <remko.po...@gmail.com> wrote:
>> 
>> Yes but only the JMH benchmarks. Is that acceptable?
>> 
>> The latency tests and the non-JMH Async Logger tests are too involved... 
>> 
>> One thing to bear in mind, we carefully documented the versions of the 
>> libraries we compared against with our benchmark results. The fact that 
>> newer versions of these libraries are now available does not invalidate 
>> those results. It just means that our performance page is not up to date 
>> with the latest version. We can try to stay up to date but in my opinion 
>> it's okay to let some time elapse if we're busy with other things. 
>> 
>> Anyway, if just the JMH tests are ok, I'll try to do this in the next month. 
>> 
>> Remko 
>> 
>> Sent from my iPhone
>> 
>>> On Mar 3, 2017, at 17:24, Ralph Goers <ralph.go...@dslextreme.com> wrote:
>>> 
>>> Remko, 
>>> 
>>> Would it be possible for you to update the performance page for the next 
>>> release? I am uncomfortable with some of the results because I know they 
>>> have changed since 2.6.  
>>> 
>>> Ralph
>>> 
>>> -
>>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>>> 
>> 
>> -
>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>> 
>> 
> 
> 
> 
> -
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
> 

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1259) Log4j threads are leaking on Tomcat shutdown

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15895092#comment-15895092
 ] 

Remko Popma commented on LOG4J2-1259:
-

Do you want to provide a patch for the Log4j2 manual?

> Log4j threads are leaking on Tomcat shutdown
> 
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web 
> also included in the web application deployed in Tomcat 8. The context 
> listener is correctly starting up and shutting down, catalina.properties does 
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>  java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>  com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>  
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
>  com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: Performance page for next release.

[Remko Popma]

Yes but only the JMH benchmarks. Is that acceptable?

The latency tests and the non-JMH Async Logger tests are too involved... 

One thing to bear in mind, we carefully documented the versions of the 
libraries we compared against with our benchmark results. The fact that newer 
versions of these libraries are now available does not invalidate those 
results. It just means that our performance page is not up to date with the 
latest version. We can try to stay up to date but in my opinion it's okay to 
let some time elapse if we're busy with other things. 

Anyway, if just the JMH tests are ok, I'll try to do this in the next month. 

Remko 

Sent from my iPhone

> On Mar 3, 2017, at 17:24, Ralph Goers  wrote:
> 
> Remko, 
> 
> Would it be possible for you to update the performance page for the next 
> release? I am uncomfortable with some of the results because I know they have 
> changed since 2.6.  
> 
> Ralph
> 
> -
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
> 

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: Roadmap for 2.8.1

[Remko Popma]

Mikael, you probably need to plan your versioning scheme to handle any 
combination of the following:
* log4j 2 releases: do you want to do a release for the log4j-scala modules 
every time? E.g., when we go from 2.8.1 to 2.8.2? My understanding is that once 
they are decoupled, the log4j-scala modules won't be released automatically 
with log4j anymore, someone needs to do the work for a log4j-scala release 
separately. 
* Scala releases: how do you want to sync up with Scala language versions? (I 
guess include major Scala version in the log4j-scala module version)
* log4j-scala module versions: enhancements to these modules, independent of 
the above 


Sent from my iPhone

> On Mar 3, 2017, at 9:10, Mikael Ståldal <mikael.stal...@magine.com> wrote:
> 
> I would like to keep package and artifact names, and bump version to 11.0.
> 
>>> On Mar 1, 2017 4:04 PM, "Matt Sicker" <boa...@gmail.com> wrote:
>>> If you change artifact ids, it's generally a good idea to change packages, 
>>> too. I've had issues in the past with Feign for instance because they 
>>> changed groupId/artifactId at one point but kept the same API, so I had two 
>>> copies on the classpath until I found out there was a duplicate and 
>>> excluded them (though admittedly not a problem in OSGi environments :P).
>>> 
>>> On 1 March 2017 at 07:47, Ralph Goers <ralph.go...@dslextreme.com> wrote:
>>> You can do that, but that will probably confuse users too. I would suggest 
>>> changing the artifactId and then start at either 1.0 or 2.0.
>>> 
>>> Ralph
>>> 
>>>> On Mar 1, 2017, at 6:09 AM, Mikael Ståldal <mikael.stal...@magine.com> 
>>>> wrote:
>>>> 
>>>> OK, but then at least we have to start with a version > 2.8.
>>>> 
>>>> On Wed, Mar 1, 2017 at 1:33 PM, Apache <ralph.go...@dslextreme.com> wrote:
>>>>> I guarantee if you try to keep the same versioning you will regret it.
>>>>> 
>>>>> Ralph
>>>>> 
>>>>>> On Mar 1, 2017, at 2:22 AM, Mikael Ståldal <mikael.stal...@magine.com> 
>>>>>> wrote:
>>>>>> 
>>>>>> I was under the impression that we were not ready to integrate the site 
>>>>>> from log4j-scala. That's why I considered the release of log4j-scala as 
>>>>>> delayed, since there is no point of releasing it if we cannot get the 
>>>>>> site integrated.
>>>>>> 
>>>>>> But now when Ralph says he's ready to integrate the site, I guess we can 
>>>>>> go ahead and release log4j-scala.
>>>>>> 
>>>>>> I don't like the idea of having separate versioning for log4j-scala, 
>>>>>> that will be confusing since we have already started with the same 
>>>>>> versioning as Log4j. Log4j-scala also have a dependency on log4j-api, 
>>>>>> and I think we want to keep that in sync.
>>>>>> 
>>>>>> 
>>>>>>>> On Tue, Feb 28, 2017 at 4:08 PM, Matt Sicker <boa...@gmail.com> wrote:
>>>>>>>> One issue we came across in practice is that Scala 2.12 requires Java 
>>>>>>>> 8, but we don't want to require that for the entire build, so we 
>>>>>>>> separated the repo. This also helps avoid making the main log4j repo 
>>>>>>>> from taking forever to build and release which can help the RERO idea. 
>>>>>>>> Plus, these non-core modules don't change nearly as often as 
>>>>>>>> log4j-core or log4j-api, so they don't really need new releases all 
>>>>>>>> that often.
>>>>>>>> 
>>>>>>>> On 28 February 2017 at 01:44, Remko Popma <remko.po...@gmail.com> 
>>>>>>>> wrote:
>>>>>>>> To be honest I still don't understand 
>>>>>>>> 
>>>>>>>> * the vision of what we ultimately want to achieve 
>>>>>>>> * how different repos fit into that vision 
>>>>>>>> * what different websites we are planning to create to give users 
>>>>>>>> access to these different modules 
>>>>>>>> * what websites are going to be driven from which modules or projects 
>>>>>>>> * who of us is going to be driving what aspect of the above 
>>>>>>>> 
>>>>>>>> My lack of understanding is not just limited

Re: [ANNOUNCEMENT] Apache Log4j 2.8.1 released

[Remko Popma]

Blogged: https://blogs.apache.org/logging/entry/log4j-2-8-1-released


On Fri, Mar 3, 2017 at 2:27 PM, Ralph Goers 
wrote:

> The Apache Log4j 2 team is pleased to announce the Log4j 2.8.1 release!
>
> Apache Log4j is a well known framework for logging application behavior.
> Log4j 2 is an upgrade to Log4j that provides significant improvements over
> its predecessor, Log4j 1.x, and provides many other modern features such as
> support for Markers, lambda expressions for lazy logging, property
> substitution using Lookups, multiple patterns on a PatternLayout and
> asynchronous Loggers. Another notable Log4j 2 feature is the ability to be
> "garbage-free" (avoid allocating temporary objects) while logging. In
> addition, Log4j 2 will not lose events while reconfiguring.
>
> This release primarily contains bugfixes and minor enhancements. More
> details on the new features and fixes are itemized below.
>
> Note that subsequent to the 2.6 release a minor source incompatibility was
> found due to the addition of new methods to the Logger interface. If you
> have code that does:
>
> logger.error(null, “This is the log message”, throwable);
>
> or similar with any log level you will get a compiler error saying the
> reference is ambiguous. To correct this either do:
>
> logger.error(“This is the log message”, throwable);
>
> or
>
> logger.error((Marker) null, “This is the log message”, throwable);
>
> The Log4j 2.8.1 API, as well as many core components, maintains binary
> compatibility with previous releases.
>
> GA
> Release 2.8.1
>
> Changes in this version include:
>
> New
> Features
>
>- LOG4J2-1823 :
>Remove deprecation on MessageSupplier lambda functions in Logger API.
>- LOG4J2-1807 :
>[core] Add and implement LogEvent.toImmutable().
>
>
> Fixed
> Bugs
>
>- LOG4J2-1804 :
>Allow %i in file pattern to be preceded with characters other than just
>'-'. Thanks to Pierrick Hymbert.
>- LOG4J2-1816 :
>Change minOccur to minOccurs in Log4j-config.xsd. Thanks to shubhankar1100.
>- LOG4J2-1803 : Fix
>Maven POM to ensure JMH generated classes in log4j-perf are included in
>benchmarks jar.
>- LOG4J2-1800 :
>Report errors when sending to Kafka when using syncSend=false. Thanks to
>Vincent Tieleman.
>- LOG4J2-1805 :
>Fixed rare race condition in FixedDateFormat, made 
> FixedDateFormat::millisSinceMidnight
>method public.
>- LOG4J2-1799 :
>Fixed bug in PropertiesUtil::getCharsetProperty that caused
>UnsupportedCharsetException for ConsoleAppender. Thanks to Eduard
>Gizatullin.
>- LOG4J2-1806 : Fix
>Javadoc for DefaultRolloverStrategy::purgeAscending Thanks to
>challarao.
>- LOG4J2-1818 : Fix
>rollover to work when filePattern contains no directory components. Thanks
>to xkr47.
>
>
> 
> Changes
>
>- LOG4J2-1822 :
>Update SLF4J to 1.7.24.
>- LOG4J2-1812 :
>Improved error message when log4j 2 configuration file not found.
>- LOG4J2-1810 :
>Update to use Logback 1.1.10 and then Logback 1.2 for tests.
>- LOG4J2-1819 :
>Update Jackson from 2.8.5 to 2.8.6.
>
> --
>
> Apache Log4j 2.8.1 requires a minimum of Java 7 to build and run. Log4j
> 2.3 was the last release that supported Java 6.
>
> Basic compatibility with Log4j 1.x is provided through the log4j-1.2-api
> component, however it does not implement some of the very implementation
> specific classes and methods. The package names and Maven groupId have been
> changed to org.apache.logging.log4j to avoid any conflicts with log4j 1.x.
>
> For complete information on Apache Log4j 2, including instructions on how
> to submit bug reports, patches, or suggestions for improvement, see the
> Apache Apache Log4j 2 website:
> https://logging.apache.org/log4j/2.x/
>

[jira] [Comment Edited] (LOG4J2-1761) Support for standard java queues for the async logger

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15891237#comment-15891237
 ] 

Remko Popma edited comment on LOG4J2-1761 at 3/1/17 10:58 PM:
--

You can get some of the advantages by using AsyncAppender. You can select the 
queue implementation when you use AsyncAppender. 

Async Loggers are faster than AsyncAppender in multithreaded scenarios because 
of the Disruptor. Building Async Loggers without the Disruptor would be 
pointless.  If you don't want to use the Disruptor please use AsyncAppender. 

About the overflow, you may be right (I haven't checked). How often can this 
happen? Assuming you are logging 100 million events per second, how long does 
it take to overflow a 64 bit long? 


was (Author: rem...@yahoo.com):
You can get some of the advantages by using AsyncAppender. You can select the 
queue implementation when you use AsyncAppender. 

AsyncAppender Loggers are faster in multithreaded scenarios because of the 
Disruptor. If you don't want to use it please use AsyncAppender. 

About the overflow, you may be right (I haven't checked). How often can this 
happen? Assuming you are logging 100 million events per second, how long does 
it take to overflow a 64 bit long? 

> Support for standard java queues for the async logger
> -
>
> Key: LOG4J2-1761
> URL: https://issues.apache.org/jira/browse/LOG4J2-1761
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.7
>Reporter: Kim Northrop
>Priority: Minor
> Attachments: AsyncLogEvent.java, AsyncLoggerWithQueueContext.java, 
> AsyncLoggerWithQueueContextSelector.java, AsyncLoggerWithQueue.java, 
> QueueWrapperCLQ.java, QueueWrapper.java, QueueWrapperLBQ.java, 
> QueueWrapperLTQ.java
>
>
> Please add support for standard java queues (LinkedTransferQueue, 
> ArrayBlockingQueue, LinkedBlockingQueue, ConcurrentLinkedQueue) to the async 
> logger. I will attach some classes for usage with System properties 
> (Log4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerWithQueueContextSelector,
>  LoggerQueue.Capacity=, LoggerQueue.Type= LinkedTransferQueue, ConcurrentLinkedQueue, LinkedBlockingQueue>). Since most 
> of these queues allocate new nodes for new elements I have not implemented 
> usage of thread locals for the log events.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1761) Support for standard java queues for the async logger

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15891237#comment-15891237
 ] 

Remko Popma commented on LOG4J2-1761:
-

You can get some of the advantages by using AsyncAppender. You can select the 
queue implementation when you use AsyncAppender. 

AsyncAppender Loggers are faster in multithreaded scenarios because of the 
Disruptor. If you don't want to use it please use AsyncAppender. 

About the overflow, you may be right (I haven't checked). How often can this 
happen? Assuming you are logging 100 million events per second, how long does 
it take to overflow a 64 bit long? 

> Support for standard java queues for the async logger
> -
>
> Key: LOG4J2-1761
> URL: https://issues.apache.org/jira/browse/LOG4J2-1761
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.7
>Reporter: Kim Northrop
>Priority: Minor
> Attachments: AsyncLogEvent.java, AsyncLoggerWithQueueContext.java, 
> AsyncLoggerWithQueueContextSelector.java, AsyncLoggerWithQueue.java, 
> QueueWrapperCLQ.java, QueueWrapper.java, QueueWrapperLBQ.java, 
> QueueWrapperLTQ.java
>
>
> Please add support for standard java queues (LinkedTransferQueue, 
> ArrayBlockingQueue, LinkedBlockingQueue, ConcurrentLinkedQueue) to the async 
> logger. I will attach some classes for usage with System properties 
> (Log4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerWithQueueContextSelector,
>  LoggerQueue.Capacity=, LoggerQueue.Type= LinkedTransferQueue, ConcurrentLinkedQueue, LinkedBlockingQueue>). Since most 
> of these queues allocate new nodes for new elements I have not implemented 
> usage of thread locals for the log events.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: [VOTE] Release Log4j 2.8.1-rc1

[Remko Popma]

Darn, we'll miss each other by 18 hours. Almost indeed!

Sent from my iPhone

> On Mar 1, 2017, at 20:32, Gary Gregory <garydgreg...@gmail.com> wrote:
> 
> I land at AMS on March 5 9 AM. Almost!
> 
> Gary
> 
>> On Tue, Feb 28, 2017 at 11:28 PM, Remko Popma <remko.po...@gmail.com> wrote:
>> 
>> 
>>> On Wed, Mar 1, 2017 at 4:07 AM, Gary Gregory <garydgreg...@gmail.com> wrote:
>>> How long are you in Amsterdam? I might be in Dordrecht (1 hour by train 
>>> IIRC) next week for work.
>>  
>> We are flying back to Tokyo on the afternoon of Saturday the 4th.
>> It would be fun to meet in person! Are you in Europe now?
>>   
>>> 
>>> Gary
>>> 
>>>> On Mon, Feb 27, 2017 at 11:36 PM, Remko Popma <remko.po...@gmail.com> 
>>>> wrote:
>>>> FYI I won't be able to start reviewing until Wednesday (likely evening 
>>>> Amsterdam time). 
>>>> 
>>>>> On Mon, Feb 27, 2017 at 3:09 Ralph Goers <ralph.go...@dslextreme.com> 
>>>>> wrote:
>>>>> This is a vote to release Log4j 2.8.1 the next version of the Log4j 2 
>>>>> project.
>>>>> 
>>>>> Please download, test, and cast your votes on the log4j developers list.
>>>>> [] +1, release the artifacts
>>>>> [] -1, don't release because...
>>>>> 
>>>>> The vote will remain open for 72 hours (or more if required). All votes 
>>>>> are welcome and we encourage everyone to test the release, but only 
>>>>> Logging PMC votes are “officially” counted. As always, at least 3 +1 
>>>>> votes and more positive than negative votes are required.
>>>>> 
>>>>> Changes in this version include:
>>>>> 
>>>>> New Features
>>>>> 
>>>>> LOG4J2-1823: Remove deprecation on MessageSupplier lambda functions in 
>>>>> Logger API.
>>>>> LOG4J2-1807: [core] Add and implement LogEvent.toImmutable().
>>>>> Fixed Bugs
>>>>> 
>>>>> LOG4J2-1804: Allow %i in file pattern to be preceded with characters 
>>>>> other than just '-'. Thanks to Pierrick Hymbert.
>>>>> LOG4J2-1816: Change minOccur to minOccurs in Log4j-config.xsd. Thanks to 
>>>>> shubhankar1100.
>>>>> LOG4J2-1803: Fix Maven POM to ensure JMH generated classes in log4j-perf 
>>>>> are included in benchmarks jar.
>>>>> LOG4J2-1800: Report errors when sending to Kafka when using 
>>>>> syncSend=false. Thanks to Vincent Tieleman.
>>>>> LOG4J2-1805: Fixed rare race condition in FixedDateFormat, made 
>>>>> FixedDateFormat::millisSinceMidnight method public.
>>>>> LOG4J2-1799: Fixed bug in PropertiesUtil::getCharsetProperty that caused 
>>>>> UnsupportedCharsetException for ConsoleAppender. Thanks to Eduard 
>>>>> Gizatullin.
>>>>> LOG4J2-1806: Fix Javadoc for DefaultRolloverStrategy::purgeAscending 
>>>>> Thanks to challarao.
>>>>> LOG4J2-1818: Fix rollover to work when filePattern contains no directory 
>>>>> components. Thanks to xkr47.
>>>>> Changes
>>>>> 
>>>>> LOG4J2-1822: Update SLF4J to 1.7.24.
>>>>> LOG4J2-1812: Improved error message when log4j 2 configuration file not 
>>>>> found.
>>>>> LOG4J2-1810: Update to use Logback 1.1.10 and then Logback 1.2 for tests.
>>>>> LOG4J2-1819: Update Jackson from 2.8.5 to 2.8.6.
>>>>> Tag: 
>>>>> a)  for a new copy do "git clone 
>>>>> https://git-wip-us.apache.org/repos/asf/logging-log4j2.git; and then "git 
>>>>> checkout tags/log4j-2.8.1-rc1”
>>>>> b) for an existing working copy to “git pull” and then “git checkout 
>>>>> tags/log4j-2.8.1-rc1”
>>>>> Web Site: http://rgoers.github.io/log4j2-site/index.html
>>>>> 
>>>>> Artifacts: 
>>>>> https://repository.apache.org/content/repositories/orgapachelogging-1025
>>>>> 
>>>>> You may download all the artifacts by executing:
>>>>> wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate 
>>>>> https://repository.apache.org/content/repositories/orgapachelogging-1025/org/apache/logging/log4j/
>>>>> Ralph
>>>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
>>> Java Persistence with Hibernate, Second Edition 
>>> JUnit in Action, Second Edition 
>>> Spring Batch in Action 
>>> Blog: http://garygregory.wordpress.com 
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>> 
> 
> 
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
> Java Persistence with Hibernate, Second Edition 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com 
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

Re: [VOTE] Release Log4j 2.8.1-rc1

[Remko Popma]

+1

Sent from my iPhone

> On Feb 27, 2017, at 3:09, Ralph Goers  wrote:
> 
> This is a vote to release Log4j 2.8.1 the next version of the Log4j 2 project.
> 
> Please download, test, and cast your votes on the log4j developers list.
> [] +1, release the artifacts
> [] -1, don't release because...
> 
> The vote will remain open for 72 hours (or more if required). All votes are 
> welcome and we encourage everyone to test the release, but only Logging PMC 
> votes are “officially” counted. As always, at least 3 +1 votes and more 
> positive than negative votes are required.
> 
> Changes in this version include:
> 
> New Features
> 
> LOG4J2-1823: Remove deprecation on MessageSupplier lambda functions in Logger 
> API.
> LOG4J2-1807: [core] Add and implement LogEvent.toImmutable().
> Fixed Bugs
> 
> LOG4J2-1804: Allow %i in file pattern to be preceded with characters other 
> than just '-'. Thanks to Pierrick Hymbert.
> LOG4J2-1816: Change minOccur to minOccurs in Log4j-config.xsd. Thanks to 
> shubhankar1100.
> LOG4J2-1803: Fix Maven POM to ensure JMH generated classes in log4j-perf are 
> included in benchmarks jar.
> LOG4J2-1800: Report errors when sending to Kafka when using syncSend=false. 
> Thanks to Vincent Tieleman.
> LOG4J2-1805: Fixed rare race condition in FixedDateFormat, made 
> FixedDateFormat::millisSinceMidnight method public.
> LOG4J2-1799: Fixed bug in PropertiesUtil::getCharsetProperty that caused 
> UnsupportedCharsetException for ConsoleAppender. Thanks to Eduard Gizatullin.
> LOG4J2-1806: Fix Javadoc for DefaultRolloverStrategy::purgeAscending Thanks 
> to challarao.
> LOG4J2-1818: Fix rollover to work when filePattern contains no directory 
> components. Thanks to xkr47.
> Changes
> 
> LOG4J2-1822: Update SLF4J to 1.7.24.
> LOG4J2-1812: Improved error message when log4j 2 configuration file not found.
> LOG4J2-1810: Update to use Logback 1.1.10 and then Logback 1.2 for tests.
> LOG4J2-1819: Update Jackson from 2.8.5 to 2.8.6.
> Tag: 
> a)  for a new copy do "git clone 
> https://git-wip-us.apache.org/repos/asf/logging-log4j2.git; and then "git 
> checkout tags/log4j-2.8.1-rc1”
> b) for an existing working copy to “git pull” and then “git checkout 
> tags/log4j-2.8.1-rc1”
> Web Site: http://rgoers.github.io/log4j2-site/index.html
> 
> Artifacts: 
> https://repository.apache.org/content/repositories/orgapachelogging-1025
> 
> You may download all the artifacts by executing:
> wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate 
> https://repository.apache.org/content/repositories/orgapachelogging-1025/org/apache/logging/log4j/
> Ralph

[jira] [Commented] (LOG4J2-1829) Delete log files older than x days and max size of a log file should be y(MB)

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15889858#comment-15889858
 ] 

Remko Popma commented on LOG4J2-1829:
-

Have you seen the Custom Delete action supported by the Rollover File appender: 
https://logging.apache.org/log4j/2.x/manual/appenders.html#CustomDeleteOnRollover

> Delete log files older than x days and max size of a log file should be y(MB)
> -
>
> Key: LOG4J2-1829
> URL: https://issues.apache.org/jira/browse/LOG4J2-1829
> Project: Log4j 2
>  Issue Type: Bug
>Reporter: Senthilraja
>
> I need log4j to handle the following requirements(both).
> 1) I want my log files to be created with maximum size of 100MB, exceeding 
> that size a new file should be created.
> 2) I need to mention number of days to maintain the log files. If the 
> specified days have crossed, the older log files should be deleted.
> Whether both the requirements can be handled in same log4j configuration.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: [VOTE] Release Log4j 2.8.1-rc1

[Remko Popma]

On Wed, Mar 1, 2017 at 4:07 AM, Gary Gregory <garydgreg...@gmail.com> wrote:

> How long are you in Amsterdam? I might be in Dordrecht (1 hour by train
> IIRC) next week for work.
>

We are flying back to Tokyo on the afternoon of Saturday the 4th.
It would be fun to meet in person! Are you in Europe now?


>
> Gary
>
> On Mon, Feb 27, 2017 at 11:36 PM, Remko Popma <remko.po...@gmail.com>
> wrote:
>
>> FYI I won't be able to start reviewing until Wednesday (likely evening
>> Amsterdam time).
>>
>> On Mon, Feb 27, 2017 at 3:09 Ralph Goers <ralph.go...@dslextreme.com>
>> wrote:
>>
>>> This is a vote to release Log4j 2.8.1 the next version of the Log4j 2
>>> project.
>>>
>>> Please download, test, and cast your votes on the log4j developers list.
>>> [] +1, release the artifacts
>>> [] -1, don't release because...
>>>
>>> The vote will remain open for 72 hours (or more if required). All
>>> votes are welcome and we encourage everyone to test the release, but only
>>> Logging PMC votes are “officially” counted. As always, at least 3 +1 votes
>>> and more positive than negative votes are required.
>>>
>>> Changes in this version include:
>>>
>>> <https://github.com/apache/logging-log4j2/blob/fae030ae021790d3127eb5d273141c2ecd1f82e5/RELEASE-NOTES.md#new-features>New
>>> Features
>>>
>>>- LOG4J2-1823 <https://issues.apache.org/jira/browse/LOG4J2-1823>:
>>>Remove deprecation on MessageSupplier lambda functions in Logger API.
>>>- LOG4J2-1807 <https://issues.apache.org/jira/browse/LOG4J2-1807>:
>>>[core] Add and implement LogEvent.toImmutable().
>>>
>>>
>>> <https://github.com/apache/logging-log4j2/blob/fae030ae021790d3127eb5d273141c2ecd1f82e5/RELEASE-NOTES.md#fixed-bugs>Fixed
>>> Bugs
>>>
>>>- LOG4J2-1804 <https://issues.apache.org/jira/browse/LOG4J2-1804>:
>>>Allow %i in file pattern to be preceded with characters other than just
>>>'-'. Thanks to Pierrick Hymbert.
>>>- LOG4J2-1816 <https://issues.apache.org/jira/browse/LOG4J2-1816>:
>>>Change minOccur to minOccurs in Log4j-config.xsd. Thanks to 
>>> shubhankar1100.
>>>- LOG4J2-1803 <https://issues.apache.org/jira/browse/LOG4J2-1803>:
>>>Fix Maven POM to ensure JMH generated classes in log4j-perf are included 
>>> in
>>>benchmarks jar.
>>>- LOG4J2-1800 <https://issues.apache.org/jira/browse/LOG4J2-1800>:
>>>Report errors when sending to Kafka when using syncSend=false. Thanks to
>>>Vincent Tieleman.
>>>- LOG4J2-1805 <https://issues.apache.org/jira/browse/LOG4J2-1805>:
>>>Fixed rare race condition in FixedDateFormat, made
>>>FixedDateFormat::millisSinceMidnight method public.
>>>- LOG4J2-1799 <https://issues.apache.org/jira/browse/LOG4J2-1799>:
>>>Fixed bug in PropertiesUtil::getCharsetProperty that caused
>>>UnsupportedCharsetException for ConsoleAppender. Thanks to Eduard
>>>Gizatullin.
>>>- LOG4J2-1806 <https://issues.apache.org/jira/browse/LOG4J2-1806>:
>>>Fix Javadoc for DefaultRolloverStrategy::purgeAscending Thanks to
>>>challarao.
>>>- LOG4J2-1818 <https://issues.apache.org/jira/browse/LOG4J2-1818>:
>>>Fix rollover to work when filePattern contains no directory components.
>>>Thanks to xkr47.
>>>
>>>
>>> <https://github.com/apache/logging-log4j2/blob/fae030ae021790d3127eb5d273141c2ecd1f82e5/RELEASE-NOTES.md#changes>
>>> Changes
>>>
>>>- LOG4J2-1822 <https://issues.apache.org/jira/browse/LOG4J2-1822>:
>>>Update SLF4J to 1.7.24.
>>>- LOG4J2-1812 <https://issues.apache.org/jira/browse/LOG4J2-1812>:
>>>Improved error message when log4j 2 configuration file not found.
>>>- LOG4J2-1810 <https://issues.apache.org/jira/browse/LOG4J2-1810>:
>>>Update to use Logback 1.1.10 and then Logback 1.2 for tests.
>>>- LOG4J2-1819 <https://issues.apache.org/jira/browse/LOG4J2-1819>:
>>>Update Jackson from 2.8.5 to 2.8.6.
>>>
>>> Tag:
>>>
>>> a)  for a new copy do "git clone 
>>> https://git-wip-us.apache.org/repos/asf/logging-log4j2.git; and then "git 
>>> checkout tags/log4j-2.8.1-rc1”
>>> b) for an existing working copy to “git pull” and then “git checkout 
>>> tags/log4j-2.8.1-rc1”
>&

Re: Roadmap for 2.8.1

[Remko Popma]

To be honest I still don't understand

* the vision of what we ultimately want to achieve
* how different repos fit into that vision
* what different websites we are planning to create to give users access to
these different modules
* what websites are going to be driven from which modules or projects
* who of us is going to be driving what aspect of the above

My lack of understanding is not just limited to the Scala modules but is
about the whole splitting up the release.

Perhaps a diagram would help clarify my understanding. (I think there's
already a JIRA or an epic for the above. Adding some diagrams there would
be very useful.)

Remko

On Tue, Feb 28, 2017 at 2:26 Matt Sicker  wrote:

> I'd be in favour of starting a new release train for the Log4j Scala APIs.
> Not exactly sure which version to start from, though.
>
> On 27 February 2017 at 18:35, Ralph Goers 
> wrote:
>
> If you use that excuse they will never get released as it creates a
> catch-22.  If I release without them then we have a regression until they
> are released.
>
> This is why you shouldn’t really be releasing them using the Log4j
> versions. Change the artifactIds so they can start at 1.0, 2.0 or whatever.
>
> Once you create the release and deploy it to the web site I can modify the
> web site to point to it.
>
> Ralph
>
> On Feb 27, 2017, at 5:19 PM, Matt Sicker  wrote:
>
> Well, you included 2.10 and 2.11 in 2.8.1-rc1 which kind of makes it
> harder to release from the log4j-scala repo when two of the three artifacts
> will already exist.
>
> On 27 February 2017 at 12:14, Ralph Goers 
> wrote:
>
> Why is the release of log4j-scala delayed?
>
> Ralph
>
> On Feb 27, 2017, at 10:23 AM, Mikael Ståldal 
> wrote:
>
> I would really like LOG4J2-1661 and LOG4J2-1690 out in the next release.
>
> I implemented LOG4J2-1690 only in the new log4j-scala repo since I thought
> that it would be released as part of 2.8, otherwise I would have put it to
> the main repo as well. But now releasing of the log4j-scala repo has been
> delayed and I start to get disappointed.
>
> On Sat, Feb 25, 2017 at 8:32 AM, Matt Sicker  wrote:
>
> Relative symlinks would work for that regardless of version. Option 1 it
> is, then?
>
> On 25 February 2017 at 00:22, Apache  wrote:
>
> Note that the link in the log4j site can reference a symlink so that the
> log4j site never has to change when the Scala site is updated.
>
> Ralph
>
> On Feb 24, 2017, at 11:21 PM, Apache  wrote:
>
> Option 2 makes no sense to me.  I don’t plan on being the release manager
> for log4j-scala. In order for me to implement option 2 I would have to
> include the log4j-scala site into the log4j release process - as well as
> log4j-examples, etc if they move out. That is just not doable. Deploying
> the Scala site parallel to log4j makes it much easier to maintain
> independently of log4j.
>
> Ralph
>
> On Feb 24, 2017, at 11:15 PM, Matt Sicker  wrote:
>
> The site repository is laid out like this:
>
> log4j/2.x/ -(symlink)-> log4j-2.8/
> log4j/log4j-2.8/log4j-api/
> ...
> log4j/2.x/log4j-api-scala_2.11/
>
> Option 1 is to put it here instead:
> log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant; that's a pretty
> ugly URL honestly)
> log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory
>
> Option 2 is to commit the scala site where it is now, but you'd have to
> manage it alongside log4j core releases. Option 1 still requires
> maintenance, too.
>
> On 25 February 2017 at 00:05, Apache  wrote:
>
> There is a specific location in svn where the site pages have to be
> committed, so I don’t really understand option 1.
>
> Ralph
>
> On Feb 24, 2017, at 9:48 PM, Matt Sicker  wrote:
>
> I see two ways of doing that, though:
>
> 1. Commit the Scala site in a separate directory similar to what I started
> doing with Log4j Boot. Add redirect pages or rewrite rules via .htaccess if
> possible to keep links from breaking.
> 2. Commit the Scala site where it would go when creating the main site.
> Depending on how you update the files in svn for a site update, could this
> be more annoying to maintain?
>
> On 24 February 2017 at 22:30, Apache  wrote:
>
> From my perspective that doesn’t matter. However, we would really need a
> Scala site before we can modify the Log4j site, otherwise it will be a dead
> link.
>
> All that really needs to happen is the Scala site needs to be checked in
> adjacent to the Log4j 2 site. Then the Log4j 2 site just has a link to the
> Scala site from the main menu. The two sites won’t really be “integrated” -
> they will just have links to each other.
>
> Ralph
>
> On Feb 24, 2017, at 5:02 PM, Matt Sicker  wrote:
>
> It is cosmetic, but we'd also be adding the 

Re: [VOTE] Release Log4j 2.8.1-rc1

[Remko Popma]

FYI I won't be able to start reviewing until Wednesday (likely evening
Amsterdam time).

On Mon, Feb 27, 2017 at 3:09 Ralph Goers  wrote:

> This is a vote to release Log4j 2.8.1 the next version of the Log4j 2
> project.
>
> Please download, test, and cast your votes on the log4j developers list.
> [] +1, release the artifacts
> [] -1, don't release because...
>
> The vote will remain open for 72 hours (or more if required). All
> votes are welcome and we encourage everyone to test the release, but only
> Logging PMC votes are “officially” counted. As always, at least 3 +1 votes
> and more positive than negative votes are required.
>
> Changes in this version include:
>
> New
> Features
>
>- LOG4J2-1823 :
>Remove deprecation on MessageSupplier lambda functions in Logger API.
>- LOG4J2-1807 :
>[core] Add and implement LogEvent.toImmutable().
>
>
> Fixed
> Bugs
>
>- LOG4J2-1804 :
>Allow %i in file pattern to be preceded with characters other than just
>'-'. Thanks to Pierrick Hymbert.
>- LOG4J2-1816 :
>Change minOccur to minOccurs in Log4j-config.xsd. Thanks to shubhankar1100.
>- LOG4J2-1803 : Fix
>Maven POM to ensure JMH generated classes in log4j-perf are included in
>benchmarks jar.
>- LOG4J2-1800 :
>Report errors when sending to Kafka when using syncSend=false. Thanks to
>Vincent Tieleman.
>- LOG4J2-1805 :
>Fixed rare race condition in FixedDateFormat, made
>FixedDateFormat::millisSinceMidnight method public.
>- LOG4J2-1799 :
>Fixed bug in PropertiesUtil::getCharsetProperty that caused
>UnsupportedCharsetException for ConsoleAppender. Thanks to Eduard
>Gizatullin.
>- LOG4J2-1806 : Fix
>Javadoc for DefaultRolloverStrategy::purgeAscending Thanks to challarao.
>- LOG4J2-1818 : Fix
>rollover to work when filePattern contains no directory components. Thanks
>to xkr47.
>
>
> 
> Changes
>
>- LOG4J2-1822 :
>Update SLF4J to 1.7.24.
>- LOG4J2-1812 :
>Improved error message when log4j 2 configuration file not found.
>- LOG4J2-1810 :
>Update to use Logback 1.1.10 and then Logback 1.2 for tests.
>- LOG4J2-1819 :
>Update Jackson from 2.8.5 to 2.8.6.
>
> Tag:
>
> a)  for a new copy do "git clone 
> https://git-wip-us.apache.org/repos/asf/logging-log4j2.git; and then "git 
> checkout tags/log4j-2.8.1-rc1”
> b) for an existing working copy to “git pull” and then “git checkout 
> tags/log4j-2.8.1-rc1”
>
> Web Site:  
> http://rgoers.github.io/log4j2-site/index.html
>
> Artifacts: 
> https://repository.apache.org/content/repositories/orgapachelogging-1025
>
> You may download all the artifacts by executing:
>
> wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate 
> https://repository.apache.org/content/repositories/orgapachelogging-1025/org/apache/logging/log4j/
>
> Ralph
>
>

Re: Does ByteBufferDestination.drain() even need an argument?

[Remko Popma]

Yes, ByteBuffer is only useful for binary data. Using it for text would be
painful.

On Mon, Feb 27, 2017 at 2:55 Matt Sicker <boa...@gmail.com> wrote:

> Oh, alright, that makes sense. No need to change it, I was mainly curious
> since I'm working on some NIO stuff (from the other thread) and came to a
> point where I need to add a similar interface, though now I'm also seeing
> why a StringBuilder is used (I was trying to skip an intermediate step of
> formatting a log message by directly encoding the LogEvent into a
> ByteBuffer since this playground code doesn't have a need for complicated
> layouts, but ensuring the write buffer has enough space between each and
> every byte would be extremely tedious).
>
> On 26 February 2017 at 19:48, Remko Popma <remko.po...@gmail.com> wrote:
>
> Similarly to the way the drain() method gives *implementations *the
> flexibility to return a different ByteBuffer, I wanted to also give *callers
> *the flexibility to drain a different ByteBuffer. I don't have a concrete
> use case for it, but I imagined there might be cases where callers
> overflowed content into another buffer which would need to be drained
> separately.
>
> I don't want to modify the signatures of the ByteBufferDestination
> interface. It would break binary compatibility for no good reason.
>
>
> On Mon, Feb 27, 2017 at 10:33 AM, Matt Sicker <boa...@gmail.com> wrote:
>
> Since all our implementations of ByteBufferDestination return a shared
> ByteBuffer in getByteBuffer(), I don't see why it needs to be provided to
> the drain() method. drain() returns the buffer (or a new one in the case of
> MemoryMappedFileManager), and I don't see why an assumption could be made
> that the buffer you're draining is the exact one the destination already
> knows about. Is there a particular use case why this might not work?
>
> --
> Matt Sicker <boa...@gmail.com>
>
>
>
>
>
> --
> Matt Sicker <boa...@gmail.com>
>

Re: Does ByteBufferDestination.drain() even need an argument?

[Remko Popma]

Similarly to the way the drain() method gives *implementations *the
flexibility to return a different ByteBuffer, I wanted to also give *callers
*the flexibility to drain a different ByteBuffer. I don't have a concrete
use case for it, but I imagined there might be cases where callers
overflowed content into another buffer which would need to be drained
separately.

I don't want to modify the signatures of the ByteBufferDestination
interface. It would break binary compatibility for no good reason.


On Mon, Feb 27, 2017 at 10:33 AM, Matt Sicker  wrote:

> Since all our implementations of ByteBufferDestination return a shared
> ByteBuffer in getByteBuffer(), I don't see why it needs to be provided to
> the drain() method. drain() returns the buffer (or a new one in the case of
> MemoryMappedFileManager), and I don't see why an assumption could be made
> that the buffer you're draining is the exact one the destination already
> knows about. Is there a particular use case why this might not work?
>
> --
> Matt Sicker 
>

Re: Release Notes

[Remko Popma]

Afonso Murakami, if you are a chatbot please unsubscribe. You are failing
the Turing test.

Guys, I suspect someone is trying to train their chatbot on our mailing
list...
If this continues we may need to unsubscribe it ourselves...

On Mon, Feb 27, 2017 at 10:25 AM, Matt Sicker  wrote:

> I don't understand how you're GPG-signing your emails, yet you don't seem
> to understand what a mailing list is. Usually knowledge of one comes with
> the other.
>
> On 26 February 2017 at 18:33, Afonso Murakami 
> wrote:
>
>> That what people does they love and passion to hack other people, what a
>> awful guy, he just benefit him self in my back and is awful.
>>
>> On Feb 26, 2017, at 4:21 PM, Afonso Murakami 
>> wrote:
>>
>> I subscribe for this mail list and already getting hacked that is awfull,
>> is there any where I can report to to let then know about this ?
>>
>> On Feb 26, 2017, at 4:16 PM, Afonso Murakami 
>> wrote:
>>
>> so may be he is doing something for him self and that is a problem, his
>> benefit him behind my back and that is a hacking going on and I can not do
>> anything about it and that is a huge problem, ahh.
>>
>> On Feb 26, 2017, at 4:12 PM, Ralph Goers 
>> wrote:
>>
>> Matt isn’t doing anything for you. If you are here by mistake please just
>> send an email to log4j-dev-unsubscr...@logging.apache.org
>>
>> Ralph
>>
>>
>> On Feb 26, 2017, at 4:49 PM, Afonso Murakami 
>> wrote:
>>
>>  Matt Sicker is doing some work on this can you contact him he can
>> explain better them me, thank's
>>
>> On Feb 26, 2017, at 3:42 PM, Ralph Goers 
>> wrote:
>>
>> I don’t understand. What does the RELEASE-NOTES.txt file have to do with
>> Jira? What generated HTML?  The text file is the result of running the
>> Maven command and is what I past into the email.
>>
>> Ralph
>>
>> On Feb 26, 2017, at 4:27 PM, Matt Sicker  wrote:
>>
>> I renamed it to .md to make it a markdown file so that each issue could
>> link to jira. It makes it look nicer on GitHub, and then it makes it easier
>> to copy/paste the generated HTML into an email or blog post.
>>
>> On 26 February 2017 at 16:57, Apache  wrote:
>>
>>> Matt,
>>>
>>> I am wondering why you renamed RELEASE-NOTES.txt to RELEASE-NOTES.md?
>>> This file is generated by maven as part of preparing for the release. The
>>> output is a text file, not markdown. Furthermore, it caused the release to
>>> fail since it is included by name in the distribution zip files and that
>>> name wasn’t changed.
>>>
>>> I renamed it back to RELEASE-NOTES.txt.
>>>
>>> Ralph
>>>
>>> -
>>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>>>
>>>
>>
>>
>> --
>> Matt Sicker 
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> --
> Matt Sicker 
>

Re: Experimenting with NIO

[Remko Popma]

Afonso, are you a robot?

On Mon, Feb 27, 2017 at 8:44 AM, Afonso Murakami 
wrote:

> That is great thank you very much for your help
>
> On Feb 26, 2017, at 3:36 PM, Matt Sicker  wrote:
>
> Afonso, are you on the right mailing list?
>
> Anyways, I've made more updates to my playground. Without implementing
> manual buffering on top of RandomAccessFile or FileChannel (or the async
> file channel, but that one has a bug in it right now causing OOM errors
> occasionally which is probably due to a misunderstanding on how many
> ByteBuffers I can queue up asynchronously before I'm supposed to stop and
> wait), the Java 101 style of using new BufferedOutputStream(new
> FileOutputStream(file)) is currently the fastest appender I have. I'm also
> trying to implement a MappedByteBuffer version, but now I'm rediscovering
> the reason why we have a ByteBufferDestination interface (plus all I'm
> getting as a result are 2 GB files filled with nulls, so I'm doing
> something wrong here anyways).
>
> I was also able to fix some strange performance issues in the tests that
> were being caused by my Layout implementation, so I've swapped in a trivial
> one that assumes input is in ASCII and casts chars to bytes to encode them.
> In Java 9, we may be able to do something with the compacted strings thing
> they added for ISO-8859-1 strings.
>
> There are also some additional benchmarks added that I found interesting
> while comparing some approaches. For one, copying from a directly-allocated
> ByteBuffer into a byte[] (via ByteBuffer::get(byte[])) is almost twice as
> fast as copying from a heap-allocated ByteBuffer into a byte[]. Another
> interesting thing I found was that doing new Date().toString() is faster
> than Instant.now().toString().
>
> On 26 February 2017 at 16:10, Afonso Murakami 
> wrote:
>
>> Thank you for your help and time .
>>
>> On Feb 26, 2017, at 2:05 PM, Matt Sicker  wrote:
>>
>> So far I've discovered that my implementation of Layout that uses
>> CharsetEncoder.encode(CharBuffer, ByteBuffer, boolean) is slower than
>> the version that just uses CharsetEncoder.encode(CharBuffer). That could
>> be causing issues here.
>>
>> I did try out FileChannel, and based on my current implementations, it's
>> around the same speed as using Files.newOutputStream(). My
>> AsynchronousFileChannel usage must be incorrect as it's working much slower
>> than the synchronous form.
>>
>> On 26 February 2017 at 13:03, Afonso Murakami 
>> wrote:
>>
>>> I don’t know if that make any difference but I click on the link
>>> https://githhub.com/vz/nio-looger to see what is about and when I
>>> finished I sign of on my account may that screw up something or may be not,
>>> I’m not sure if Idid that or not, sorry.
>>>
>>> On Feb 26, 2017, at 10:49 AM, Matt Sicker  wrote:
>>>
>>> I could be doing something wrong entirely here, but so far, the fastest
>>> way I've found to write to a file (not including mmap yet) is via:
>>>
>>> new BufferedOutputStream(Files.newOutputStream(Paths.get("test.log")))
>>>
>>> And this is with added synchronization on the append() method, too.
>>> Also, one of my updates to the async channel version is causing OOM errors
>>> in JMH now, so I broke something.
>>>
>>> On 26 February 2017 at 12:22, Matt Sicker  wrote:
>>>
 I added some basic JMH tests to my repo along with a couple alternative
 appender implementations. I got rid of the unnecessary file region locking
 in the async file channel one, but it's still coming out quite a bit slower
 than the RandomAccessFile and Files.newOutputStream() based appenders,
 though that could be due to the use of Phaser (which I only added to
 cleanly close the appender synchronously).

 On 26 February 2017 at 10:05, Matt Sicker  wrote:

> Perhaps something got optimized by the JVM? I'll add some JMH tests to
> this repo to try out various approaches.
>
> On Sat, Feb 25, 2017 at 21:12, Apache 
> wrote:
>
>> I tried using a FileChannel for the FileAppender a week or so ago to
>> see if passing the ByteBuffer to the FileChannel would improve 
>> performance
>> since it doesn’t have to be synchronized. I didn’t see any improvement
>> though and I ended up reverting it. But I might have done something 
>> wrong.
>>
>> Ralph
>>
>> On Feb 25, 2017, at 4:19 PM, Matt Sicker  wrote:
>>
>> We already use a bit of NIO (ByteBuffer for layouts and
>> appenders/managers, MappedByteBuffer for mmap'd files, FileLock for 
>> locking
>> files, etc.), and I've been playing around with the NIO API lately. I 
>> have
>> some sample code here  to show
>> some trivial use case of AsynchronousFileChannel. In Java 7, 

[jira] [Commented] (LOG4J2-1797) Add asynchronous/non-blocking SPIs for appenders

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15884093#comment-15884093
 ] 

Remko Popma commented on LOG4J2-1797:
-

Would it be possible to use the LMAX ExceptionHandler interface (or introduce 
our own interface which has match the signature of {{handleEventException}} so 
we can have one impl that satisfies both interfaces)? I also like the idea of 
having a {{handleOnShutdownException}} method.

Here is what the LMAX interface looks like, javadocs and all:

{code}
/**
 * Callback handler for uncaught exceptions in the event processing cycle of 
the {@link BatchEventProcessor}
 */
public interface ExceptionHandler {
/**
 * Strategy for handling uncaught exceptions when processing an 
event.
 * 
 * If the strategy wishes to terminate further processing by the {@link 
BatchEventProcessor}
 * then it should throw a {@link RuntimeException}.
 *
 * @param ex   the exception that propagated from the {@link 
EventHandler}.
 * @param sequence of the event which cause the exception.
 * @param eventbeing processed when the exception occurred.  This can 
be null.
void handleEventException(Throwable ex, long sequence, T event);

/**
 * Callback to notify of an exception during {@link 
LifecycleAware#onStart()}
 * @param ex throw during the starting process.
 */
void handleOnStartException(Throwable ex);

/**
 * Callback to notify of an exception during {@link 
LifecycleAware#onShutdown()}
 * @param ex throw during the shutdown process.
 */
void handleOnShutdownException(Throwable ex);
}
{code}

> Add asynchronous/non-blocking SPIs for appenders
> 
>
> Key: LOG4J2-1797
> URL: https://issues.apache.org/jira/browse/LOG4J2-1797
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Reporter: Matt Sicker
>
> Some appenders (e.g., Kafka and Cassandra) support using an asynchronous SPI 
> with callbacks (to make them non-blocking). In a Scala-based API, this could 
> be easily handled with the Future class, and with Java 8, this could be 
> easily handled with a CompleteableFuture class. However, if this API 
> improvement is desired for Java 7, then we'd need to create a basic callback 
> API that would ideally be easy to update to CompleteableFuture later on.
> In theory, such an SPI could also be adapted to use the Flow classes in Java 
> 9. This may be an interesting API to follow as we could use the Reactive 
> Streams standard API or a compatible API.
> Some main things that would be desirable in such an SPI would include 
> asynchronous error handling (e.g., to trigger a failover appender). This 
> should be adapted to work well with the generic AsyncAppender and AsyncLogger 
> as well.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1807) [core] Add and implement LogEvent.toImmutable()

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15884087#comment-15884087
 ] 

Remko Popma commented on LOG4J2-1807:
-

Looking at the code, I would suggest:
* removing the non-static Log4jLogEvent.createMemento() method. It is currently 
not used, and it may create confusion for users: should they call 
{{toImmutable}} or {{createMemento}}?
* removing the static Log4jLogEvent.createMemento(LogEvent) method. Current 
callers (there's only 2) can be updated to call the {{createMemento(LogEvent 
event, boolean includeLocation)}} method instead.

> [core] Add and implement LogEvent.toImmutable()
> ---
>
> Key: LOG4J2-1807
> URL: https://issues.apache.org/jira/browse/LOG4J2-1807
> Project: Log4j 2
>  Issue Type: New Feature
>Affects Versions: 2.8.1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Attachments: logging-log4j2.patch
>
>
> [core] Add and implement LogEvent.asImmutable()
> {code:java}
> /**
>  * Returns an immutable version of this log event, which MAY BE a copy of 
> this event.
>  *  
>  * @return an immutable version of this log event
>  */
> LogEvent asImmutable();
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: Undeprecating MessageSupplier

[Remko Popma]

Thanks Matt!

On Sat, Feb 25, 2017 at 2:47 PM, Matt Sicker <boa...@gmail.com> wrote:

> Changed in https://issues.apache.org/jira/browse/LOG4J2-1823
>
> On 24 February 2017 at 12:58, Remko Popma <remko.po...@gmail.com> wrote:
>
>> +1 I'm fine with undeprecating MessageSupplier.
>>
>> Remko
>>
>> Sent from my iPhone
>>
>> On Feb 24, 2017, at 19:07, Matt Sicker <boa...@gmail.com> wrote:
>>
>> In log4j-api, the interface MessageSupplier has been deprecated ever
>> since we realized that we didn't need it and could just use
>> Supplier for lambda support. However, now that I've actually tried
>> to use this in my own Java 8 project, I noticed that by default, the
>> following will call the deprecated method:
>>
>> logger.info(() -> new MapMessage(convertForLogging(fields)));
>>
>> However, if I cast it, it'll call the non-deprecated form:
>>
>> logger.info((Supplier) () -> new MapMessage(convertForLogging(f
>> ields)));
>>
>> This isn't ideal. I propose we simply undeprecate MessageSupplier as it's
>> the more specific form that javac will use by default anyways. We should
>> note that it won't be available in a hypothetical 3.0 API, but I'd imagine
>> that hypothetical API would just use Java 8's Supplier functional interface
>> instead as well.
>>
>> --
>> Matt Sicker <boa...@gmail.com>
>>
>>
>
>
> --
> Matt Sicker <boa...@gmail.com>
>

Re: Undeprecating MessageSupplier

[Remko Popma]

+1 I'm fine with undeprecating MessageSupplier. 

Remko 

Sent from my iPhone

> On Feb 24, 2017, at 19:07, Matt Sicker  wrote:
> 
> In log4j-api, the interface MessageSupplier has been deprecated ever since we 
> realized that we didn't need it and could just use Supplier for 
> lambda support. However, now that I've actually tried to use this in my own 
> Java 8 project, I noticed that by default, the following will call the 
> deprecated method:
> 
> logger.info(() -> new MapMessage(convertForLogging(fields)));
> 
> However, if I cast it, it'll call the non-deprecated form:
> 
> logger.info((Supplier) () -> new 
> MapMessage(convertForLogging(fields)));
> 
> This isn't ideal. I propose we simply undeprecate MessageSupplier as it's the 
> more specific form that javac will use by default anyways. We should note 
> that it won't be available in a hypothetical 3.0 API, but I'd imagine that 
> hypothetical API would just use Java 8's Supplier functional interface 
> instead as well.
> 
> -- 
> Matt Sicker 

[jira] [Commented] (LOG4J2-1820) Log4j 2.8 can lose exceptions when a security manager is present

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876449#comment-15876449
 ] 

Remko Popma commented on LOG4J2-1820:
-

Hi Jason, I'm traveling and may not get around to looking at this for some 
time. Perhaps someone else in the community can take a look?

> Log4j 2.8 can lose exceptions when a security manager is present
> 
>
> Key: LOG4J2-1820
> URL: https://issues.apache.org/jira/browse/LOG4J2-1820
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Jason Tedor
> Attachments: 
> 0001-Handle-security-exception-on-getting-class-loader.patch
>
>
> When Log4j is rendering an exception, it can attempt to access a class loader 
> that it does not have permissions to access when a security manager is 
> present.
> I have a patch and a failing test case for this; I will submit it shortly.
> This is similar to LOG4J2-1560.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1760) AsyncAppender with LinkedTransferQueue.offer()

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma updated LOG4J2-1760:

Fix Version/s: 2.8.1

> AsyncAppender with LinkedTransferQueue.offer()
> --
>
> Key: LOG4J2-1760
> URL: https://issues.apache.org/jira/browse/LOG4J2-1760
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Affects Versions: 2.7
>Reporter: Addison Walterson
>Assignee: Remko Popma
>Priority: Minor
> Fix For: 2.8.1
>
>
> I suggest that the AsyncAppender can use a LinkedTransferQueue for which 
> offer() is used to enqueue messages because tryTransfer() only succeeds if 
> the receiving thread waits for a message which means that the queue has 
> length 0.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Assigned] (LOG4J2-1760) AsyncAppender with LinkedTransferQueue.offer()

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma reassigned LOG4J2-1760:
---

Assignee: Remko Popma

> AsyncAppender with LinkedTransferQueue.offer()
> --
>
> Key: LOG4J2-1760
> URL: https://issues.apache.org/jira/browse/LOG4J2-1760
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Affects Versions: 2.7
>Reporter: Addison Walterson
>Assignee: Remko Popma
>Priority: Minor
> Fix For: 2.8.1
>
>
> I suggest that the AsyncAppender can use a LinkedTransferQueue for which 
> offer() is used to enqueue messages because tryTransfer() only succeeds if 
> the receiving thread waits for a message which means that the queue has 
> length 0.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1563) Log4j 2.6.2 can lose exceptions when a security manager is present

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15872993#comment-15872993
 ] 

Remko Popma commented on LOG4J2-1563:
-

I Saw you raised LOG4J2-1820 for the new issue. Perfect, thanks!

> Log4j 2.6.2 can lose exceptions when a security manager is present
> --
>
> Key: LOG4J2-1563
> URL: https://issues.apache.org/jira/browse/LOG4J2-1563
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2
>Reporter: Jason Tedor
>Assignee: Gary Gregory
> Fix For: 2.7
>
> Attachments: 
> 0001-Unify-handling-of-throwables-when-loading-class.patch, 
> 0002-Remove-policy-in-throwable-proxy-security-test.patch, 
> throwable-proxy-security-exception-2.6.2.patch
>
>
> When Log4j is rendering an exception, it can attempt to load classes that it 
> does not have permissions to load when a security manager is present.
> I have a patch and a failing test case for this; I will submit it shortly.
> This is the backport for LOG4J2-1560.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1807) [core] Add and implement LogEvent.toImmutable()

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15872545#comment-15872545
 ] 

Remko Popma commented on LOG4J2-1807:
-

They have different usages. From memory: the Builder is used in the critical 
path for non-garbagefree logging (so needs to be fast), while the 
serialize-deserialize implementation is used by some appenders like the SMTP 
appender. I believe both implementations have existed for a long time. It may 
be possible to unify them but we would need to be very sure there's no side 
effect anywhere...

> [core] Add and implement LogEvent.toImmutable()
> ---
>
> Key: LOG4J2-1807
> URL: https://issues.apache.org/jira/browse/LOG4J2-1807
> Project: Log4j 2
>  Issue Type: New Feature
>Affects Versions: 2.8.1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Attachments: logging-log4j2.patch
>
>
> [core] Add and implement LogEvent.asImmutable()
> {code:java}
> /**
>  * Returns an immutable version of this log event, which MAY BE a copy of 
> this event.
>  *  
>  * @return an immutable version of this log event
>  */
> LogEvent asImmutable();
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1807) [core] Add and implement LogEvent.toImmutable()

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15871191#comment-15871191
 ] 

Remko Popma commented on LOG4J2-1807:
-

Gary, will do. I'll try to make time in the next few weeks. 

> [core] Add and implement LogEvent.toImmutable()
> ---
>
> Key: LOG4J2-1807
> URL: https://issues.apache.org/jira/browse/LOG4J2-1807
> Project: Log4j 2
>  Issue Type: New Feature
>Affects Versions: 2.8.1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Attachments: logging-log4j2.patch
>
>
> [core] Add and implement LogEvent.asImmutable()
> {code:java}
> /**
>  * Returns an immutable version of this log event, which MAY BE a copy of 
> this event.
>  *  
>  * @return an immutable version of this log event
>  */
> LogEvent asImmutable();
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: Async logging and thread name

[Remko Popma]

Hi Leon,

Yes by default the thread name is cached. 
There is a system property to switch that off: see 
https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/async/ThreadNameCachingStrategy.java

The reason for the caching is that every call to get the current thread's name 
creates a new String object, which I found impacted performance measurably. 

Why Thread is implemented to store its name in a char[] array and create a new 
String on each query I don't know. May have to do with interaction with native 
code.

Remko

Sent from my iPhone

> On Feb 16, 2017, at 4:37, Leon Finker  wrote:
> 
> Hi,
> 
> Is there any thread name caching going on with log4j2 (doesn't matter 
> sync/async)? If I have a thread pool of tasks and call 
> Thread.currentThread().setName (with unique id) in the beginning of the task 
> execution, I sometimes see reuse of previous thread name in the log 
> statements. Id is UUID, so it's definitely unique. And if I do System.out on 
> the current thread name after setting it, I do see the new name as expected. 
> But in log statements the thread name is from the previous set. The pattern 
> layout is: [%date{DEFAULT}{UTC}Z][%level][%thread:%tid][%c{3}] %message%n
> 
> log4j:2.7
> 
> Any ideas what could be causing the thread name reuse?
> 
> Thank you
> 
> -
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
> 

Re: RollingAppenderSizeTest failures

[Remko Popma]

The new test failure (can't open zip) looks like a one-off...

Sent from my iPhone

> On Feb 15, 2017, at 9:58, Gary Gregory  wrote:
> 
>> On Tue, Feb 14, 2017 at 3:22 PM, Apache  wrote:
>> What problem before what?
>> 
>> RollingAppenderSizeTest was failing because I was manually trying to delete 
>> files instead of letting the Rule do it.
> 
> My mistake. I did not know that the issue was as simple as that.
> 
> Gary
>  
>> 
>> Ralph
>> 
>>> On Feb 14, 2017, at 2:56 PM, Gary Gregory  wrote:
>>> 
>>> Was the problem before that threads where not finishing normally on test 
>>> completion? Could this be the same kind of issue?
>>> 
>>> Gary
>>> 
 On Tue, Feb 14, 2017 at 1:28 PM, Apache  wrote:
 I got a Windows 10 VM installed and was able to reproduce the problem and 
 fix it. However, now the build is failing with
 
 Failed tests:
   
 GcFreeAsynchronousLoggingTest.testNoAllocationDuringSteadyStateLogging:34 
 Error opening zip file or JAR manifest missing : 
 C:\Users\Ralph%20Goers\.m2\repository\com\google\code\java-allocation-instrumenter\java-allocation-instrumenter\3.0.1\java-allocation-instrumenter-3.0.1.jar
  expected:<[FATAL o.a.l.l.c.GcFreeAsynchronousLoggingTest [main] value1 
 {aKey=value1, key2=value2, prop1=value1, prop2=value2} This message is 
 logged to the console]> but was:<[Error opening zip file or JAR manifest 
 missing : 
 C:\Users\Ralph%20Goers\.m2\repository\com\google\code\java-allocation-instrumenter\java-allocation-instrumenter\3.0.1\java-allocation-instrumenter-3.0.1.jar]>
   
 GcFreeMixedSyncAyncLoggingTest.testNoAllocationDuringSteadyStateLogging:30 
 Error opening zip file or JAR manifest missing : 
 C:\Users\Ralph%20Goers\.m2\repository\com\google\code\java-allocation-instrumenter\java-allocation-instrumenter\3.0.1\java-allocation-instrumenter-3.0.1.jar
  expected:<[FATAL o.a.l.l.c.GcFreeMixedSyncAyncLoggingTest [main] value1 
 {aKey=value1, key2=value2, prop1=value1, prop2=value2} This message is 
 logged to the console]> but was:<[Error opening zip file or JAR manifest 
 missing : 
 C:\Users\Ralph%20Goers\.m2\repository\com\google\code\java-allocation-instrumenter\java-allocation-instrumenter\3.0.1\java-allocation-instrumenter-3.0.1.jar]>
   GcFreeSynchronousLoggingTest.testNoAllocationDuringSteadyStateLogging:30 
 Error opening zip file or JAR manifest missing : 
 C:\Users\Ralph%20Goers\.m2\repository\com\google\code\java-allocation-instrumenter\java-allocation-instrumenter\3.0.1\java-allocation-instrumenter-3.0.1.jar
  expected:<[FATAL o.a.l.l.c.GcFreeSynchronousLoggingTest [main] value1 
 {aKey=value1, key2=value2, prop1=value1, prop2=value2} This message is 
 logged to the console]> but was:<[Error opening zip file or JAR manifest 
 missing : 
 C:\Users\Ralph%20Goers\.m2\repository\com\google\code\java-allocation-instrumenter\java-allocation-instrumenter\3.0.1\java-allocation-instrumenter-3.0.1.jar]>
 
 Ralph
 
> On Feb 13, 2017, at 12:13 PM, Apache  wrote:
> 
> No. I plan to figure out why it is breaking.
> 
> Ralph
> 
>> On Feb 13, 2017, at 11:02 AM, Gary Gregory  
>> wrote:
>> 
>> My hope was that Ralph would revert his commit that broke the build on 
>> Windows.
>> 
>> Gary
>> 
>>> On Mon, Feb 13, 2017 at 10:01 AM, Gary Gregory  
>>> wrote:
>>> Maven just works as in on Windows. I have the Maven bin folder on my 
>>> PATH, that's it, it contains mvn.cmd.
>>> 
>>> Gary
>>> 
 On Mon, Feb 13, 2017 at 9:45 AM, Matt Sicker  wrote:
 Well, that's step one! My only Windows computer is for videogames, so 
 I'm not really experienced with development in such an environment 
 these days. If you can figure out how to get the mvnw.cmd script to 
 work in Windows, that'd be great.
 
> On 13 February 2017 at 11:26, Gary Gregory  
> wrote:
> Thank you for setting that up Matt. I can see the same failures on 
> https://builds.apache.org/job/Log4jWindows/ as I do locally.
> 
> Gary
> 
>> On Sun, Feb 12, 2017 at 11:11 PM, Matt Sicker  
>> wrote:
>> Also, using a similar multi-config Jenkins job, we can set up JDK 7, 
>> 8, and 9pre Linux builds as well.
>> 
>>> On 13 February 2017 at 01:08, Matt Sicker  wrote:
>>> Sorry for the deluge of build emails, forgot to disable that.
>>> 
>>> Anyways, I got the build running for Windows: 
>>> . I have it set to run 
>>> daily for now as 

[jira] [Closed] (LOG4J2-1816) Fix minOccur in log4j-config.xsd

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma closed LOG4J2-1816.
---
Resolution: Fixed

Pull request accepted in commit 2cb9949.
Keep 'em coming!

> Fix minOccur in log4j-config.xsd
> 
>
> Key: LOG4J2-1816
> URL: https://issues.apache.org/jira/browse/LOG4J2-1816
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.8
>    Reporter: Remko Popma
>    Assignee: Remko Popma
> Fix For: 2.8.1
>
>
> StackOverflow pull request #58:
> https://github.com/apache/logging-log4j2/pull/58/files/8290a8812e51c60df507c52803d211b7523d948c



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Created] (LOG4J2-1816) Fix minOccur in log4j-config.xsd

[Remko Popma (JIRA)]

Remko Popma created LOG4J2-1816:
---

 Summary: Fix minOccur in log4j-config.xsd
 Key: LOG4J2-1816
 URL: https://issues.apache.org/jira/browse/LOG4J2-1816
 Project: Log4j 2
  Issue Type: Bug
Affects Versions: 2.8
Reporter: Remko Popma
Assignee: Remko Popma
 Fix For: 2.8.1


StackOverflow pull request #58:

https://github.com/apache/logging-log4j2/pull/58/files/8290a8812e51c60df507c52803d211b7523d948c



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1814) Wrapper Generate$ExtendedLogger name inconvenient on Linux

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15865220#comment-15865220
 ] 

Remko Popma commented on LOG4J2-1814:
-

That is what I had in mind. Sorry I wasn't clear. 

> Wrapper Generate$ExtendedLogger name inconvenient on Linux 
> ---
>
> Key: LOG4J2-1814
> URL: https://issues.apache.org/jira/browse/LOG4J2-1814
> Project: Log4j 2
>  Issue Type: Improvement
>        Reporter: Remko Popma
>    Assignee: Remko Popma
>
> The $ExtendedLogger is interpreted as an environment variable. 
> {code}
> $ java -cp log4j-core-2.8.jar 
> org.apache.logging.log4j.core.tools.Generate$ExtendedLogger \
>  com.mycomp.ExtLogger DIAG=350 NOTICE=450 VERBOSE=550 > 
> com/mycomp/ExtLogger.java
> Error: Main method not found in class 
> org.apache.logging.log4j.core.tools.Generate, please define the main method 
> {code}
> The workaround is to quote the class name:
> {code}
> $ java -cp log4j-core-2.8.jar 
> "org.apache.logging.log4j.core.tools.Generate$ExtendedLogger" \
>  com.mycomp.ExtLogger DIAG=350 NOTICE=450 VERBOSE=550 > 
> com/mycomp/ExtLogger.java
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1814) Wrapper Generate$ExtendedLogger name inconvenient on Linux

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15865065#comment-15865065
 ] 

Remko Popma commented on LOG4J2-1814:
-

Also, improve the docs to clarify usage 
(http://stackoverflow.com/q/42192625/1446916).

> Wrapper Generate$ExtendedLogger name inconvenient on Linux 
> ---
>
> Key: LOG4J2-1814
> URL: https://issues.apache.org/jira/browse/LOG4J2-1814
> Project: Log4j 2
>  Issue Type: Improvement
>        Reporter: Remko Popma
>    Assignee: Remko Popma
>
> The $ExtendedLogger is interpreted as an environment variable. 
> {code}
> $ java -cp log4j-core-2.8.jar 
> org.apache.logging.log4j.core.tools.Generate$ExtendedLogger \
>  com.mycomp.ExtLogger DIAG=350 NOTICE=450 VERBOSE=550 > 
> com/mycomp/ExtLogger.java
> Error: Main method not found in class 
> org.apache.logging.log4j.core.tools.Generate, please define the main method 
> {code}
> The workaround is to quote the class name:
> {code}
> $ java -cp log4j-core-2.8.jar 
> "org.apache.logging.log4j.core.tools.Generate$ExtendedLogger" \
>  com.mycomp.ExtLogger DIAG=350 NOTICE=450 VERBOSE=550 > 
> com/mycomp/ExtLogger.java
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1814) Wrapper Generate$ExtendedLogger name inconvenient on Linux

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma updated LOG4J2-1814:

Description: 
The $ExtendedLogger is interpreted as an environment variable. 

{code}
$ java -cp log4j-core-2.8.jar 
org.apache.logging.log4j.core.tools.Generate$ExtendedLogger \
 com.mycomp.ExtLogger DIAG=350 NOTICE=450 VERBOSE=550 > 
com/mycomp/ExtLogger.java

Error: Main method not found in class 
org.apache.logging.log4j.core.tools.Generate, please define the main method 
{code}

The workaround is to quote the class name:

{code}
$ java -cp log4j-core-2.8.jar 
"org.apache.logging.log4j.core.tools.Generate$ExtendedLogger" \
 com.mycomp.ExtLogger DIAG=350 NOTICE=450 VERBOSE=550 > 
com/mycomp/ExtLogger.java
{code}

  was:
The $ExtendedLogger is interpreted as an environment variable. 

{code}
$ java -cp log4j-core-2.8.jar 
org.apache.logging.log4j.core.tools.Generate$ExtendedLogger \
> com.mycomp.ExtLogger DIAG=350 NOTICE=450 VERBOSE=550 > 
> com/mycomp/ExtLogger.java
Error: Main method not found in class 
org.apache.logging.log4j.core.tools.Generate, please define the main method 
{code}

The workaround is to quote the class name:

{code}
$ java -cp log4j-core-2.8.jar 
"org.apache.logging.log4j.core.tools.Generate$ExtendedLogger" \
> com.mycomp.ExtLogger DIAG=350 NOTICE=450 VERBOSE=550 > 
> com/mycomp/ExtLogger.java
{code}


> Wrapper Generate$ExtendedLogger name inconvenient on Linux 
> ---
>
> Key: LOG4J2-1814
> URL: https://issues.apache.org/jira/browse/LOG4J2-1814
> Project: Log4j 2
>      Issue Type: Improvement
>Reporter: Remko Popma
>Assignee: Remko Popma
>
> The $ExtendedLogger is interpreted as an environment variable. 
> {code}
> $ java -cp log4j-core-2.8.jar 
> org.apache.logging.log4j.core.tools.Generate$ExtendedLogger \
>  com.mycomp.ExtLogger DIAG=350 NOTICE=450 VERBOSE=550 > 
> com/mycomp/ExtLogger.java
> Error: Main method not found in class 
> org.apache.logging.log4j.core.tools.Generate, please define the main method 
> {code}
> The workaround is to quote the class name:
> {code}
> $ java -cp log4j-core-2.8.jar 
> "org.apache.logging.log4j.core.tools.Generate$ExtendedLogger" \
>  com.mycomp.ExtLogger DIAG=350 NOTICE=450 VERBOSE=550 > 
> com/mycomp/ExtLogger.java
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1814) Wrapper Generate$ExtendedLogger name inconvenient on Linux

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma updated LOG4J2-1814:

Description: 
The $ExtendedLogger is interpreted as an environment variable. 

{code}
$ java -cp log4j-core-2.8.jar 
org.apache.logging.log4j.core.tools.Generate$ExtendedLogger \
> com.mycomp.ExtLogger DIAG=350 NOTICE=450 VERBOSE=550 > 
> com/mycomp/ExtLogger.java
Error: Main method not found in class 
org.apache.logging.log4j.core.tools.Generate, please define the main method 
{code}

The workaround is to quote the class name:

{code}
$ java -cp log4j-core-2.8.jar 
"org.apache.logging.log4j.core.tools.Generate$ExtendedLogger" \
> com.mycomp.ExtLogger DIAG=350 NOTICE=450 VERBOSE=550 > 
> com/mycomp/ExtLogger.java
{code}

  was:The $ExtendedLogger is interpreted as an environment variable. 


> Wrapper Generate$ExtendedLogger name inconvenient on Linux 
> ---
>
> Key: LOG4J2-1814
> URL: https://issues.apache.org/jira/browse/LOG4J2-1814
> Project: Log4j 2
>  Issue Type: Improvement
>    Reporter: Remko Popma
>Assignee: Remko Popma
>
> The $ExtendedLogger is interpreted as an environment variable. 
> {code}
> $ java -cp log4j-core-2.8.jar 
> org.apache.logging.log4j.core.tools.Generate$ExtendedLogger \
> > com.mycomp.ExtLogger DIAG=350 NOTICE=450 VERBOSE=550 > 
> > com/mycomp/ExtLogger.java
> Error: Main method not found in class 
> org.apache.logging.log4j.core.tools.Generate, please define the main method 
> {code}
> The workaround is to quote the class name:
> {code}
> $ java -cp log4j-core-2.8.jar 
> "org.apache.logging.log4j.core.tools.Generate$ExtendedLogger" \
> > com.mycomp.ExtLogger DIAG=350 NOTICE=450 VERBOSE=550 > 
> > com/mycomp/ExtLogger.java
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1814) Wrapper Generate$ExtendedLogger name inconvenient on Linux

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma updated LOG4J2-1814:

External issue URL: 
https://gist.github.com/sdwsk/47b86d243023b1583d340889a89639f6

> Wrapper Generate$ExtendedLogger name inconvenient on Linux 
> ---
>
> Key: LOG4J2-1814
> URL: https://issues.apache.org/jira/browse/LOG4J2-1814
> Project: Log4j 2
>  Issue Type: Improvement
>        Reporter: Remko Popma
>    Assignee: Remko Popma
>
> The $ExtendedLogger is interpreted as an environment variable. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Created] (LOG4J2-1814) Wrapper Generate$ExtendedLogger name inconvenient on Linux

[Remko Popma (JIRA)]

Remko Popma created LOG4J2-1814:
---

 Summary: Wrapper Generate$ExtendedLogger name inconvenient on 
Linux 
 Key: LOG4J2-1814
 URL: https://issues.apache.org/jira/browse/LOG4J2-1814
 Project: Log4j 2
  Issue Type: Improvement
Reporter: Remko Popma
Assignee: Remko Popma


The $ExtendedLogger is interpreted as an environment variable. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1808) java.lang.NoSuchMethodError: org.apache.logging.log4j.ThreadContext.getThreadContextMap()

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15863818#comment-15863818
 ] 

Remko Popma commented on LOG4J2-1808:
-

Glad to hear that.

> java.lang.NoSuchMethodError: 
> org.apache.logging.log4j.ThreadContext.getThreadContextMap()
> -
>
> Key: LOG4J2-1808
> URL: https://issues.apache.org/jira/browse/LOG4J2-1808
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.8
> Environment: Google AppEngine local development server
>Reporter: Lukasz Lenart
>
> {noformat}
> [INFO] Feb 04, 2017 4:38:37 PM com.google.apphosting.utils.jetty.JettyLogger 
> warn
> [INFO] WARNING: failed 
> com.google.appengine.tools.development.DevAppEngineWebAppContext@454577f3{/,/Users/lukaszlenart/Projects/Private/gruuf-webapp/target/gruuf-webapp-1.0-SNAPSHOT}:
>  java.lang.NoSuchMethodError: 
> org.apache.logging.log4j.ThreadContext.getThreadContextMap()Lorg/apache/logging/log4j/spi/ReadOnlyThreadContextMap;
> [INFO] Feb 04, 2017 4:38:37 PM com.google.apphosting.utils.jetty.JettyLogger 
> warn
> [INFO] WARNING: failed JettyContainerService$ApiProxyHandler@53c6160c: 
> java.lang.NoSuchMethodError: 
> org.apache.logging.log4j.ThreadContext.getThreadContextMap()Lorg/apache/logging/log4j/spi/ReadOnlyThreadContextMap;
> [INFO] Feb 04, 2017 4:38:37 PM com.google.apphosting.utils.jetty.JettyLogger 
> warn
> [INFO] WARNING: Error starting handlers
> [INFO] java.lang.NoSuchMethodError: 
> org.apache.logging.log4j.ThreadContext.getThreadContextMap()Lorg/apache/logging/log4j/spi/ReadOnlyThreadContextMap;
> [INFO]at 
> org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createDefaultInjector(ContextDataInjectorFactory.java:83)
> [INFO]at 
> org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createInjector(ContextDataInjectorFactory.java:67)
> [INFO]at 
> org.apache.logging.log4j.core.lookup.ContextMapLookup.(ContextMapLookup.java:34)
> [INFO]at 
> org.apache.logging.log4j.core.lookup.Interpolator.(Interpolator.java:117)
> [INFO]at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.(AbstractConfiguration.java:125)
> [INFO]at 
> org.apache.logging.log4j.core.config.NullConfiguration.(NullConfiguration.java:32)
> [INFO]at 
> org.apache.logging.log4j.core.LoggerContext.(LoggerContext.java:77)
> [INFO]at 
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.createContext(ClassLoaderContextSelector.java:171)
> [INFO]at 
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.locateContext(ClassLoaderContextSelector.java:145)
> [INFO]at 
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:70)
> [INFO]at 
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:57)
> [INFO]at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:147)
> [INFO]at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
> [INFO]at 
> org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
> [INFO]at 
> org.apache.logging.log4j.LogManager.getLogger(LogManager.java:551)
> [INFO]at 
> org.apache.struts2.tiles.StrutsTilesListener.(StrutsTilesListener.java:34)
> [INFO]at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> [INFO]at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> [INFO]at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> [INFO]at 
> java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> [INFO]at java.lang.Class.newInstance(Class.java:383)
> [INFO]at 
> org.mortbay.jetty.webapp.WebXmlConfiguration.newListenerInstance(WebXmlConfiguration.java:650)
> [INFO]at 
> org.mortbay.jetty.webapp.WebXmlConfiguration.initListener(WebXmlConfiguration.java:631)
> [INFO]at 
> org.mortbay.jetty.webapp.WebXmlConfiguration.initWebXmlElement(WebXmlConfiguration.java:368)
> [INFO]at 
> org.mortbay.jetty.webapp.WebXmlConfiguration.initialize(WebXmlConfiguration.java:289)
> [INFO]at 
> org.mortbay.jetty.webapp.WebXmlConfiguration.configure(WebXmlConfiguration.java:222)
> [INFO]at 
> org.mortbay.jetty.webapp.WebXmlConf

[jira] [Commented] (LOG4J2-1813) Provide shorter and more intuitive way to switch on Log4j internal debug logging

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15863065#comment-15863065
 ] 

Remko Popma commented on LOG4J2-1813:
-

That is certainly an improvement and I like the initiative. 

I would like to give the {{-Dlog4j2.debug}} switch special treatment: note that 
no value is required, just specifying the property is the equivalent of 
{{-Dlog4j2.simplelog.StatusLogger.level=TRACE}}, plus it should persist even if 
the configuration file has a different value in its {{status}} attribute. 

> Provide shorter and more intuitive way to switch on Log4j internal debug 
> logging
> 
>
> Key: LOG4J2-1813
> URL: https://issues.apache.org/jira/browse/LOG4J2-1813
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Configurators
>Affects Versions: 2.8
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.8.1
>
>
> People find it difficult to troubleshoot Log4j 2 configuration issues. Many 
> people don't know what the "status" attribute is for at the beginning of the 
> configuration:
> {code}
>  ...
> {code}
> In addition, the above setting does not take effect until the configuration 
> file is found. If users have trouble making Log4j 2 find their configuration 
> file, the above does not help.
> In such cases, users can enable internal status logging by setting system 
> property {{org.apache.logging.log4j.simplelog.StatusLogger.level}} to 
> {{TRACE}}.
> This is problematic because:
> * It is not well-known (documented in the FAQ and on the configuration page 
> but many people don't know about this feature)
> * The name is a bit... lengthy :-) 
> * Apparently people don't intuitively grasp that "status logging" means the 
> internal log4j 2 debug logging facility.
> * It is confusing that there are two phases (before config file found and 
> after), and the status logger level can be different and needs to be 
> specified separately
> I propose we add a short, intuitive system property that results in _all_ 
> internal Log4j 2 status logging to be printed to the console. When set, this 
> property should even override the configuration status attribute in my 
> opinion.
> Something like {{-Dlog4j2.debug}} (without even requiring a value) would be 
> good, but I'm open to any suggestions.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: Logback performance improvements

[Remko Popma]

#FriendsDontLetFriendsUseJavaUtilLogging

On Sun, Feb 12, 2017 at 11:41 PM, Remko Popma <remko.po...@gmail.com> wrote:

> But I agree it is interesting to see that a simple (RAF)FileAppender will
> outperform async logging if the sustained logging rate is faster than the
> appender can handle for long enough to fill up the queue. I've heard people
> in the high performance computing world mention this but I hadn't seen
> actual numbers until now.
>
> It is good to gain an intuition on these things. Async Loggers (with LMAX
> Disruptor) performance is worse than a plain File but not terrible either.
> Interesting how LogbackAsyncFile seems to suffer more than
> log4j2AsyncAppender.
>
> And yes, JUL is so bad it is not funny any more. We did document that
> <https://logging.apache.org/log4j/2.x/performance.html#fileLoggingComparison>
> but perhaps we need to evangelize it more...
>
>
> On Sun, Feb 12, 2017 at 4:59 PM, Remko Popma <remko.po...@gmail.com>
> wrote:
>
>> The queue is bigger but still fills up quickly because all the benchmarks
>> do is add events as quickly as possible and the FileAppender can't keep up
>> with that rate.
>>
>> Sent from my iPhone
>>
>> On Feb 12, 2017, at 16:19, Apache <ralph.go...@dslextreme.com> wrote:
>>
>> I added the tests so you guys could run them and take a look. I have no
>> problem with the changes being reverted.
>>
>> As I think I said, I expected most of the async appenders to back up. I
>> expected them to be a bit slower, but I didn’t expect them to be as slow as
>> they are when the queue is full. I also don’t understand why AsyncLogger is
>> slower as it should have a large ring buffer if I understand correctly.
>>
>> Ralph
>>
>> On Feb 11, 2017, at 4:36 PM, Remko Popma <remko.po...@gmail.com> wrote:
>>
>> I don't think it is a good idea to mix async tests with sync tests.
>>
>> We already have separate benchmarks for the various ways to log
>> asynchronously, if you want to compare them just run those also.
>>
>> JMH makes it super easy to build benchmarks but we have to be very
>> careful that the test really measures what we want to measure.
>>
>> Asynchronous logging has two "states", queue full and space available. Do
>> we want to measure the queue full state or the space available state (or
>> the transition between the two)?
>>
>> With a normal FileAppender JMH will iterate so fast that the queue
>> immediately fills up. This will likely happen during the warmup iterations
>> (no guarantee of course).
>>
>> What actually happens in that state? We used to block until space becomes
>> available in the queue. What we do now depends on the configured
>> AsyncQueueFullPolicy. Because blocking caused deadlocks in some scenarios,
>> our current default is to bypass the queue and log to the FileAppender
>> directly. I expect that to be slower than the simple FileAppender because
>> of the additional lock contention on the tail of the queue during the
>> attempted thread handover.
>>
>> The "queue full" state is not the normal logging state for an
>> application. If we want to measure this we should move these tests to a
>> separate benchmark that is clearly marked "QueueFullAsyncBenchmark" or
>> something like that.
>> Otherwise people reading these benchmark results will misinterpret them
>> and get confused.
>>
>> The existing Async benchmarks ensure they measure the "queue space
>> available" state.
>>
>> Remko
>>
>> Sent from my iPhone
>>
>> On Feb 12, 2017, at 4:37, Apache <ralph.go...@dslextreme.com> wrote:
>>
>> Just for fun I decided to add some more tests to the file appender
>> benchmark. I’ve checked them in. Please review them to see if everything is
>> configured so the tests make sense.
>>
>> Note that I would expect the async appenders to reduce to the speed of
>> the file appender, since once the queue fills up that is what they are
>> waiting on. But I didn’t set a buffer size for the disruptor or async
>> logger tests so I would have expected those to be quite a bit faster than
>> the regular file test.
>>
>> The one thing that is definitely worth noting is how truly terrible the
>> JUL file appender is. I have to assume that it must be doing an immediate
>> flush on every write.
>>
>> This is on my MacBook Pro - what Ceki would call Fast CPU/Fast SSD
>>
>> Benchmark  Mode  Samples
>> Score Er

Re: Logback performance improvements

[Remko Popma]

But I agree it is interesting to see that a simple (RAF)FileAppender will
outperform async logging if the sustained logging rate is faster than the
appender can handle for long enough to fill up the queue. I've heard people
in the high performance computing world mention this but I hadn't seen
actual numbers until now.

It is good to gain an intuition on these things. Async Loggers (with LMAX
Disruptor) performance is worse than a plain File but not terrible either.
Interesting how LogbackAsyncFile seems to suffer more than
log4j2AsyncAppender.

And yes, JUL is so bad it is not funny any more. We did document that
<https://logging.apache.org/log4j/2.x/performance.html#fileLoggingComparison>
but perhaps we need to evangelize it more...


On Sun, Feb 12, 2017 at 4:59 PM, Remko Popma <remko.po...@gmail.com> wrote:

> The queue is bigger but still fills up quickly because all the benchmarks
> do is add events as quickly as possible and the FileAppender can't keep up
> with that rate.
>
> Sent from my iPhone
>
> On Feb 12, 2017, at 16:19, Apache <ralph.go...@dslextreme.com> wrote:
>
> I added the tests so you guys could run them and take a look. I have no
> problem with the changes being reverted.
>
> As I think I said, I expected most of the async appenders to back up. I
> expected them to be a bit slower, but I didn’t expect them to be as slow as
> they are when the queue is full. I also don’t understand why AsyncLogger is
> slower as it should have a large ring buffer if I understand correctly.
>
> Ralph
>
> On Feb 11, 2017, at 4:36 PM, Remko Popma <remko.po...@gmail.com> wrote:
>
> I don't think it is a good idea to mix async tests with sync tests.
>
> We already have separate benchmarks for the various ways to log
> asynchronously, if you want to compare them just run those also.
>
> JMH makes it super easy to build benchmarks but we have to be very careful
> that the test really measures what we want to measure.
>
> Asynchronous logging has two "states", queue full and space available. Do
> we want to measure the queue full state or the space available state (or
> the transition between the two)?
>
> With a normal FileAppender JMH will iterate so fast that the queue
> immediately fills up. This will likely happen during the warmup iterations
> (no guarantee of course).
>
> What actually happens in that state? We used to block until space becomes
> available in the queue. What we do now depends on the configured
> AsyncQueueFullPolicy. Because blocking caused deadlocks in some scenarios,
> our current default is to bypass the queue and log to the FileAppender
> directly. I expect that to be slower than the simple FileAppender because
> of the additional lock contention on the tail of the queue during the
> attempted thread handover.
>
> The "queue full" state is not the normal logging state for an application.
> If we want to measure this we should move these tests to a separate
> benchmark that is clearly marked "QueueFullAsyncBenchmark" or something
> like that.
> Otherwise people reading these benchmark results will misinterpret them
> and get confused.
>
> The existing Async benchmarks ensure they measure the "queue space
> available" state.
>
> Remko
>
> Sent from my iPhone
>
> On Feb 12, 2017, at 4:37, Apache <ralph.go...@dslextreme.com> wrote:
>
> Just for fun I decided to add some more tests to the file appender
> benchmark. I’ve checked them in. Please review them to see if everything is
> configured so the tests make sense.
>
> Note that I would expect the async appenders to reduce to the speed of the
> file appender, since once the queue fills up that is what they are waiting
> on. But I didn’t set a buffer size for the disruptor or async logger tests
> so I would have expected those to be quite a bit faster than the regular
> file test.
>
> The one thing that is definitely worth noting is how truly terrible the
> JUL file appender is. I have to assume that it must be doing an immediate
> flush on every write.
>
> This is on my MacBook Pro - what Ceki would call Fast CPU/Fast SSD
>
> Benchmark  Mode  Samples
>   Score Error   Units
> o.a.l.l.p.j.FileAppenderBenchmark.julFile thrpt   10
>   69.546 ±   2.635  ops/ms
> o.a.l.l.p.j.FileAppenderBenchmark.log4j1File  thrpt   10
>   783.006 ±  28.138  ops/ms
> o.a.l.l.p.j.FileAppenderBenchmark.log4j2AsyncAppender thrpt   10
>   939.605 ±  38.655  ops/ms
> o.a.l.l.p.j.FileAppenderBenchmark.log4j2AsyncDisruptorthrpt   10
> 1446.522 ±  45.485  ops/ms
> o.a.l.l.p.j.FileAppenderBenchmark.log4j2AsyncLogger   thrpt   10
&

Remko travel plans

[Remko Popma]

I will be travelling to Holland between Feb 15 and March 5th, with sporadic
internet access at times, so I may be slow to reply during this period.

Remko

Re: Logback performance improvements

[Remko Popma]

The queue is bigger but still fills up quickly because all the benchmarks do is 
add events as quickly as possible and the FileAppender can't keep up with that 
rate. 

Sent from my iPhone

> On Feb 12, 2017, at 16:19, Apache <ralph.go...@dslextreme.com> wrote:
> 
> I added the tests so you guys could run them and take a look. I have no 
> problem with the changes being reverted.
> 
> As I think I said, I expected most of the async appenders to back up. I 
> expected them to be a bit slower, but I didn’t expect them to be as slow as 
> they are when the queue is full. I also don’t understand why AsyncLogger is 
> slower as it should have a large ring buffer if I understand correctly.
> 
> Ralph
> 
>> On Feb 11, 2017, at 4:36 PM, Remko Popma <remko.po...@gmail.com> wrote:
>> 
>> I don't think it is a good idea to mix async tests with sync tests. 
>> 
>> We already have separate benchmarks for the various ways to log 
>> asynchronously, if you want to compare them just run those also. 
>> 
>> JMH makes it super easy to build benchmarks but we have to be very careful 
>> that the test really measures what we want to measure. 
>> 
>> Asynchronous logging has two "states", queue full and space available. Do we 
>> want to measure the queue full state or the space available state (or the 
>> transition between the two)?
>> 
>> With a normal FileAppender JMH will iterate so fast that the queue 
>> immediately fills up. This will likely happen during the warmup iterations 
>> (no guarantee of course). 
>> 
>> What actually happens in that state? We used to block until space becomes 
>> available in the queue. What we do now depends on the configured 
>> AsyncQueueFullPolicy. Because blocking caused deadlocks in some scenarios, 
>> our current default is to bypass the queue and log to the FileAppender 
>> directly. I expect that to be slower than the simple FileAppender because of 
>> the additional lock contention on the tail of the queue during the attempted 
>> thread handover. 
>> 
>> The "queue full" state is not the normal logging state for an application. 
>> If we want to measure this we should move these tests to a separate 
>> benchmark that is clearly marked "QueueFullAsyncBenchmark" or something like 
>> that. 
>> Otherwise people reading these benchmark results will misinterpret them and 
>> get confused. 
>> 
>> The existing Async benchmarks ensure they measure the "queue space 
>> available" state. 
>> 
>> Remko 
>> 
>> Sent from my iPhone
>> 
>>> On Feb 12, 2017, at 4:37, Apache <ralph.go...@dslextreme.com> wrote:
>>> 
>>> Just for fun I decided to add some more tests to the file appender 
>>> benchmark. I’ve checked them in. Please review them to see if everything is 
>>> configured so the tests make sense. 
>>> 
>>> Note that I would expect the async appenders to reduce to the speed of the 
>>> file appender, since once the queue fills up that is what they are waiting 
>>> on. But I didn’t set a buffer size for the disruptor or async logger tests 
>>> so I would have expected those to be quite a bit faster than the regular 
>>> file test. 
>>> 
>>> The one thing that is definitely worth noting is how truly terrible the JUL 
>>> file appender is. I have to assume that it must be doing an immediate flush 
>>> on every write.
>>> 
>>> This is on my MacBook Pro - what Ceki would call Fast CPU/Fast SSD
>>> 
>>> Benchmark  Mode  Samples
>>>  Score Error   Units
>>> o.a.l.l.p.j.FileAppenderBenchmark.julFile thrpt   10
>>> 69.546 ±   2.635  ops/ms
>>> o.a.l.l.p.j.FileAppenderBenchmark.log4j1File  thrpt   10   
>>> 783.006 ±  28.138  ops/ms
>>> o.a.l.l.p.j.FileAppenderBenchmark.log4j2AsyncAppender thrpt   10   
>>> 939.605 ±  38.655  ops/ms
>>> o.a.l.l.p.j.FileAppenderBenchmark.log4j2AsyncDisruptorthrpt   10  
>>> 1446.522 ±  45.485  ops/ms
>>> o.a.l.l.p.j.FileAppenderBenchmark.log4j2AsyncLogger   thrpt   10  
>>> 1269.014 ±  27.236  ops/ms
>>> o.a.l.l.p.j.FileAppenderBenchmark.log4j2File  thrpt   10  
>>> 1475.605 ±  74.675  ops/ms
>>> o.a.l.l.p.j.FileAppenderBenchmark.log4j2MMF   thrpt   10  
>>> 2131.240 ± 114.184  ops/ms
>>> o.a.l.l.p.j.FileAppenderBenchmark.log4j2RAF   thrpt   10  
>>> 1

[jira] [Comment Edited] (LOG4J2-1811) Log4j 2 configuration/usage ergonomics

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15862663#comment-15862663
 ] 

Remko Popma edited comment on LOG4J2-1811 at 2/12/17 6:00 AM:
--

I agree the documentation is very good and certainly thorough. On the other 
hand, I have seen comments on StackOverflow indicating that for some users the 
sheer volume of documentation is a bit intimidating and makes it potentially 
harder to find what they are looking for. 

What I have in mind for this ticket is to make small "nudges", changes that 
make Log4j 2 more intuitive to use and configure. Hopefully that makes 
documentation less necessary.


was (Author: rem...@yahoo.com):
I agree our documentation is very good and certainly thorough. On the other 
hand, I have seen comments on StackOverflow indicating that for some users the 
sheer volume of documentation is a bit intimidating and makes it potentially 
harder to find what they are looking for. 

What I have in mind for this ticket is to make small "nudges", changes that 
make Log4j 2 more intuitive to use and configure. Hopefully that makes 
documentation less necessary.

> Log4j 2 configuration/usage ergonomics
> --
>
> Key: LOG4J2-1811
> URL: https://issues.apache.org/jira/browse/LOG4J2-1811
> Project: Log4j 2
>  Issue Type: Epic
>  Components: Configurators, Core
>Reporter: Remko Popma
>
> The vast majority of StackOverflow Log4j 2 questions is related to 
> configuration. The Log4j 2 site offers an extensive manual but apparently 
> many questions remain.
> This ticket aims to make Log4j 2 easier to configure and use. This can take 
> many forms: 
> * adding documentation
> * making documentation easier to find
> * detecting and addressing inconsistencies
> * facilitating debugging
> * showing richer error messages that help users diagnose problems
> * ... etc
> I am making this an epic so the effort can span multiple releases and include 
> many big or small changes.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1811) Log4j 2 configuration/usage ergonomics

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15862663#comment-15862663
 ] 

Remko Popma commented on LOG4J2-1811:
-

I agree our documentation is very good and certainly thorough. On the other 
hand, I have seen comments on StackOverflow indicating that for some users the 
sheer volume of documentation is a bit intimidating and makes it potentially 
harder to find what they are looking for. 

What I have in mind for this ticket is to make small "nudges", changes that 
make Log4j 2 more intuitive to use and configure. Hopefully that makes 
documentation less necessary.

> Log4j 2 configuration/usage ergonomics
> --
>
> Key: LOG4J2-1811
> URL: https://issues.apache.org/jira/browse/LOG4J2-1811
> Project: Log4j 2
>  Issue Type: Epic
>  Components: Configurators, Core
>Reporter: Remko Popma
>
> The vast majority of StackOverflow Log4j 2 questions is related to 
> configuration. The Log4j 2 site offers an extensive manual but apparently 
> many questions remain.
> This ticket aims to make Log4j 2 easier to configure and use. This can take 
> many forms: 
> * adding documentation
> * making documentation easier to find
> * detecting and addressing inconsistencies
> * facilitating debugging
> * showing richer error messages that help users diagnose problems
> * ... etc
> I am making this an epic so the effort can span multiple releases and include 
> many big or small changes.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1813) Provide shorter and more intuitive way to switch on Log4j internal debug logging

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma updated LOG4J2-1813:

Description: 
People find it difficult to troubleshoot Log4j 2 configuration issues. Many 
people don't know what the "status" attribute is for at the beginning of the 
configuration:

{code}
 ...
{code}

In addition, the above setting does not take effect until the configuration 
file is found. If users have trouble making Log4j 2 find their configuration 
file, the above does not help.

In such cases, users can enable internal status logging by setting system 
property {{org.apache.logging.log4j.simplelog.StatusLogger.level}} to {{TRACE}}.

This is problematic because:
* It is not well-known (documented in the FAQ and on the configuration page but 
many people don't know about this feature)
* The name is a bit... lengthy :-) 
* Apparently people don't intuitively grasp that "status logging" means the 
internal log4j 2 debug logging facility.
* It is confusing that there are two phases (before config file found and 
after), and the status logger level can be different and needs to be specified 
separately

I propose we add a short, intuitive system property that results in _all_ 
internal Log4j 2 status logging to be printed to the console. When set, this 
property should even override the configuration status attribute in my opinion.

Something like {{-Dlog4j2.debug}} (without even requiring a value) would be 
good, but I'm open to any suggestions.

  was:
People find it difficult to troubleshoot Log4j 2 configuration issues. Many 
people don't know what the "status" attribute is for at the beginning of the 
configuration:

{code}
 ...
{code}

In addition, the above setting does not take effect until the configuration 
file is found. If users have trouble making Log4j 2 find their configuration 
file, the above does not help.

In such cases, users can enable internal status logging by setting system 
property {{org.apache.logging.log4j.simplelog.StatusLogger.level}} to {{TRACE}}.

This is problematic because:
* It is not well-known (documented in the FAQ and on the configuration page but 
many people don't know about this feature)
* The name is a bit... lengthy :-) 
* Apparently people don't intuitively grasp that "status logging" means the 
internal log4j 2 debug logging facility.
* It is confusing that there are two phases (before config file found and 
after), and the status logger level can be different and needs to be specified 
separately

I propose we add a short, intuitive system property that results in _all_ 
internal Log4j 2 status logging to be printed to the console. When set, this 
property should even override the configuration status attribute in my opinion.

Something like {{-Dlog4j2.debug}} would be good, but I'm open to any 
suggestions.


> Provide shorter and more intuitive way to switch on Log4j internal debug 
> logging
> 
>
> Key: LOG4J2-1813
> URL: https://issues.apache.org/jira/browse/LOG4J2-1813
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Configurators
>Affects Versions: 2.8
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.8.1
>
>
> People find it difficult to troubleshoot Log4j 2 configuration issues. Many 
> people don't know what the "status" attribute is for at the beginning of the 
> configuration:
> {code}
>  ...
> {code}
> In addition, the above setting does not take effect until the configuration 
> file is found. If users have trouble making Log4j 2 find their configuration 
> file, the above does not help.
> In such cases, users can enable internal status logging by setting system 
> property {{org.apache.logging.log4j.simplelog.StatusLogger.level}} to 
> {{TRACE}}.
> This is problematic because:
> * It is not well-known (documented in the FAQ and on the configuration page 
> but many people don't know about this feature)
> * The name is a bit... lengthy :-) 
> * Apparently people don't intuitively grasp that "status logging" means the 
> internal log4j 2 debug logging facility.
> * It is confusing that there are two phases (before config file found and 
> after), and the status logger level can be different and needs to be 
> specified separately
> I propose we add a short, intuitive system property that results in _all_ 
> internal Log4j 2 status logging to be printed to the console. When set, this 
> property should even override the configuration status attribute in my 
> opinion.
> Something like {{-Dlog4j2.debug}} (without even requiring a value) would be 
> good, but I'm open

[jira] [Created] (LOG4J2-1813) Provide shorter and more intuitive way to switch on Log4j internal debug logging

[Remko Popma (JIRA)]

Remko Popma created LOG4J2-1813:
---

 Summary: Provide shorter and more intuitive way to switch on Log4j 
internal debug logging
 Key: LOG4J2-1813
 URL: https://issues.apache.org/jira/browse/LOG4J2-1813
 Project: Log4j 2
  Issue Type: Improvement
  Components: Configurators
Affects Versions: 2.8
Reporter: Remko Popma
Assignee: Remko Popma
 Fix For: 2.8.1


People find it difficult to troubleshoot Log4j 2 configuration issues. Many 
people don't know what the "status" attribute is for at the beginning of the 
configuration:

{code}
 ...
{code}

In addition, the above setting does not take effect until the configuration 
file is found. If users have trouble making Log4j 2 find their configuration 
file, the above does not help.

In such cases, users can enable internal status logging by setting system 
property {{org.apache.logging.log4j.simplelog.StatusLogger.level}} to {{TRACE}}.

This is problematic because:
* It is not well-known (documented in the FAQ and on the configuration page but 
many people don't know about this feature)
* The name is a bit... lengthy :-) 
* Apparently people don't intuitively grasp that "status logging" means the 
internal log4j 2 debug logging facility.
* It is confusing that there are two phases (before config file found and 
after), and the status logger level can be different and needs to be specified 
separately

I propose we add a short, intuitive system property that results in _all_ 
internal Log4j 2 status logging to be printed to the console. When set, this 
property should even override the configuration status attribute in my opinion.

Something like {{-Dlog4j2.debug}} would be good, but I'm open to any 
suggestions.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1812) Improve error message when log4j 2 configuration file not found

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma updated LOG4J2-1812:

Description: 
When configuration fails because no Log4j 2 configuration file is found, the 
following message is logged to the console at ERROR level: 

{code}
No log4j2 configuration file found. Using default configuration: logging only 
errors to the console.
{code}

We should be able to improve this. One idea is to add this:

{code}
No log4j2 configuration file found. Using default configuration: logging only 
errors to the console. Set system property 
'org.apache.logging.log4j.simplelog.StatusLogger.level' to TRACE to show Log4j2 
internal initialization logging.
{code}

Another idea is to dump the contents of the StatusLogger ring buffer to the 
console.

  was:
When configuration fails because no Log4j 2 configuration file is found, the 
following message is logged to the console at ERROR level: 

{code}
No log4j2 configuration file found. Using default configuration: logging only 
errors to the console.
{code}

We should be able to improve this. One idea is to add this:

{code}
No log4j2 configuration file found. Using default configuration: logging only 
errors to the console. Set system property 
'org.apache.logging.log4j.simplelog.StatusLogger.level' to TRACE to show Log4j2 
initialization internal logging.
{code}

Another idea is to dump the contents of the StatusLogger ring buffer to the 
console.


> Improve error message when log4j 2 configuration file not found
> ---
>
> Key: LOG4J2-1812
> URL: https://issues.apache.org/jira/browse/LOG4J2-1812
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Configurators
>Affects Versions: 2.3, 2.4, 2.5, 2.6, 2.7, 2.8
>    Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.8.1
>
>
> When configuration fails because no Log4j 2 configuration file is found, the 
> following message is logged to the console at ERROR level: 
> {code}
> No log4j2 configuration file found. Using default configuration: logging only 
> errors to the console.
> {code}
> We should be able to improve this. One idea is to add this:
> {code}
> No log4j2 configuration file found. Using default configuration: logging only 
> errors to the console. Set system property 
> 'org.apache.logging.log4j.simplelog.StatusLogger.level' to TRACE to show 
> Log4j2 internal initialization logging.
> {code}
> Another idea is to dump the contents of the StatusLogger ring buffer to the 
> console.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1812) Improve error message when log4j 2 configuration file not found

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15862652#comment-15862652
 ] 

Remko Popma commented on LOG4J2-1812:
-

Added above text to the error message in commit 2467ef5.

Please let me know what people think of the idea to dump the StatusLogger ring 
buffer.

> Improve error message when log4j 2 configuration file not found
> ---
>
> Key: LOG4J2-1812
> URL: https://issues.apache.org/jira/browse/LOG4J2-1812
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Configurators
>Affects Versions: 2.3, 2.4, 2.5, 2.6, 2.7, 2.8
>    Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.8.1
>
>
> When configuration fails because no Log4j 2 configuration file is found, the 
> following message is logged to the console at ERROR level: 
> {code}
> No log4j2 configuration file found. Using default configuration: logging only 
> errors to the console.
> {code}
> We should be able to improve this. One idea is to add this:
> {code}
> No log4j2 configuration file found. Using default configuration: logging only 
> errors to the console. Set system property 
> 'org.apache.logging.log4j.simplelog.StatusLogger.level' to TRACE to show 
> Log4j2 initialization internal logging.
> {code}
> Another idea is to dump the contents of the StatusLogger ring buffer to the 
> console.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Created] (LOG4J2-1812) Improve error message when log4j 2 configuration file not found

[Remko Popma (JIRA)]

Remko Popma created LOG4J2-1812:
---

 Summary: Improve error message when log4j 2 configuration file not 
found
 Key: LOG4J2-1812
 URL: https://issues.apache.org/jira/browse/LOG4J2-1812
 Project: Log4j 2
  Issue Type: Improvement
  Components: Configurators
Affects Versions: 2.8, 2.7, 2.6, 2.5, 2.4, 2.3
Reporter: Remko Popma
Assignee: Remko Popma
 Fix For: 2.8.1


When configuration fails because no Log4j 2 configuration file is found, the 
following message is logged to the console at ERROR level: 

{code}
No log4j2 configuration file found. Using default configuration: logging only 
errors to the console.
{code}

We should be able to improve this. One idea is to add this:

{code}
No log4j2 configuration file found. Using default configuration: logging only 
errors to the console. Set system property 
'org.apache.logging.log4j.simplelog.StatusLogger.level' to TRACE to show Log4j2 
initialization internal logging.
{code}

Another idea is to dump the contents of the StatusLogger ring buffer to the 
console.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Created] (LOG4J2-1811) Log4j 2 configuration/usage ergonomics

[Remko Popma (JIRA)]

Remko Popma created LOG4J2-1811:
---

 Summary: Log4j 2 configuration/usage ergonomics
 Key: LOG4J2-1811
 URL: https://issues.apache.org/jira/browse/LOG4J2-1811
 Project: Log4j 2
  Issue Type: Epic
  Components: Configurators, Core
Reporter: Remko Popma


The vast majority of StackOverflow Log4j 2 questions is related to 
configuration. The Log4j 2 site offers an extensive manual but apparently many 
questions remain.

This ticket aims to make Log4j 2 easier to configure and use. This can take 
many forms: 
* adding documentation
* making documentation easier to find
* detecting and addressing inconsistencies
* facilitating debugging
* showing richer error messages that help users diagnose problems
* ... etc

I am making this an epic so the effort can span multiple releases and include 
many big or small changes.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: Logback performance improvements

[Remko Popma]

","Score","Score Error 
>>>>> (99.9%)","Unit"
>>>>> "ch.qos.logback.perf.FileAppenderBenchmark.log4j1File","thrpt",16,10,687.623660,16.114008,"ops/ms"
>>>>> "ch.qos.logback.perf.FileAppenderBenchmark.log4j2File","thrpt",16,10,1203.649145,8.835115,"ops/ms"
>>>>> "ch.qos.logback.perf.FileAppenderBenchmark.log4j2RAF","thrpt",16,10,1266.241778,7.564414,"ops/ms"
>>>>> "ch.qos.logback.perf.FileAppenderBenchmark.logbackFile","thrpt",16,10,789.507183,9.866592,"ops/ms"
>>>>> "Benchmark","Mode","Threads","Samples","Score","Score Error 
>>>>> (99.9%)","Unit"
>>>>> "ch.qos.logback.perf.FileAppenderBenchmark.log4j1File","thrpt",32,10,690.252411,11.587858,"ops/ms"
>>>>> "ch.qos.logback.perf.FileAppenderBenchmark.log4j2File","thrpt",32,10,1514185.478492,126804.168771,"ops/ms"
>>>>> "ch.qos.logback.perf.FileAppenderBenchmark.log4j2RAF","thrpt",32,10,1264.049209,28.309088,"ops/ms"
>>>>> "ch.qos.logback.perf.FileAppenderBenchmark.logbackFile","thrpt",32,10,754.828687,14.865909,"ops/ms"
>>>>> "Benchmark","Mode","Threads","Samples","Score","Score Error 
>>>>> (99.9%)","Unit"
>>>>> "ch.qos.logback.perf.FileAppenderBenchmark.log4j1File","thrpt",64,10,670.498518,11.147198,"ops/ms"
>>>>> "ch.qos.logback.perf.FileAppenderBenchmark.log4j2File","thrpt",64,10,1293.301940,22.687086,"ops/ms"
>>>>> "ch.qos.logback.perf.FileAppenderBenchmark.log4j2RAF","thrpt",64,10,1380.527892,14.907542,"ops/ms"
>>>>> "ch.qos.logback.perf.FileAppenderBenchmark.logbackFile","thrpt",64,10,750.528159,11.356281,"ops/ms"
>>>>> 
>>>>>> On 9 February 2017 at 13:02, Apache <ralph.go...@dslextreme.com> wrote:
>>>>>> You might try running Ceki’s benchmark project on AWS and publish those 
>>>>>> numbers here. He also asked people to publish numbers on the Logback 
>>>>>> user’s list so he can add them to his spreadsheet.
>>>>>> 
>>>>>> From your numbers and the numbers I’ve been getting, it is clear to me 
>>>>>> that the SSDs in Apple’s MacBook’s are pretty awesome. From the hardware 
>>>>>> Remko is listing I’d say his machine is about as old as my other MacBook 
>>>>>> except that he has an SSD that is slightly faster than my hard drive.
>>>>>> 
>>>>>> Ralph
>>>>>> 
>>>>>>> On Feb 9, 2017, at 11:12 AM, Matt Sicker <boa...@gmail.com> wrote:
>>>>>>> 
>>>>>>> Ran on an AWS instance (CentOS 7.2), cpuinfo says 8-core Intel(R) 
>>>>>>> Xeon(R) CPU E5-2666 v3 @ 2.90GHz, not super sure about all the params 
>>>>>>> involved in making the instance, but here's some data (same strangeness 
>>>>>>> with MMF):
>>>>>>> 
>>>>>>> Benchmark Mode  Samples 
>>>>>>> Score Error   Units
>>>>>>> o.a.l.l.p.j.FileAppenderBenchmark.julFilethrpt   10
>>>>>>> 86.867 ±   4.502  ops/ms
>>>>>>> o.a.l.l.p.j.FileAppenderBenchmark.log4j1File thrpt   10   
>>>>>>> 671.156 ±   7.099  ops/ms
>>>>>>> o.a.l.l.p.j.FileAppenderBenchmark.log4j2File thrpt   10  
>>>>>>> 1221.814 ±  22.130  ops/ms
>>>>>>> o.a.l.l.p.j.FileAppenderBenchmark.log4j2MMF  thrpt   10  
>>>>>>> 1178.407 ± 960.141  ops/ms
>>>>>>> o.a.l.l.p.j.FileAppenderBenchmark.log4j2RAF  thrpt   10  
>>>>>>> 1220.746 ±  34.421  ops/ms
>>>>>>> o.a.l.l.p.j.FileAppenderBenchmark.logbackFilethrpt   10   
>>>>>>> 898.122 ±   8.128  ops/ms
>>>>>>> 
>>>>>>>> On 9 February 2017 at 12:02, Matt Sicker <boa...@gmail.com> wrote:
>>>>>>>> Run on a MacBook Pro (Retina, 15-inch, Mid 2015) 2.5 GHz Intel Core 
>>>>>>>> i7. C

Re: Regarding Checkstyle, PMD, and formatting

[Remko Popma]

+1 on braces

On Sat, Feb 11, 2017 at 12:35 AM, Apache <ralph.go...@dslextreme.com> wrote:

> You don’t really have to use final everywhere. If you don’t, Gary will fix
> it ;-)
>
> Actually, I really do prefer most of our check style rules, but not enough
> to yell and scream about it. The one that bothers me the most is that I
> want braces wherever they are optional.
>
> Ralph
>
> On Feb 10, 2017, at 8:09 AM, Matt Sicker <boa...@gmail.com> wrote:
>
> At work, I've switched from final everywhere to final everywhere but local
> variables while maintaining effective finality instead. I just wish Java
> had final be the default.
>
> On 10 February 2017 at 05:34, Remko Popma <remko.po...@gmail.com> wrote:
>
>> Generally agree except that we agreed that the final qualifier was
>> optional.  This may not be easy (or possible?) to verify automatically
>> anyway.
>>
>> Otherwise all looks reasonable.
>>
>> Sent from my iPhone
>>
>> On Feb 10, 2017, at 17:55, Mikael Ståldal <mikael.stal...@magine.com>
>> wrote:
>>
>> Seems reasonable.
>>
>> On Fri, Feb 10, 2017 at 5:56 AM, Gary Gregory <garydgreg...@gmail.com>
>> wrote:
>>
>>> I agree with all that! :-)
>>>
>>> Gary
>>>
>>>
>>> On Feb 9, 2017 7:05 PM, "Matt Sicker" <boa...@gmail.com> wrote:
>>>
>>> I was browsing through the site and took a look at the component
>>> reports. Checkstyle alone seems close to pointless as there are over 200
>>> errors in log4j-api alone. log4j-core has over 2000 errors. Even new files
>>> that were formatted with our formatter settings such as the
>>> CassandraAppender plugin have import ordering errors. I also disagree with
>>> some of the rules configured, but that doesn't really matter when we don't
>>> enforce it in the first place.
>>>
>>> Anyways, what's the point of configuring this and adding checkstyle
>>> comments yet not even using it? The only project I've come across in the
>>> wild so far that has checkstyle configured properly was Spring Boot, and
>>> your pull request has to pass the checkstyle check to even be mergeable.
>>>
>>> Perhaps if we wish to actually use it, we could loosen the rules down to
>>> a much smaller set that actually matches the formatter settings in
>>> src/ide/. If the rules matched our code base, then we could also have
>>> Jenkins run checkstyle checks which would keep us informed when we mess up,
>>> and it would also be useful for pull requests (I've had to reformat many
>>> patches in the past).
>>>
>>> Related, there's the style guide <https://logging.apache.org/lo
>>> g4j/2.x/javastyle.html> which I'm pretty sure I've never even looked at
>>> before. This could also be normalized with our formatter files. I've
>>> generally thought of our code style summarized as:
>>>
>>> * 4 space indent
>>> * use final
>>> * no star imports outside tests (and those should generally be static
>>> imports)
>>> * imports should be in some sort of alphabetical order (this is really
>>> difficult to match between IntelliJ and Eclipse for some reason; I've had
>>> rather obnoxious fights about this in the past thanks to
>>> import-order-induced merge conflicts)
>>> * try to stick to unix line endings, but we're rather mixed still
>>> * every file needs a license header unless it's impossible to include
>>> comments
>>> * use CamelCaseClassNames, even for acronyms
>>> * no hungarian notation or other distracting naming conventions
>>> * otherwise stick to typical Sun style that everyone basically
>>> recognizes (that the JDK doesn't even use itself)
>>>
>>> --
>>> Matt Sicker <boa...@gmail.com>
>>>
>>>
>>>
>>
>>
>> --
>> [image: MagineTV]
>>
>> *Mikael Ståldal*
>> Senior software developer
>>
>> *Magine TV*
>> mikael.stal...@magine.com
>> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com
>> <http://www.magine.com/>
>>
>> Privileged and/or Confidential Information may be contained in this
>> message. If you are not the addressee indicated in this message
>> (or responsible for delivery of the message to such a person), you may
>> not copy or deliver this message to anyone. In such case,
>> you should destroy this message and kindly notify the sender by reply
>> email.
>>
>>
>
>
> --
> Matt Sicker <boa...@gmail.com>
>
>
>

[jira] [Commented] (LOG4J2-1678) (GC) Avoid allocating temporary objects in ThreadContextMapFilter

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15861335#comment-15861335
 ] 

Remko Popma commented on LOG4J2-1678:
-

Can you provide details on why you think there's a problem?

> (GC) Avoid allocating temporary objects in ThreadContextMapFilter
> -
>
> Key: LOG4J2-1678
> URL: https://issues.apache.org/jira/browse/LOG4J2-1678
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Filters
>Affects Versions: 2.7
>    Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.8
>
>
> Make ThreadContextMapFilter garbage-free.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: Regarding Checkstyle, PMD, and formatting

[Remko Popma]

Generally agree except that we agreed that the final qualifier was optional.  
This may not be easy (or possible?) to verify automatically anyway. 

Otherwise all looks reasonable. 

Sent from my iPhone

> On Feb 10, 2017, at 17:55, Mikael Ståldal  wrote:
> 
> Seems reasonable.
> 
>> On Fri, Feb 10, 2017 at 5:56 AM, Gary Gregory  wrote:
>> I agree with all that! :-)
>> 
>> Gary
>> 
>> 
>> On Feb 9, 2017 7:05 PM, "Matt Sicker"  wrote:
>> I was browsing through the site and took a look at the component reports. 
>> Checkstyle alone seems close to pointless as there are over 200 errors in 
>> log4j-api alone. log4j-core has over 2000 errors. Even new files that were 
>> formatted with our formatter settings such as the CassandraAppender plugin 
>> have import ordering errors. I also disagree with some of the rules 
>> configured, but that doesn't really matter when we don't enforce it in the 
>> first place.
>> 
>> Anyways, what's the point of configuring this and adding checkstyle comments 
>> yet not even using it? The only project I've come across in the wild so far 
>> that has checkstyle configured properly was Spring Boot, and your pull 
>> request has to pass the checkstyle check to even be mergeable.
>> 
>> Perhaps if we wish to actually use it, we could loosen the rules down to a 
>> much smaller set that actually matches the formatter settings in src/ide/. 
>> If the rules matched our code base, then we could also have Jenkins run 
>> checkstyle checks which would keep us informed when we mess up, and it would 
>> also be useful for pull requests (I've had to reformat many patches in the 
>> past).
>> 
>> Related, there's the style guide 
>>  which I'm pretty sure 
>> I've never even looked at before. This could also be normalized with our 
>> formatter files. I've generally thought of our code style summarized as:
>> 
>> * 4 space indent
>> * use final
>> * no star imports outside tests (and those should generally be static 
>> imports)
>> * imports should be in some sort of alphabetical order (this is really 
>> difficult to match between IntelliJ and Eclipse for some reason; I've had 
>> rather obnoxious fights about this in the past thanks to 
>> import-order-induced merge conflicts)
>> * try to stick to unix line endings, but we're rather mixed still
>> * every file needs a license header unless it's impossible to include 
>> comments
>> * use CamelCaseClassNames, even for acronyms
>> * no hungarian notation or other distracting naming conventions
>> * otherwise stick to typical Sun style that everyone basically recognizes 
>> (that the JDK doesn't even use itself)
>> 
>> -- 
>> Matt Sicker 
>> 
> 
> 
> 
> -- 
>  
> 
> Mikael Ståldal
> Senior software developer 
> 
> Magine TV
> mikael.stal...@magine.com
> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com 
> 
> Privileged and/or Confidential Information may be contained in this message. 
> If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not 
> copy or deliver this message to anyone. In such case, 
> you should destroy this message and kindly notify the sender by reply email.  
>  

Re: Logback performance improvements

[Remko Popma]

   thrpt   10
>> 1765.340 ±  149.707  ops/ms
>> o.a.l.l.p.j.FileAppenderBenchmark.logbackFilethrpt   10
>> 1192.594 ±   57.777  ops/ms
>>
>> I will try the other machines later and post those results.
>>
>> Ralph
>>
>>
>> On Feb 9, 2017, at 5:22 AM, Apache <ralph.go...@dslextreme.com> wrote:
>>
>> Ceki replied on twitter that the immediateFlush option is now a parameter
>> of the appended, not the encoder, so it looks like the confit needs to be
>> changed and the test rerun.
>>
>> Ralph
>>
>> On Feb 9, 2017, at 3:08 AM, Remko Popma <remko.po...@gmail.com> wrote:
>>
>> FYI, The write and flush methods in BufferedOutputStream are also
>> synchronized, so we won't be able to do away with synchronization
>> completely.
>>
>> In OutputStreamManager we synchronize multiple methods but these are
>> nested calls. I thought reentrant synchronization had negligible overhead
>> but I haven't measured this myself.
>>
>>
>> Sent from my iPhone
>>
>> On Feb 9, 2017, at 2:31, Apache <ralph.go...@dslextreme.com> wrote:
>>
>> I’m pretty sure the problem we have is that a) we are synchronizing many
>> methods and b) we are synchronizing more than just the write.
>> Unfortunately, I can’t figure out how to reduce that based on how dispersed
>> the code has gotten.
>>
>> Ralph
>>
>> On Feb 8, 2017, at 10:14 AM, Apache <ralph.go...@dslextreme.com> wrote:
>>
>> I tried to modify FileManager to just use a BufferedOutputStream but
>> discovered I couldn’t as the layouts now require the ByteBuffer.
>>
>> Ralph
>>
>> On Feb 8, 2017, at 12:14 AM, Apache <ralph.go...@dslextreme.com> wrote:
>>
>> The append method isn’t synchronized but the writeBytes method acquires a
>> lock. His code is actually a lot simpler than ours in that it just uses a
>> BufferedOutputStream and he only obtains the lock when he is writing to it.
>>
>> Ralph
>>
>> On Feb 6, 2017, at 5:23 PM, Matt Sicker <boa...@gmail.com> wrote:
>>
>> I'm not sure if I'm looking in the right place, but a major difference
>> now between Logback's appenders and Log4j's is that Logback isn't
>> synchronized on the append method.
>>
>> On 6 February 2017 at 18:18, Matt Sicker <boa...@gmail.com> wrote:
>>
>>> Is this something we can improve performance on by implementing a file
>>> appender based on FileChannel or AsynchronousFileChannel instead of
>>> OutputStream?
>>>
>>> On 6 February 2017 at 17:50, Apache <ralph.go...@dslextreme.com> wrote:
>>>
>>>> Ceki has updated his numbers to include those reported on the mailing
>>>> list. https://docs.google.com/spreadsheets/d/1cpb5D7qnyye4W0
>>>> RTlHUnXedYK98catNZytYIu5D91m0/edit#gid=0
>>>>
>>>> I haven’t run the tests with Logback 1.2-SNAPSHOT but my numbers for my
>>>> two MacBooks are at https://docs.google.com/spread
>>>> sheets/d/1L67IhmUVvyLBWtC6iq0TMj-j0vrbKsUKWuZV0Nlqisk/edit?usp=sharing
>>>> .
>>>>
>>>> Ralph
>>>>
>>>> On Feb 6, 2017, at 9:33 AM, Apache <ralph.go...@dslextreme.com> wrote:
>>>>
>>>> Yes, that is still the standard approach most people use and is the
>>>> only way to provide a head-to-head comparison against the logging
>>>> frameworks.
>>>>
>>>> Ralph
>>>>
>>>> On Feb 6, 2017, at 8:02 AM, Matt Sicker <boa...@gmail.com> wrote:
>>>>
>>>> This is all in a synchronous appender, right? Either way, that's rather
>>>> interesting.
>>>>
>>>> On 6 February 2017 at 07:54, Apache <ralph.go...@dslextreme.com> wrote:
>>>>
>>>>> Someone posted numbers on the Logback user’s list that match mine.  It
>>>>> shows Logback 1.1.9 was pretty terrible, 1.1.10 is somewhat better and
>>>>> 1.2-SNAPSHOT is on par or slightly better than Log4j 2.
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Feb 5, 2017, at 3:25 PM, Matt Sicker <boa...@gmail.com> wrote:
>>>>>
>>>>> I think we need some comparisons on the log4j side: file appender with
>>>>> 256k buffer size, random access file appender with 256k buffer size (which
>>>>> appears to be the default), and memory mapped file appender. It'd be cool
>>>>> to see how these compose with async logging enabled in both l

Re: Logback performance improvements

[Remko Popma]

can you push the correct config?

On Thu, Feb 9, 2017 at 11:03 PM, Apache <ralph.go...@dslextreme.com> wrote:

> After modifying the configuration the new results on my laptop are:
>
> Benchmark Mode  Samples Score
> Error   Units
> o.a.l.l.p.j.FileAppenderBenchmark.julFilethrpt   1092.580
> ±3.698  ops/ms
> o.a.l.l.p.j.FileAppenderBenchmark.log4j1File thrpt   10   828.707
> ±   55.006  ops/ms
> o.a.l.l.p.j.FileAppenderBenchmark.log4j2File thrpt   10  1647.230
> ±  125.682  ops/ms
> o.a.l.l.p.j.FileAppenderBenchmark.log4j2MMF  thrpt   10  1465.002
> ± 1284.943  ops/ms
> o.a.l.l.p.j.FileAppenderBenchmark.log4j2RAF  thrpt   10  1765.340
> ±  149.707  ops/ms
> o.a.l.l.p.j.FileAppenderBenchmark.logbackFilethrpt   10  1192.594
> ±   57.777  ops/ms
>
> I will try the other machines later and post those results.
>
> Ralph
>
>
> On Feb 9, 2017, at 5:22 AM, Apache <ralph.go...@dslextreme.com> wrote:
>
> Ceki replied on twitter that the immediateFlush option is now a parameter
> of the appended, not the encoder, so it looks like the confit needs to be
> changed and the test rerun.
>
> Ralph
>
> On Feb 9, 2017, at 3:08 AM, Remko Popma <remko.po...@gmail.com> wrote:
>
> FYI, The write and flush methods in BufferedOutputStream are also
> synchronized, so we won't be able to do away with synchronization
> completely.
>
> In OutputStreamManager we synchronize multiple methods but these are
> nested calls. I thought reentrant synchronization had negligible overhead
> but I haven't measured this myself.
>
>
> Sent from my iPhone
>
> On Feb 9, 2017, at 2:31, Apache <ralph.go...@dslextreme.com> wrote:
>
> I’m pretty sure the problem we have is that a) we are synchronizing many
> methods and b) we are synchronizing more than just the write.
> Unfortunately, I can’t figure out how to reduce that based on how dispersed
> the code has gotten.
>
> Ralph
>
> On Feb 8, 2017, at 10:14 AM, Apache <ralph.go...@dslextreme.com> wrote:
>
> I tried to modify FileManager to just use a BufferedOutputStream but
> discovered I couldn’t as the layouts now require the ByteBuffer.
>
> Ralph
>
> On Feb 8, 2017, at 12:14 AM, Apache <ralph.go...@dslextreme.com> wrote:
>
> The append method isn’t synchronized but the writeBytes method acquires a
> lock. His code is actually a lot simpler than ours in that it just uses a
> BufferedOutputStream and he only obtains the lock when he is writing to it.
>
> Ralph
>
> On Feb 6, 2017, at 5:23 PM, Matt Sicker <boa...@gmail.com> wrote:
>
> I'm not sure if I'm looking in the right place, but a major difference now
> between Logback's appenders and Log4j's is that Logback isn't synchronized
> on the append method.
>
> On 6 February 2017 at 18:18, Matt Sicker <boa...@gmail.com> wrote:
>
>> Is this something we can improve performance on by implementing a file
>> appender based on FileChannel or AsynchronousFileChannel instead of
>> OutputStream?
>>
>> On 6 February 2017 at 17:50, Apache <ralph.go...@dslextreme.com> wrote:
>>
>>> Ceki has updated his numbers to include those reported on the mailing
>>> list. https://docs.google.com/spreadsheets/d/1cpb5D7qnyye4W0
>>> RTlHUnXedYK98catNZytYIu5D91m0/edit#gid=0
>>>
>>> I haven’t run the tests with Logback 1.2-SNAPSHOT but my numbers for my
>>> two MacBooks are at https://docs.google.com/spread
>>> sheets/d/1L67IhmUVvyLBWtC6iq0TMj-j0vrbKsUKWuZV0Nlqisk/edit?usp=sharing.
>>>
>>> Ralph
>>>
>>> On Feb 6, 2017, at 9:33 AM, Apache <ralph.go...@dslextreme.com> wrote:
>>>
>>> Yes, that is still the standard approach most people use and is the only
>>> way to provide a head-to-head comparison against the logging frameworks.
>>>
>>> Ralph
>>>
>>> On Feb 6, 2017, at 8:02 AM, Matt Sicker <boa...@gmail.com> wrote:
>>>
>>> This is all in a synchronous appender, right? Either way, that's rather
>>> interesting.
>>>
>>> On 6 February 2017 at 07:54, Apache <ralph.go...@dslextreme.com> wrote:
>>>
>>>> Someone posted numbers on the Logback user’s list that match mine.  It
>>>> shows Logback 1.1.9 was pretty terrible, 1.1.10 is somewhat better and
>>>> 1.2-SNAPSHOT is on par or slightly better than Log4j 2.
>>>>
>>>> Ralph
>>>>
>>>> On Feb 5, 2017, at 3:25 PM, Matt Sicker <boa...@gmail.com> wrote:
>>>>
>>>> I think we need some com

Re: Logback performance improvements

[Remko Popma]

FYI, The write and flush methods in BufferedOutputStream are also synchronized, 
so we won't be able to do away with synchronization completely. 

In OutputStreamManager we synchronize multiple methods but these are nested 
calls. I thought reentrant synchronization had negligible overhead but I 
haven't measured this myself. 


Sent from my iPhone

> On Feb 9, 2017, at 2:31, Apache  wrote:
> 
> I’m pretty sure the problem we have is that a) we are synchronizing many 
> methods and b) we are synchronizing more than just the write. Unfortunately, 
> I can’t figure out how to reduce that based on how dispersed the code has 
> gotten.
> 
> Ralph
> 
>> On Feb 8, 2017, at 10:14 AM, Apache  wrote:
>> 
>> I tried to modify FileManager to just use a BufferedOutputStream but 
>> discovered I couldn’t as the layouts now require the ByteBuffer. 
>> 
>> Ralph
>> 
>>> On Feb 8, 2017, at 12:14 AM, Apache  wrote:
>>> 
>>> The append method isn’t synchronized but the writeBytes method acquires a 
>>> lock. His code is actually a lot simpler than ours in that it just uses a 
>>> BufferedOutputStream and he only obtains the lock when he is writing to it.
>>> 
>>> Ralph
>>> 
 On Feb 6, 2017, at 5:23 PM, Matt Sicker  wrote:
 
 I'm not sure if I'm looking in the right place, but a major difference now 
 between Logback's appenders and Log4j's is that Logback isn't synchronized 
 on the append method.
 
 On 6 February 2017 at 18:18, Matt Sicker  wrote:
> Is this something we can improve performance on by implementing a file 
> appender based on FileChannel or AsynchronousFileChannel instead of 
> OutputStream?
> 
>> On 6 February 2017 at 17:50, Apache  wrote:
>> Ceki has updated his numbers to include those reported on the mailing 
>> list. 
>> https://docs.google.com/spreadsheets/d/1cpb5D7qnyye4W0RTlHUnXedYK98catNZytYIu5D91m0/edit#gid=0
>> 
>> I haven’t run the tests with Logback 1.2-SNAPSHOT but my numbers for my 
>> two MacBooks are at 
>> https://docs.google.com/spreadsheets/d/1L67IhmUVvyLBWtC6iq0TMj-j0vrbKsUKWuZV0Nlqisk/edit?usp=sharing.
>>  
>> 
>> Ralph
>> 
>>> On Feb 6, 2017, at 9:33 AM, Apache  wrote:
>>> 
>>> Yes, that is still the standard approach most people use and is the 
>>> only way to provide a head-to-head comparison against the logging 
>>> frameworks.
>>> 
>>> Ralph
>>> 
 On Feb 6, 2017, at 8:02 AM, Matt Sicker  wrote:
 
 This is all in a synchronous appender, right? Either way, that's 
 rather interesting.
 
 On 6 February 2017 at 07:54, Apache  wrote:
> Someone posted numbers on the Logback user’s list that match mine.  
> It shows Logback 1.1.9 was pretty terrible, 1.1.10 is somewhat better 
> and 1.2-SNAPSHOT is on par or slightly better than Log4j 2.
> 
> Ralph
> 
>> On Feb 5, 2017, at 3:25 PM, Matt Sicker  wrote:
>> 
>> I think we need some comparisons on the log4j side: file appender 
>> with 256k buffer size, random access file appender with 256k buffer 
>> size (which appears to be the default), and memory mapped file 
>> appender. It'd be cool to see how these compose with async logging 
>> enabled in both log4j and logback.
>> 
>> On 5 February 2017 at 16:06, Apache  
>> wrote:
>>> You should run the code at https://github.com/ceki/logback-perf to 
>>> compare your results to Ceki’s.  You also should capture the 
>>> cpubenchmark speed of your processor and get the speed of your hard 
>>> drive. I used Blackmagic speed test on my Mac. I am capturing my 
>>> results in a Google spreadsheet. I will post the like once I have 
>>> it.
>>> 
>>> Ralph
>>> 
 On Feb 5, 2017, at 1:48 PM, Gary Gregory  
 wrote:
 
 If you want, I can run tests on Windows once the build works on 
 Windows again.
 
 Let me know what args/command line...
 
 Gary
 
> On Feb 5, 2017 11:58 AM, "Apache"  
> wrote:
> I guess my MacBook Pro must fit in the Slow CPU/Fast Hard drive 
> category. With Logback 1.10 and -t 4  now get
> 
> Benchmark Mode  Samples   
>  Score   Error  Units
> o.a.l.l.p.j.FileAppenderBenchmark.julFilethrpt   20   
>  98187.673 ±  4935.712  ops/s

Re: Logback performance improvements

[Remko Popma]

I will try taking a look when I get home from work tonight. 

Ceki reported some strange numbers about Log4j 1 outperforming Log4j2 before, 
and when we showed results from 3 or 4 environments that disproved his claims, 
he never really explained how that happened. 

Not sure if there's some issue with his test setup... I would definitely double 
check his numbers. 

Sent from my iPhone

> On Feb 9, 2017, at 14:12, Apache  wrote:
> 
> Logback 1.2 has been released. I just ran our performance benchmarks against 
> it and I am mystified. Logback 1.2 is coming out almost 4 times slower than 
> 1.1.10. Can someone please verify my results?
> 
> I am running them with
> 
> java -jar target/benchmarks.jar ".*FileAppenderBenchmark.*" -f 1 -wi 10 -i 10 
> -t 4 -tu ms
> 
> This is on my MacBook Pro (mid-2015) with a 2.8 GHz Intel Core i7 and a fast 
> SSD.
> 
> Benchmark Mode  Samples Score 
>  Error   Units
> o.a.l.l.p.j.FileAppenderBenchmark.julFilethrpt   1094.052 ±   
> 13.645  ops/ms
> o.a.l.l.p.j.FileAppenderBenchmark.log4j1File thrpt   10   838.130 ±   
> 11.205  ops/ms
> o.a.l.l.p.j.FileAppenderBenchmark.log4j2File thrpt   10  1844.284 ±   
> 72.803  ops/ms
> o.a.l.l.p.j.FileAppenderBenchmark.log4j2MMF  thrpt   10  2041.727 ± 
> 1260.868  ops/ms
> o.a.l.l.p.j.FileAppenderBenchmark.log4j2RAF  thrpt   10  1879.691 ±   
> 93.162  ops/ms
> o.a.l.l.p.j.FileAppenderBenchmark.logbackFilethrpt   10   287.678 ±   
>  8.516  ops/ms
> 
> 
> This is on a Mac Pro (mid-2013) with a 3.5 GHz Intel 6 Core Xeon E5 with an 
> external USB SSD.
> 
> Benchmark Mode  Samples Score 
> Error   Units
> o.a.l.l.p.j.FileAppenderBenchmark.julFilethrpt   1067.616 ±   
> 8.256  ops/ms
> o.a.l.l.p.j.FileAppenderBenchmark.log4j1File thrpt   10   607.507 ±  
> 87.307  ops/ms
> o.a.l.l.p.j.FileAppenderBenchmark.log4j2File thrpt   10   668.316 ± 
> 124.457  ops/ms
> o.a.l.l.p.j.FileAppenderBenchmark.log4j2MMF  thrpt   10  3174.031 ± 
> 149.277  ops/ms
> o.a.l.l.p.j.FileAppenderBenchmark.log4j2RAF  thrpt   10   839.811 ± 
> 154.662  ops/ms
> o.a.l.l.p.j.FileAppenderBenchmark.logbackFilethrpt   10   175.482 ±   
> 0.869  ops/ms
> 
> This is also on the same Map Pro (mid-2013) but using the faster internal SSD.
> 
> Benchmark Mode  Samples Score 
> Error   Units
> o.a.l.l.p.j.FileAppenderBenchmark.julFilethrpt   1075.435 ±   
> 0.287  ops/ms
> o.a.l.l.p.j.FileAppenderBenchmark.log4j1File thrpt   10   735.162 ±   
> 5.182  ops/ms
> o.a.l.l.p.j.FileAppenderBenchmark.log4j2File thrpt   10  1346.217 ±  
> 13.955  ops/ms
> o.a.l.l.p.j.FileAppenderBenchmark.log4j2MMF  thrpt   10  2439.903 ± 
> 355.553  ops/ms
> o.a.l.l.p.j.FileAppenderBenchmark.log4j2RAF  thrpt   10  1507.775 ±   
> 9.600  ops/ms
> o.a.l.l.p.j.FileAppenderBenchmark.logbackFilethrpt   10   184.796 ±   
> 2.052  ops/ms
> 
> Finally, this is on my old MacBook Pro (Late-2011) 2.5GHz Intel Core i5 with 
> an internal hard drive.
> 
> Benchmark Mode  Samples Score 
>  Error   Units
> o.a.l.l.p.j.FileAppenderBenchmark.julFilethrpt   1039.181 ±   
>  3.315  ops/ms
> o.a.l.l.p.j.FileAppenderBenchmark.log4j1File thrpt   10   485.160 ±   
> 98.892  ops/ms
> o.a.l.l.p.j.FileAppenderBenchmark.log4j2File thrpt   10   551.578 ±  
> 120.902  ops/ms
> o.a.l.l.p.j.FileAppenderBenchmark.log4j2MMF  thrpt   10  1720.083 ± 
> 1113.734  ops/ms
> o.a.l.l.p.j.FileAppenderBenchmark.log4j2RAF  thrpt   10   561.398 ±  
> 226.339  ops/ms
> o.a.l.l.p.j.FileAppenderBenchmark.logbackFilethrpt   10   161.530 ±   
>  4.585  ops/ms
> 
> The news page at Logback says that it has major performance improvements but 
> these numbers are 3-4 times slower than what I got with 1.1.10.
> 
> Ralph
> 
> 
>  
> 
> 
> 
> 
> 
> 
>> On Feb 8, 2017, at 10:31 AM, Apache  wrote:
>> 
>> I’m pretty sure the problem we have is that a) we are synchronizing many 
>> methods and b) we are synchronizing more than just the write. Unfortunately, 
>> I can’t figure out how to reduce that based on how dispersed the code has 
>> gotten.
>> 
>> Ralph
>> 
>>> On Feb 8, 2017, at 10:14 AM, Apache  wrote:
>>> 
>>> I tried to modify FileManager to just use a BufferedOutputStream but 
>>> discovered I couldn’t as the layouts now require the ByteBuffer. 
>>> 
>>> Ralph
>>> 
 On Feb 8, 2017, at 12:14 AM, Apache  wrote:
 
 The append method isn’t synchronized but the writeBytes method acquires a 
 lock. His code is actually a lot simpler than ours in that it just uses a 
 BufferedOutputStream and he only obtains the 

Re: Logback performance improvements

[Remko Popma]

Is it possible that the memory mapped file starts resizing and remapping at 
this point?

Sent from my iPhone

> On Feb 8, 2017, at 15:12, Apache <ralph.go...@dslextreme.com> wrote:
> 
> I used a ThreadLocal byte buffer and wrote to the file channel and if 
> anything, it performed slightly worse. This is probably because I had to 
> write after ever event, not when the buffer was full, otherwise the ordering 
> of events in the output would get messed up.
> 
> I decided to throw the MemoryMappedFileAppender into the mix and I got some 
> very strange behavior. Using Logback 1.1.10 the overall results with 4 
> threads were:
> 
> Benchmark Mode  Samples Score 
> Error   Units
> o.a.l.l.p.j.FileAppenderBenchmark.julFilethrpt   1098.886 ±  
> 10.855  ops/ms
> o.a.l.l.p.j.FileAppenderBenchmark.log4j1File thrpt   10   826.640 ±  
> 14.219  ops/ms
> o.a.l.l.p.j.FileAppenderBenchmark.log4j2File thrpt   10  1861.518 ± 
> 139.885  ops/ms
> o.a.l.l.p.j.FileAppenderBenchmark.log4j2MMF  thrpt   10  1478.489 ± 
> 970.526  ops/ms
> o.a.l.l.p.j.FileAppenderBenchmark.log4j2RAF  thrpt   10  2023.783 ±  
> 41.284  ops/ms
> o.a.l.l.p.j.FileAppenderBenchmark.logbackFilethrpt   10   997.495 ±  
> 42.801  ops/ms
> 
> What is strange is the actual output from the run for the 
> MemoryMappedFileAppender. You will notice that it starts off like a bat out 
> of hell but then bogs down terribly. I’d love to know why.
> 
> # VM invoker: 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_65.jdk/Contents/Home/jre/bin/java
> # VM options: 
> # Warmup: 10 iterations, 1 s each
> # Measurement: 10 iterations, 1 s each
> # Timeout: 10 min per iteration
> # Threads: 4 threads, will synchronize iterations
> # Benchmark mode: Throughput, ops/time
> # Benchmark: org.apache.logging.log4j.perf.jmh.FileAppenderBenchmark.log4j2MMF
> 
> # Run progress: 50.00% complete, ETA 00:01:14
> # Fork: 1 of 1
> # Warmup Iteration   1: 2546.240 ops/ms
> # Warmup Iteration   2: 3071.504 ops/ms
> # Warmup Iteration   3: 2980.503 ops/ms
> # Warmup Iteration   4: 2709.490 ops/ms
> # Warmup Iteration   5: 2661.919 ops/ms
> # Warmup Iteration   6: 2610.875 ops/ms
> # Warmup Iteration   7: 2663.431 ops/ms
> # Warmup Iteration   8: 2675.847 ops/ms
> # Warmup Iteration   9: 2755.735 ops/ms
> # Warmup Iteration  10: 2666.353 ops/ms
> Iteration   1: 2577.419 ops/ms
> Iteration   2: 2804.161 ops/ms
> Iteration   3: 1179.059 ops/ms
> Iteration   4: 1167.719 ops/ms
> Iteration   5: 1170.686 ops/ms
> Iteration   6: 1246.053 ops/ms
> Iteration   7: 1173.593 ops/ms
> Iteration   8: 1196.317 ops/ms
> Iteration   9: 1127.199 ops/ms
> Iteration  10: 1142.684 ops/ms
> 
> Ralph
> 
> 
>> On Feb 7, 2017, at 10:55 AM, Apache <ralph.go...@dslextreme.com> wrote:
>> 
>> True, but I would still like to also see what difference it makes using the 
>> FileChannel instead of the OutputStream.
>> 
>> Ralph
>> 
>>> On Feb 7, 2017, at 9:45 AM, Remko Popma <remko.po...@gmail.com> wrote:
>>> 
>>> That is all doable but it may be a good idea to test if that is really 
>>> where the bottleneck is. 
>>> We could try whether we get better numbers if we remove the current 
>>> synchronization (ignoring any scrambled output, just for testing purposes).
>>> 
>>> 
>>>> On Wed, Feb 8, 2017 at 1:40 AM, Apache <ralph.go...@dslextreme.com> wrote:
>>>> In looking at FileManager and OutputStreamManager it does have a 
>>>> ByteBuffer but it requires synchronization. I am thinking it might make 
>>>> more sense to have a ThreadLocal ByteBuffer and then pass that to 
>>>> FileChannel.write() so that no synchronization is required.
>>>> 
>>>> Ralph
>>>> 
>>>>> On Feb 7, 2017, at 9:36 AM, Matt Sicker <boa...@gmail.com> wrote:
>>>>> 
>>>>> Can't we use the ByteBuffers introduced in the GC-free epic? I was under 
>>>>> the impression that byte arrays being passed to appenders was created 
>>>>> from a ByteBuffer at this point, though I haven't really taken a close 
>>>>> look at this.
>>>>> 
>>>>> On 7 February 2017 at 10:05, Apache <ralph.go...@dslextreme.com> wrote:
>>>>>> A FileChannel is guaranteed to be thread safe. You can obtain a 
>>>>>> FileChannel from a FlieOutputStream, so that would seem to imply that 
>>>>>> FileOutputStream might be thread-safe, but you can’t really know that 
&

Re: Logback performance improvements

[Remko Popma]

That is all doable but it may be a good idea to test if that is really
where the bottleneck is.
We could try whether we get better numbers if we remove the current
synchronization (ignoring any scrambled output, just for testing purposes).


On Wed, Feb 8, 2017 at 1:40 AM, Apache <ralph.go...@dslextreme.com> wrote:

> In looking at FileManager and OutputStreamManager it does have a
> ByteBuffer but it requires synchronization. I am thinking it might make
> more sense to have a ThreadLocal ByteBuffer and then pass that to
> FileChannel.write() so that no synchronization is required.
>
> Ralph
>
> On Feb 7, 2017, at 9:36 AM, Matt Sicker <boa...@gmail.com> wrote:
>
> Can't we use the ByteBuffers introduced in the GC-free epic? I was under
> the impression that byte arrays being passed to appenders was created from
> a ByteBuffer at this point, though I haven't really taken a close look at
> this.
>
> On 7 February 2017 at 10:05, Apache <ralph.go...@dslextreme.com> wrote:
>
>> A FileChannel is guaranteed to be thread safe. You can obtain a
>> FileChannel from a FlieOutputStream, so that would seem to imply that
>> FileOutputStream might be thread-safe, but you can’t really know that
>> without looking at the source. The problem is that FileChannel.write()
>> takes a ByteBuffer whereas FileOutputStream.write() accepts a byte array.
>> To be thread safe it would have to safely copy the byte array into the byte
>> buffer to pass to the FileChannel. But FileOutputStream doesn’t use the
>> FileChannel at all in Java 7. It calls a native method that doesn’t specify
>> whether it is thread-safe or not, so simply removing the synchronization
>> isn’t guaranteed to work properly.
>>
>> OTOH, RandomAccessFile doesn’t say that it is thread-safe either and we
>> are not synchronizing writes to it.
>>
>> Ralph
>>
>> On Feb 7, 2017, at 8:37 AM, Matt Sicker <boa...@gmail.com> wrote:
>>
>> I looked at 1.2-SNAPSHOT and 1.1.10 and saw nothing special other than a
>> lack of a synchronized keyword on the equivalent append method. Perhaps he
>> figured out a simpler way to emulate locking?
>>
>> I've been working with async/non-blocking streaming APIs for long enough
>> now that I can't even remember the last time I had to write an actual lock.
>>
>> On 6 February 2017 at 22:02, Apache <ralph.go...@dslextreme.com> wrote:
>>
>>> Logback 1.2-SNAPSHOT
>>>
>>> Ralph
>>>
>>> On Feb 6, 2017, at 8:29 PM, Remko Popma <remko.po...@gmail.com> wrote:
>>>
>>> Sorry what 1.2 do you mean?
>>>
>>> Sent from my iPhone
>>>
>>> On Feb 7, 2017, at 11:06, Apache <ralph.go...@dslextreme.com> wrote:
>>>
>>> In 1.2?  That may work for a FileOutputStream but it isn’t guaranteed to
>>> work for others.
>>>
>>> Ralph
>>>
>>> On Feb 6, 2017, at 5:23 PM, Matt Sicker <boa...@gmail.com> wrote:
>>>
>>> I'm not sure if I'm looking in the right place, but a major difference
>>> now between Logback's appenders and Log4j's is that Logback isn't
>>> synchronized on the append method.
>>>
>>> On 6 February 2017 at 18:18, Matt Sicker <boa...@gmail.com> wrote:
>>>
>>>> Is this something we can improve performance on by implementing a file
>>>> appender based on FileChannel or AsynchronousFileChannel instead of
>>>> OutputStream?
>>>>
>>>> On 6 February 2017 at 17:50, Apache <ralph.go...@dslextreme.com> wrote:
>>>>
>>>>> Ceki has updated his numbers to include those reported on the mailing
>>>>> list. https://docs.google.com/spreadsheets/d/1cpb5D7qnyye4W0
>>>>> RTlHUnXedYK98catNZytYIu5D91m0/edit#gid=0
>>>>>
>>>>> I haven’t run the tests with Logback 1.2-SNAPSHOT but my numbers for
>>>>> my two MacBooks are at https://docs.google.com/spread
>>>>> sheets/d/1L67IhmUVvyLBWtC6iq0TMj-j0vrbKsUKWuZV0Nlqisk/edit?usp=sharing
>>>>> .
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Feb 6, 2017, at 9:33 AM, Apache <ralph.go...@dslextreme.com> wrote:
>>>>>
>>>>> Yes, that is still the standard approach most people use and is the
>>>>> only way to provide a head-to-head comparison against the logging
>>>>> frameworks.
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Feb 6, 2017, at 8:02 AM, Matt Sicker <boa...@gmail.com> wrote:
>>>>>
&

Re: Logback performance improvements

[Remko Popma]

Sorry what 1.2 do you mean? 

Sent from my iPhone

> On Feb 7, 2017, at 11:06, Apache  wrote:
> 
> In 1.2?  That may work for a FileOutputStream but it isn’t guaranteed to work 
> for others.
> 
> Ralph
> 
>> On Feb 6, 2017, at 5:23 PM, Matt Sicker  wrote:
>> 
>> I'm not sure if I'm looking in the right place, but a major difference now 
>> between Logback's appenders and Log4j's is that Logback isn't synchronized 
>> on the append method.
>> 
>> On 6 February 2017 at 18:18, Matt Sicker  wrote:
>>> Is this something we can improve performance on by implementing a file 
>>> appender based on FileChannel or AsynchronousFileChannel instead of 
>>> OutputStream?
>>> 
 On 6 February 2017 at 17:50, Apache  wrote:
 Ceki has updated his numbers to include those reported on the mailing 
 list. 
 https://docs.google.com/spreadsheets/d/1cpb5D7qnyye4W0RTlHUnXedYK98catNZytYIu5D91m0/edit#gid=0
 
 I haven’t run the tests with Logback 1.2-SNAPSHOT but my numbers for my 
 two MacBooks are at 
 https://docs.google.com/spreadsheets/d/1L67IhmUVvyLBWtC6iq0TMj-j0vrbKsUKWuZV0Nlqisk/edit?usp=sharing.
  
 
 Ralph
 
> On Feb 6, 2017, at 9:33 AM, Apache  wrote:
> 
> Yes, that is still the standard approach most people use and is the only 
> way to provide a head-to-head comparison against the logging frameworks.
> 
> Ralph
> 
>> On Feb 6, 2017, at 8:02 AM, Matt Sicker  wrote:
>> 
>> This is all in a synchronous appender, right? Either way, that's rather 
>> interesting.
>> 
>> On 6 February 2017 at 07:54, Apache  wrote:
>>> Someone posted numbers on the Logback user’s list that match mine.  It 
>>> shows Logback 1.1.9 was pretty terrible, 1.1.10 is somewhat better and 
>>> 1.2-SNAPSHOT is on par or slightly better than Log4j 2.
>>> 
>>> Ralph
>>> 
 On Feb 5, 2017, at 3:25 PM, Matt Sicker  wrote:
 
 I think we need some comparisons on the log4j side: file appender with 
 256k buffer size, random access file appender with 256k buffer size 
 (which appears to be the default), and memory mapped file appender. 
 It'd be cool to see how these compose with async logging enabled in 
 both log4j and logback.
 
 On 5 February 2017 at 16:06, Apache  wrote:
> You should run the code at https://github.com/ceki/logback-perf to 
> compare your results to Ceki’s.  You also should capture the 
> cpubenchmark speed of your processor and get the speed of your hard 
> drive. I used Blackmagic speed test on my Mac. I am capturing my 
> results in a Google spreadsheet. I will post the like once I have it.
> 
> Ralph
> 
>> On Feb 5, 2017, at 1:48 PM, Gary Gregory  
>> wrote:
>> 
>> If you want, I can run tests on Windows once the build works on 
>> Windows again.
>> 
>> Let me know what args/command line...
>> 
>> Gary
>> 
>>> On Feb 5, 2017 11:58 AM, "Apache"  
>>> wrote:
>>> I guess my MacBook Pro must fit in the Slow CPU/Fast Hard drive 
>>> category. With Logback 1.10 and -t 4  now get
>>> 
>>> Benchmark Mode  Samples 
>>>Score   Error  Units
>>> o.a.l.l.p.j.FileAppenderBenchmark.julFilethrpt   20
>>> 98187.673 ±  4935.712  ops/s
>>> o.a.l.l.p.j.FileAppenderBenchmark.log4j1File thrpt   20   
>>> 842374.496 ±  6762.712  ops/s
>>> o.a.l.l.p.j.FileAppenderBenchmark.log4j2File thrpt   20  
>>> 1853062.583 ± 67032.225  ops/s
>>> o.a.l.l.p.j.FileAppenderBenchmark.log4j2RAF  thrpt   20  
>>> 2036011.226 ± 53208.281  ops/s
>>> o.a.l.l.p.j.FileAppenderBenchmark.logbackFilethrpt   20   
>>> 999667.438 ± 12074.003  ops/s
>>> 
>>> I’ll have to try this on one my VMs at work. We don’t run anything 
>>> directly on bare metal any more.
>>> 
>>> Ralph
>>> 
 On Feb 5, 2017, at 9:40 AM, Apache  
 wrote:
 
 Ceki finally fixed some of the performance problems in the 
 FileAppender. See https://logback.qos.ch/news.html and 
 https://docs.google.com/spreadsheets/d/1cpb5D7qnyye4W0RTlHUnXedYK98catNZytYIu5D91m0/edit#gid=0.
  I suspect we have a few optimizations we can make.
 
 Ralph
>>> 
> 
 
 
 
 -- 
 Matt Sicker 

Re: Java 9

[Remko Popma]

Can you point me at some info on that? What massive changes are needed?

Remko

Sent from my iPhone

> On Feb 7, 2017, at 1:36, Apache <ralph.go...@dslextreme.com> wrote:
> 
> I fixed the only problem I could find last week. However, we still have more 
> to do as we really need to support the StackWalker API and the “right” way to 
> do it would require massive changes. I also need to benchmark the cost of 
> invoking the StackWalker API to return the method’s caller to see what the 
> impact would be to do it on every logging call.
> 
> Ralph
> 
>> On Feb 6, 2017, at 9:15 AM, Matt Sicker <boa...@gmail.com> wrote:
>> 
>> I remember Ralph mentioned that he tested it out and found that it worked 
>> pretty well. See issue: <https://issues.apache.org/jira/browse/LOG4J2-1359>
>> 
>> On 6 February 2017 at 09:56, Remko Popma <remko.po...@gmail.com> wrote:
>>> I haven't had a chance to look at this yet, but is the new stack walking 
>>> API in Java 9 of any use for us? I believe applications/libraries like 
>>> Log4j were supposed to be the drivers behind this feature, but last time I 
>>> checked they were not going to cater for our use case (inspect the stack 
>>> from the bottom up)... 
>>> 
>>> From a functional point of view, is anybody aware of anything outstanding 
>>> we need to fix for Log4j 2 to work correctly on Java 9?
>>> 
>>> Remko
>> 
>> 
>> 
>> -- 
>> Matt Sicker <boa...@gmail.com>
> 

Java 9

[Remko Popma]

I haven't had a chance to look at this yet, but is the new stack walking
API in Java 9 of any use for us? I believe applications/libraries like
Log4j were supposed to be the drivers behind this feature, but last time I
checked they were not going to cater for our use case (inspect the stack
from the bottom up)...

>From a functional point of view, is anybody aware of anything outstanding
we need to fix for Log4j 2 to work correctly on Java 9?

Remko

[jira] [Commented] (LOG4J2-1809) Add global configuration environment SPI

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15853416#comment-15853416
 ] 

Remko Popma commented on LOG4J2-1809:
-

Where will this interface be used? Inside PropertiesUtil?

> Add global configuration environment SPI
> 
>
> Key: LOG4J2-1809
> URL: https://issues.apache.org/jira/browse/LOG4J2-1809
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: API
>Reporter: Matt Sicker
>Assignee: Matt Sicker
>
> Create a service provider interface for global configuration property 
> sources. Currently, we support two built in sources: properties loaded from a 
> classpath resource file named "log4j2.component.properties" and from system 
> properties. This feature will abstract those two sources into an SPI with 
> default implementations of those two sources as well as environment variables.
> This SPI should be specified through the standard 
> [ServiceLoader|https://docs.oracle.com/javase/8/docs/api/java/util/ServiceLoader.html]
>  API so as to make this simpler to support for users in any environment.
> Related to LOG4J2-1431.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1808) java.lang.NoSuchMethodError: org.apache.logging.log4j.ThreadContext.getThreadContextMap()

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15853001#comment-15853001
 ] 

Remko Popma commented on LOG4J2-1808:
-

The method {{ThreadContext.getThreadContextMap()}} was added in 2.8. The only 
way I can imagine this error would happen is that an older version of the 
log4j-api module (say, log4j-api-2.7.jar) is also on the classpath, and it is 
loaded _before_ the log4j-api-2.8.jar. 

Can you verify the full classpath of the application? Alternatively, to verify 
which jar file the class is loaded from, you can do:

{code}
System.out.println("ThreadContext from: " +  ThreadContext.class.getResource("/"
 + ThreadContext.class.getName().replace('.', '/') + ".class"));
{code}

> java.lang.NoSuchMethodError: 
> org.apache.logging.log4j.ThreadContext.getThreadContextMap()
> -
>
> Key: LOG4J2-1808
> URL: https://issues.apache.org/jira/browse/LOG4J2-1808
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.8
> Environment: Google AppEngine local development server
>Reporter: Lukasz Lenart
>
> {noformat}
> [INFO] Feb 04, 2017 4:38:37 PM com.google.apphosting.utils.jetty.JettyLogger 
> warn
> [INFO] WARNING: failed 
> com.google.appengine.tools.development.DevAppEngineWebAppContext@454577f3{/,/Users/lukaszlenart/Projects/Private/gruuf-webapp/target/gruuf-webapp-1.0-SNAPSHOT}:
>  java.lang.NoSuchMethodError: 
> org.apache.logging.log4j.ThreadContext.getThreadContextMap()Lorg/apache/logging/log4j/spi/ReadOnlyThreadContextMap;
> [INFO] Feb 04, 2017 4:38:37 PM com.google.apphosting.utils.jetty.JettyLogger 
> warn
> [INFO] WARNING: failed JettyContainerService$ApiProxyHandler@53c6160c: 
> java.lang.NoSuchMethodError: 
> org.apache.logging.log4j.ThreadContext.getThreadContextMap()Lorg/apache/logging/log4j/spi/ReadOnlyThreadContextMap;
> [INFO] Feb 04, 2017 4:38:37 PM com.google.apphosting.utils.jetty.JettyLogger 
> warn
> [INFO] WARNING: Error starting handlers
> [INFO] java.lang.NoSuchMethodError: 
> org.apache.logging.log4j.ThreadContext.getThreadContextMap()Lorg/apache/logging/log4j/spi/ReadOnlyThreadContextMap;
> [INFO]at 
> org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createDefaultInjector(ContextDataInjectorFactory.java:83)
> [INFO]at 
> org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createInjector(ContextDataInjectorFactory.java:67)
> [INFO]at 
> org.apache.logging.log4j.core.lookup.ContextMapLookup.(ContextMapLookup.java:34)
> [INFO]at 
> org.apache.logging.log4j.core.lookup.Interpolator.(Interpolator.java:117)
> [INFO]at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.(AbstractConfiguration.java:125)
> [INFO]at 
> org.apache.logging.log4j.core.config.NullConfiguration.(NullConfiguration.java:32)
> [INFO]at 
> org.apache.logging.log4j.core.LoggerContext.(LoggerContext.java:77)
> [INFO]at 
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.createContext(ClassLoaderContextSelector.java:171)
> [INFO]at 
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.locateContext(ClassLoaderContextSelector.java:145)
> [INFO]at 
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:70)
> [INFO]at 
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:57)
> [INFO]at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:147)
> [INFO]at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
> [INFO]at 
> org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
> [INFO]at 
> org.apache.logging.log4j.LogManager.getLogger(LogManager.java:551)
> [INFO]at 
> org.apache.struts2.tiles.StrutsTilesListener.(StrutsTilesListener.java:34)
> [INFO]at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> [INFO]at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> [INFO]at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> [INFO]at 
> java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> [INFO]at java.lang.Class.newInstance(Class.java:383)
> [INFO]at 
> org.mortbay.jetty.webapp.WebXmlConfigura

Re: SyslogAppender parameter name change

[Remko Popma]

Thanks Matt!
Sam, can you check if this resolves the issue? 

Sent from my iPhone

> On Feb 4, 2017, at 14:49, Matt Sicker <boa...@gmail.com> wrote:
> 
> I see. There were a couple issues with @PluginAliases for SyslogAppender 
> specifically. Fixed in master.
> 
>> On 3 February 2017 at 10:23, Matt Sicker <boa...@gmail.com> wrote:
>> Plugins can have aliases via @PluginAliases (see for example 
>> <https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/mom/JmsAppender.java>),
>>  don't recall if attributes are supported. If not, that's a feature we can 
>> support for sure.
>> 
>>> On 2 February 2017 at 18:27, Gary Gregory <garydgreg...@gmail.com> wrote:
>>> Darn, I apologize for that one. 
>>> 
>>> Gary
>>> 
>>>> On Thu, Feb 2, 2017 at 4:09 PM, Remko Popma <remko.po...@gmail.com> wrote:
>>>> Sorry for that and thanks for letting us know!
>>>> 
>>>> I wonder if parameter names can have aliases so we can support both the 
>>>> old and the new name without causing users inconvenience. If possible we 
>>>> should address this for 2.8.1. 
>>>> 
>>>> Remko 
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>>> On Feb 3, 2017, at 4:13, Sam Beroz <sambe...@gmail.com> wrote:
>>>>> 
>>>>> The reconnectionDelayMillis parameter was renamed to 
>>>>> reconnectDelayMillis. After updating to release 2.8 I noticed that I was 
>>>>> getting the following error:
>>>>> 
>>>>> ERROR Syslog contains an invalid element or attribute 
>>>>> "reconnectionDelayMillis"
>>>>> 
>>>>> It appears that change was part of this commit:
>>>>> 
>>>>> commit ed828be67a23ee3513cafc9d2fd0ff16a26c7013
>>>>> Author: Gary Gregory <ggreg...@apache.org>
>>>>> Date:   Mon Nov 14 15:11:47 2016 -0800
>>>>> 
>>>>> [LOG4J2-1709]
>>>>> 
>>>>> Add a Builder to SyslogAppender and deprecate
>>>>> SyslogAppender.createAppender().
>>>>> 
>>>>> 
>>>>> The documentation 
>>>>> (https://logging.apache.org/log4j/2.x/manual/appenders.html#SyslogAppender)
>>>>>  still has the parameter listed as "reconnectionDelayMillis" but the code 
>>>>> is now obviously looking for "reconnectDelayMillis". I'm going to change 
>>>>> my config to use the new name, but I thought I'd point out the disconnect 
>>>>> as it had me confused for a bit. Thanks - Sam
>>> 
>>> 
>>> 
>>> -- 
>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
>>> Java Persistence with Hibernate, Second Edition 
>>> JUnit in Action, Second Edition 
>>> Spring Batch in Action 
>>> Blog: http://garygregory.wordpress.com 
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>> 
>> 
>> 
>> -- 
>> Matt Sicker <boa...@gmail.com>
> 
> 
> 
> -- 
> Matt Sicker <boa...@gmail.com>