Re: Docs?

[Ralph Goers]

Logging Services uses CTR. Reviews are never required.  However, the process 
for web sites is to update the ask-staging branch, push that, verify the change 
on the staged site, and then checkout the asf-site branch and do “git rebase 
asf-staging”.

Ralph

> On Nov 16, 2022, at 11:39 PM, Davyd McColl  wrote:
> 
> Thanks Ralph, you're right - the link should be to 
> ../../log4net-2.0.8/release/sdk. The api hasn't changed since then - 
> fortunately for me, because I haven't been able to successfully re-generate 
> the sdk documentation. One of the items on my never-ending list of TODOs is 
> to update the way those docs are generated, using new tooling, so perhaps the 
> docs (a) could be auto-generated and (b) will look a little nicer.
> 
> Can I just update my `asf-site` branch and push? no need for review, surely?
> 
> -d
> 
> On 2022-11-17 08:16:26, Ralph Goers  wrote:
> Looking at .htaccess it seems everything is directed to log4net-2.0.15.
> In log4net-2.0.15/release I see
> 
> sdk -> log4net-2.0.8/release/sdk
> 
> I think that symlink is wrong and should be ../../log4net-2.0.8/release/sdk - 
> assuming of course you want 2.0.15 to reference something in 2.0.8.
> 
> Ralph
> 
>> On Nov 16, 2022, at 9:08 PM, Davyd McColl wrote:
>> 
>> Ralph, I'd appreciate any help here. Seems there's a permissions error or 
>> something - sdk docs links return a 403.
>> 
>> -d
>> 
>> 
>> On 16 November 2022 23:22:26 Alex Winfield <7nil...@gmail.com> wrote:
>> 
>>> Where should I look for the docs?
>>> 
>>> All of the examples point to dead links:
>>> https://logging.apache.org/log4net/release/config-examples.html
>>> 
>>> Sample code online doesn't appear to actually work (%aspnet-context appears
>>> to be parsed as just %a, with "spnet-context" as a static string).
>>> 
>>> I can see that there definitely is something for handling asp.net contexts (
>>> https://git-wip-us.apache.org/repos/asf?p=logging-log4net.git;a=blob_plain;f=src/log4net/Layout/Pattern/AspNetContextPatternConverter.cs;hb=HEAD),
>>> but I have no idea why it isn't working or what I need to do to enable it.
>>> 
>>> I'm just very confused on what format properties are available, which may
>>> have been renamed over time, etc
>>> 
>>> I was able to get what I wanted to work using middleware, but it does feel
>>> weird that there's so little documentation available. I'd appreciate any
>>> links that could help (I feel like this property is probably already
>>> available and not need an entire middleware just to hook into log4net lol)
>>> 
>>> Also, log4net-u...@logging.apache.org appears to not have anyone watching
>>> answering questions. If it isn't being used, it should probably be removed
>>> from the docs as a valid way to get help.
> 

Re: Docs?

[Ralph Goers]

Looking at .htaccess it seems everything is directed to log4net-2.0.15.
In log4net-2.0.15/release I see 

sdk -> log4net-2.0.8/release/sdk

I think that symlink is wrong and should be ../../log4net-2.0.8/release/sdk - 
assuming of course you want 2.0.15 to reference something in 2.0.8.

Ralph

> On Nov 16, 2022, at 9:08 PM, Davyd McColl  wrote:
> 
> Ralph, I'd appreciate any help here. Seems there's a permissions error or 
> something - sdk docs links return a 403.
> 
> -d
> 
> 
> On 16 November 2022 23:22:26 Alex Winfield <7nil...@gmail.com> wrote:
> 
>> Where should I look for the docs?
>> 
>> All of the examples point to dead links:
>> https://logging.apache.org/log4net/release/config-examples.html
>> 
>> Sample code online doesn't appear to actually work (%aspnet-context appears
>> to be parsed as just %a, with "spnet-context" as a static string).
>> 
>> I can see that there definitely is something for handling asp.net contexts (
>> https://git-wip-us.apache.org/repos/asf?p=logging-log4net.git;a=blob_plain;f=src/log4net/Layout/Pattern/AspNetContextPatternConverter.cs;hb=HEAD),
>> but I have no idea why it isn't working or what I need to do to enable it.
>> 
>> I'm just very confused on what format properties are available, which may
>> have been renamed over time, etc
>> 
>> I was able to get what I wanted to work using middleware, but it does feel
>> weird that there's so little documentation available.  I'd appreciate any
>> links that could help (I feel like this property is probably already
>> available and not need an entire middleware just to hook into log4net lol)
>> 
>> Also, log4net-u...@logging.apache.org appears to not have anyone watching
>> answering questions.  If it isn't being used, it should probably be removed
>> from the docs as a valid way to get help.

Re: Docs?

[Davyd McColl]

Ralph, I'd appreciate any help here. Seems there's a permissions error or 
something - sdk docs links return a 403.


-d


On 16 November 2022 23:22:26 Alex Winfield <7nil...@gmail.com> wrote:


 Where should I look for the docs?

All of the examples point to dead links:
https://logging.apache.org/log4net/release/config-examples.html

Sample code online doesn't appear to actually work (%aspnet-context appears
to be parsed as just %a, with "spnet-context" as a static string).

I can see that there definitely is something for handling asp.net contexts (
https://git-wip-us.apache.org/repos/asf?p=logging-log4net.git;a=blob_plain;f=src/log4net/Layout/Pattern/AspNetContextPatternConverter.cs;hb=HEAD),
but I have no idea why it isn't working or what I need to do to enable it.

I'm just very confused on what format properties are available, which may
have been renamed over time, etc

I was able to get what I wanted to work using middleware, but it does feel
weird that there's so little documentation available.  I'd appreciate any
links that could help (I feel like this property is probably already
available and not need an entire middleware just to hook into log4net lol)

Also, log4net-u...@logging.apache.org appears to not have anyone watching
answering questions.  If it isn't being used, it should probably be removed
from the docs as a valid way to get help.

Docs?

[Alex Winfield]

 Where should I look for the docs?

All of the examples point to dead links:
https://logging.apache.org/log4net/release/config-examples.html

Sample code online doesn't appear to actually work (%aspnet-context appears
to be parsed as just %a, with "spnet-context" as a static string).

I can see that there definitely is something for handling asp.net contexts (
https://git-wip-us.apache.org/repos/asf?p=logging-log4net.git;a=blob_plain;f=src/log4net/Layout/Pattern/AspNetContextPatternConverter.cs;hb=HEAD),
but I have no idea why it isn't working or what I need to do to enable it.

I'm just very confused on what format properties are available, which may
have been renamed over time, etc

I was able to get what I wanted to work using middleware, but it does feel
weird that there's so little documentation available.  I'd appreciate any
links that could help (I feel like this property is probably already
available and not need an entire middleware just to hook into log4net lol)

Also, log4net-u...@logging.apache.org appears to not have anyone watching
answering questions.  If it isn't being used, it should probably be removed
from the docs as a valid way to get help.

Re: A little stuck with publishing updated site / docs for log4net 2.0.9

[Ralph Goers]

I have updated the logging services site and corrected log4net’s .htaccess file 
to point to the 2.0.9 release. However, I cannot seem to get the download page 
to reference 2.0.9. It still shows 2.0.8.  The release notes are correct though.

Ralph

> On Aug 28, 2020, at 7:38 AM, Davyd McColl  wrote:
> 
> Thanks
> 
> -d
> 
> On 2020/08/28 16:07:45, Apache  wrote:
> I will take care of the main logging site. It currently uses the ASF CMS but 
> we have to get off of it so there isn’t much point in you having to learn how 
> to deal with it.
> 
> Ralph
> 
>> On Aug 28, 2020, at 12:26 AM, Davyd McColl wrote:
>> 
>> Hi all
>> 
>> I've been trying to update content for http://logging.apache.org/log4net (in 
>> particular http://logging.apache.org/log4net/release) and I'm sure I'm just 
>> doing something silly or missing something.
>> 
>> I've followed instructions at 
>> https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Site
>>  up to point 7, which is where I'm stuck: I'm not sure where to find the 
>> mentioned index.twig, mainly because I'm not sure what the document is 
>> referring to with "main web site". I haven't found an index.twig in 
>> https://svn.apache.org/repos/infra/websites/production/logging/content/ or 
>> https://svn.apache.org/repos/asf/logging/site/cms/trunk, but it's wholly 
>> possible I'm just missing it. Or that neither of these is the correct place 
>> to look.
>> 
>> I have updated documentation and committed via SVN for 2.0.9, including 
>> updating the 2.x link. I haven't marked the project as "not dormant" (yet -- 
>> I'll be more confident to do so once I've seen a complete release with all 
>> the entailed bits, including this site, so that I have some semblance of 
>> confidence to do it again!). All I've done is update the release notes to 
>> include the changes for 2.0.9, which I'm sure some people might appreciate, 
>> minor though the changes may be.
>> 
>> Any assistance appreciated. I've already received much assistance from Ralph 
>> and Matt (thanks!).
>> 
>> -d
> 
> 

Re: A little stuck with publishing updated site / docs for log4net 2.0.9

[Davyd McColl]

Thanks

-d

On 2020/08/28 16:07:45, Apache  wrote:
I will take care of the main logging site. It currently uses the ASF CMS but we 
have to get off of it so there isn’t much point in you having to learn how to 
deal with it.

Ralph

> On Aug 28, 2020, at 12:26 AM, Davyd McColl wrote:
>
> Hi all
>
> I've been trying to update content for http://logging.apache.org/log4net (in 
> particular http://logging.apache.org/log4net/release) and I'm sure I'm just 
> doing something silly or missing something.
>
> I've followed instructions at 
> https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Site
>  up to point 7, which is where I'm stuck: I'm not sure where to find the 
> mentioned index.twig, mainly because I'm not sure what the document is 
> referring to with "main web site". I haven't found an index.twig in 
> https://svn.apache.org/repos/infra/websites/production/logging/content/ or 
> https://svn.apache.org/repos/asf/logging/site/cms/trunk, but it's wholly 
> possible I'm just missing it. Or that neither of these is the correct place 
> to look.
>
> I have updated documentation and committed via SVN for 2.0.9, including 
> updating the 2.x link. I haven't marked the project as "not dormant" (yet -- 
> I'll be more confident to do so once I've seen a complete release with all 
> the entailed bits, including this site, so that I have some semblance of 
> confidence to do it again!). All I've done is update the release notes to 
> include the changes for 2.0.9, which I'm sure some people might appreciate, 
> minor though the changes may be.
>
> Any assistance appreciated. I've already received much assistance from Ralph 
> and Matt (thanks!).
>
> -d

Re: A little stuck with publishing updated site / docs for log4net 2.0.9

[Apache]

I will take care of the main logging site. It currently uses the ASF CMS but we 
have to get off of it so there isn’t much point in you having to learn how to 
deal with it.

Ralph

> On Aug 28, 2020, at 12:26 AM, Davyd McColl  wrote:
> 
> Hi all
> 
> I've been trying to update content for http://logging.apache.org/log4net (in 
> particular http://logging.apache.org/log4net/release) and I'm sure I'm just 
> doing something silly or missing something.
> 
> I've followed instructions at 
> https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Site
>  up to point 7, which is where I'm stuck: I'm not sure where to find the 
> mentioned index.twig, mainly because I'm not sure what the document is 
> referring to with "main web site". I haven't found an index.twig in 
> https://svn.apache.org/repos/infra/websites/production/logging/content/ or 
> https://svn.apache.org/repos/asf/logging/site/cms/trunk, but it's wholly 
> possible I'm just missing it. Or that neither of these is the correct place 
> to look.
> 
> I have updated documentation and committed via SVN for 2.0.9, including 
> updating the 2.x link. I haven't marked the project as "not dormant" (yet -- 
> I'll be more confident to do so once I've seen a complete release with all 
> the entailed bits, including this site, so that I have some semblance of 
> confidence to do it again!). All I've done is update the release notes to 
> include the changes for 2.0.9, which I'm sure some people might appreciate, 
> minor though the changes may be.
> 
> Any assistance appreciated. I've already received much assistance from Ralph 
> and Matt (thanks!).
> 
> -d

A little stuck with publishing updated site / docs for log4net 2.0.9

[Davyd McColl]

Hi all

I've been trying to update content for http://logging.apache.org/log4net (in 
particular http://logging.apache.org/log4net/release) and I'm sure I'm just 
doing something silly or missing something.

I've followed instructions at 
https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Site
 up to point 7, which is where I'm stuck: I'm not sure where to find the 
mentioned index.twig, mainly because I'm not sure what the document is 
referring to with "main web site". I haven't found an index.twig in 
https://svn.apache.org/repos/infra/websites/production/logging/content/ or 
https://svn.apache.org/repos/asf/logging/site/cms/trunk, but it's wholly 
possible I'm just missing it. Or that neither of these is the correct place to 
look.

I have updated documentation and committed via SVN for 2.0.9, including 
updating the 2.x link. I haven't marked the project as "not dormant" (yet -- 
I'll be more confident to do so once I've seen a complete release with all the 
entailed bits, including this site, so that I have some semblance of confidence 
to do it again!). All I've done is update the release notes to include the 
changes for 2.0.9, which I'm sure some people might appreciate, minor though 
the changes may be.

Any assistance appreciated. I've already received much assistance from Ralph 
and Matt (thanks!).

-d

Re: [log4j2] Legacy docs

[Gary Gregory]

I did not realize the sites were archived. That's great. We only need to
document that fact and link.

Gary

On Jun 25, 2017 21:57, "Ralph Goers"  wrote:

The Legacy section on the left nav bar contains a link for Log4j 1.x and
Log4j 2.3. These two releases (and sites) have special significance. No
other releases do. They should not be lost in a sea of other releases.
Plus, it would make that left navigation extremely long. Although all the
previous release sites are available online, the 2.x sites are also
available at https://archive.apache.org/dist/logging/log4j/ <
https://archive.apache.org/dist/logging/log4j/> as zip files.

I have no problem having the links to the web site available somewhere
else, but I would imagine it would have to be maintained by hand.

Ralph

> On Jun 25, 2017, at 8:05 PM, Gary Gregory  wrote:
>
> Hi,
>
> You're talking about something different, the change reports are one
thing,
> the site is another.
>
> I am thinking of users that are stuck on an old random release either by
> direct or transitive dependency. Using the site that matches their version
> would be quite helpful. No urgent of course.
>
> Gary
>
>
>
> On Sun, Jun 25, 2017 at 6:34 PM, Ralph Goers 
> wrote:
>
>> I only created that so people would be able to find release 2.3 if they
>> needed to use Java 6. My fear is that if we add all the releases there
then
>> that will get lost in the noise. BTW - all the releases are listed at
>> http://logging.apache.org/log4j/2.x/changes-report.html <
>> http://logging.apache.org/log4j/2.x/changes-report.html>. If we were
>> going to list all the releases then I would suggest a history page that
has
>> some sort of description about each release.
>>
>> Ralph
>>
>>> On Jun 25, 2017, at 6:16 PM, Gary Gregory 
>> wrote:
>>>
>>> Hi All,
>>>
>>> We have a nice "Legacy" section of our site. I think we should track
>> every
>>> release there.
>>>
>>> 2c,
>>> Gary
>>
>>

Re: [log4j2] Legacy docs

[Ralph Goers]

The Legacy section on the left nav bar contains a link for Log4j 1.x and Log4j 
2.3. These two releases (and sites) have special significance. No other 
releases do. They should not be lost in a sea of other releases. Plus, it would 
make that left navigation extremely long. Although all the previous release 
sites are available online, the 2.x sites are also available at 
https://archive.apache.org/dist/logging/log4j/ 
 as zip files.

I have no problem having the links to the web site available somewhere else, 
but I would imagine it would have to be maintained by hand.

Ralph

> On Jun 25, 2017, at 8:05 PM, Gary Gregory  wrote:
> 
> Hi,
> 
> You're talking about something different, the change reports are one thing,
> the site is another.
> 
> I am thinking of users that are stuck on an old random release either by
> direct or transitive dependency. Using the site that matches their version
> would be quite helpful. No urgent of course.
> 
> Gary
> 
> 
> 
> On Sun, Jun 25, 2017 at 6:34 PM, Ralph Goers 
> wrote:
> 
>> I only created that so people would be able to find release 2.3 if they
>> needed to use Java 6. My fear is that if we add all the releases there then
>> that will get lost in the noise. BTW - all the releases are listed at
>> http://logging.apache.org/log4j/2.x/changes-report.html <
>> http://logging.apache.org/log4j/2.x/changes-report.html>. If we were
>> going to list all the releases then I would suggest a history page that has
>> some sort of description about each release.
>> 
>> Ralph
>> 
>>> On Jun 25, 2017, at 6:16 PM, Gary Gregory 
>> wrote:
>>> 
>>> Hi All,
>>> 
>>> We have a nice "Legacy" section of our site. I think we should track
>> every
>>> release there.
>>> 
>>> 2c,
>>> Gary
>> 
>> 

Re: [log4j2] Legacy docs

[Gary Gregory]

Hi,

You're talking about something different, the change reports are one thing,
the site is another.

I am thinking of users that are stuck on an old random release either by
direct or transitive dependency. Using the site that matches their version
would be quite helpful. No urgent of course.

Gary



On Sun, Jun 25, 2017 at 6:34 PM, Ralph Goers 
wrote:

> I only created that so people would be able to find release 2.3 if they
> needed to use Java 6. My fear is that if we add all the releases there then
> that will get lost in the noise. BTW - all the releases are listed at
> http://logging.apache.org/log4j/2.x/changes-report.html <
> http://logging.apache.org/log4j/2.x/changes-report.html>. If we were
> going to list all the releases then I would suggest a history page that has
> some sort of description about each release.
>
> Ralph
>
> > On Jun 25, 2017, at 6:16 PM, Gary Gregory 
> wrote:
> >
> > Hi All,
> >
> > We have a nice "Legacy" section of our site. I think we should track
> every
> > release there.
> >
> > 2c,
> > Gary
>
>

Re: [log4j2] Legacy docs

[Ralph Goers]

I only created that so people would be able to find release 2.3 if they needed 
to use Java 6. My fear is that if we add all the releases there then that will 
get lost in the noise. BTW - all the releases are listed at 
http://logging.apache.org/log4j/2.x/changes-report.html 
. If we were going to 
list all the releases then I would suggest a history page that has some sort of 
description about each release.

Ralph

> On Jun 25, 2017, at 6:16 PM, Gary Gregory  wrote:
> 
> Hi All,
> 
> We have a nice "Legacy" section of our site. I think we should track every
> release there.
> 
> 2c,
> Gary

[log4j2] Legacy docs

[Gary Gregory]

Hi All,

We have a nice "Legacy" section of our site. I think we should track every
release there.

2c,
Gary

Re: Garbage-free Log4j docs preview

[Remko Popma]

Sent from my iPhone

> On 2016/06/07, at 0:16, Gary Gregory  wrote:
> 
> 
> On Jun 6, 2016 6:48 AM, "Remko Popma"  wrote:
> >
> >
> >
> > On Monday, June 6, 2016 at 6:16:52 PM UTC+9, Anthony Maire wrote:
> >>
> >> Hi Remko
> >>
> >> Great job ! 
> >> As Martin said, it's really a good thing for the high-performance 
> >> community that someone is trying to improve existing logging frameworks.
> >> The company I'm working for even started to write it's own custom SLF4J 
> >> implementation, and now we are evaluating if it's better for us to finish 
> >> this internal project or to write some custom filters and switch to log4j.
> >
> > Would you like to hear my totally unbiased opinion/advice? :-)
> > I'm not a fan of SLF4J... It means you can never use the rich feature set 
> > of the underlying logger. Like no lambdas! No CharSequences or plain domain 
> > objects, only Strings.
> > Not sure why people would want to use it in enterprise software. 
> > Maybe, well, likely, I'm biased :-) but I honestly don't see the advantage.
> > If the concern is the ability to change your mind later, there is always 
> > the log4j-to-slf4j adapter...
> >  
> >>
> >>
> >> I think there is one possible improvement with boxed primitive types: for 
> >> the moment we want to use only SLF4J api (as a consequence, we're aiming 
> >> for a low allocation rate, but not necessarily no allocation at all), so 
> >> the "Unboxer" mecanism provided in log4j is not an option for us to deal 
> >> with primitive types.
> >> Is this possible in a future release to have a special cases in 
> >> ParameterFormatter.appendSpecialTypes() for boxed primitive types ? 
> >> Currently, when using parametrized message with both Object and primitive 
> >> parameters, I haven't find a "SLF4J-compatible" way to avoid this 
> >> allocation when formatting.
> >
> >
> > If I understand correctly, you're less concerned with the varargs and the 
> > auto-boxed primitives, but would like to avoid calling toString() on the 
> > objects that resulted from the auto-boxing (please correct me if I 
> > misunderstood). Is something like the below what you have in mind? Would 
> > you mind raising a feature request on the Log4j2 issue tracker for this?
> >
> > private static boolean appendSpecialTypes(final Object o, final 
> > StringBuilder str) {
> >
> > ...
> > } else if (o instanceof Long) {
> > str.append(((Long) o).longValue());
> > return true;
> >
> > } else if (o instanceof Integer) {
> > str.append(((Integer) o).intValue());
> >
> > return true;
> >
> > } else if (o instanceof Double) {
> > str.append(((Double) o).doubleValue());
> >
> > return true;
> > } // similarly for float, short and boolean.
> > ...
> >
> > }
> 
> How about a map lookup to a code instead of a cascading if-else? Or... switch 
> to Java 8 ;-)
> 
I don't understand the Java 8 idea: does Java 8 have some mechanism that this 
code can be written differently?

Shall we discuss further on the Jira?
https://issues.apache.org/jira/browse/LOG4J2-1415

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

Re: Garbage-free Log4j docs preview

[Gary Gregory]

On Jun 6, 2016 6:48 AM, "Remko Popma"  wrote:
>
>
>
> On Monday, June 6, 2016 at 6:16:52 PM UTC+9, Anthony Maire wrote:
>>
>> Hi Remko
>>
>> Great job !
>> As Martin said, it's really a good thing for the high-performance
community that someone is trying to improve existing logging frameworks.
>> The company I'm working for even started to write it's own custom SLF4J
implementation, and now we are evaluating if it's better for us to finish
this internal project or to write some custom filters and switch to log4j.
>
> Would you like to hear my totally unbiased opinion/advice? :-)
> I'm not a fan of SLF4J... It means you can never use the rich feature set
of the underlying logger. Like no lambdas! No CharSequences or plain domain
objects, only Strings.
> Not sure why people would want to use it in enterprise software.
> Maybe, well, likely, I'm biased :-) but I honestly don't see the
advantage.
> If the concern is the ability to change your mind later, there is always
the log4j-to-slf4j adapter...
>
>>
>>
>> I think there is one possible improvement with boxed primitive types:
for the moment we want to use only SLF4J api (as a consequence, we're
aiming for a low allocation rate, but not necessarily no allocation at
all), so the "Unboxer" mecanism provided in log4j is not an option for us
to deal with primitive types.
>> Is this possible in a future release to have a special cases in
ParameterFormatter.appendSpecialTypes() for boxed primitive types ?
Currently, when using parametrized message with both Object and primitive
parameters, I haven't find a "SLF4J-compatible" way to avoid this
allocation when formatting.
>
>
> If I understand correctly, you're less concerned with the varargs and the
auto-boxed primitives, but would like to avoid calling toString() on the
objects that resulted from the auto-boxing (please correct me if I
misunderstood). Is something like the below what you have in mind? Would
you mind raising a feature request on the Log4j2 issue tracker for this?
>
> private static boolean appendSpecialTypes(final Object o, final
StringBuilder str) {
>
> ...
> } else if (o instanceof Long) {
> str.append(((Long) o).longValue());
> return true;
>
> } else if (o instanceof Integer) {
> str.append(((Integer) o).intValue());
>
> return true;
>
> } else if (o instanceof Double) {
> str.append(((Double) o).doubleValue());
>
> return true;
> } // similarly for float, short and boolean.
> ...
>
> }

How about a map lookup to a code instead of a cascading if-else? Or...
switch to Java 8 ;-)

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

Re: Garbage-free Log4j docs preview

[Remko Popma]

On Monday, June 6, 2016 at 6:16:52 PM UTC+9, Anthony Maire wrote:
>
> Hi Remko
>
> Great job ! 
> As Martin said, it's really a good thing for the high-performance 
> community that someone is trying to improve existing logging frameworks.
> The company I'm working for even started to write it's own custom SLF4J 
> implementation, and now we are evaluating if it's better for us to finish 
> this internal project or to write some custom filters and switch to log4j.
>
Would you like to hear my totally unbiased opinion/advice? :-)
I'm not a fan of SLF4J... It means you can never use the rich feature set 
of the underlying logger. Like no lambdas 
! No 
CharSequences or plain domain objects, only Strings.
Not sure why people would want to use it in enterprise software. 
Maybe, well, likely, I'm biased :-) but I honestly don't see the advantage.
If the concern is the ability to change your mind later, there is always 
the log4j-to-slf4j adapter 
...
 

>
> I think there is one possible improvement with boxed primitive types: for 
> the moment we want to use only SLF4J api (as a consequence, we're aiming 
> for a low allocation rate, but not necessarily no allocation at all), so 
> the "Unboxer" mecanism provided in log4j is not an option for us to deal 
> with primitive types.
> Is this possible in a future release to have a special cases in 
> ParameterFormatter.appendSpecialTypes() for boxed primitive types ? 
> Currently, when using parametrized message with both Object and primitive 
> parameters, I haven't find a "SLF4J-compatible" way to avoid this 
> allocation when formatting.
>

If I understand correctly, you're less concerned with the varargs and the 
auto-boxed primitives, but would like to avoid calling toString() on the 
objects that resulted from the auto-boxing (please correct me if I 
misunderstood). Is something like the below what you have in mind? Would 
you mind raising a feature request on the Log4j2 issue tracker 
 for this?

private static boolean appendSpecialTypes(final Object o, final StringBuilder 
str) {

...
} else if (o instanceof Long) {
str.append(((Long) o).longValue());
return true;

} else if (o instanceof Integer) {
str.append(((Integer) o).intValue());

return true;

} else if (o instanceof Double) {
str.append(((Double) o).doubleValue());

return true;
} // similarly for float, short and boolean.
...

}



> Kind Regards,
> Anthony
>

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

Re: Garbage-free Log4j docs preview

[Remko Popma]

On Sunday, June 5, 2016 at 7:39:25 PM UTC+9, Philippe Marschall wrote:
>
>
>
> On Friday, June 3, 2016 at 5:50:36 PM UTC+2, Remko Popma wrote:
>>
>>
>>
>> On Friday, June 3, 2016 at 4:42:51 PM UTC+9, Philippe Marschall wrote:
>>>
>>>
>>>
>>> On Tuesday, May 17, 2016 at 7:13:09 PM UTC+2, Remko Popma wrote:
>>>>
>>>> Hi all,
>>>>
>>>> First, my thanks to the many people who gave helpful advice and 
>>>> feedback on how to measure Log4j response time on this list some time ago.
>>>>
>>>> We're about to start the Log4j 2.6 release.
>>>> If anyone is interested, a preview of the garbage-free logging manual 
>>>> page is here: 
>>>> http://home.apache.org/~rpopma/log4j/2.6/manual/garbagefree.html
>>>> and a preview of the updated performance page is here: 
>>>> http://home.apache.org/~rpopma/log4j/2.6/performance.html
>>>>
>>>
>>> Forgive me my ignorance. Maybe I'm missing something or misunderstanding 
>>> something. If I want to a custom domain object like this
>>>
>>> LOG.info("something happened with {}", aDomainObject);
>>>
>>> then #toString() will be called on that object which very likely will 
>>> result in allocation. If I don't want this my domain object has to 
>>> implement CharSequence. I image this to be quite though to do without 
>>> allocation eg. how can I know the value of #charAt(10)? I would have to 
>>> "render" the entire object without allocation for every #charAt call.
>>>
>>> What I would really need is an alternative to #toString() that takes an 
>>> Appendable. Ideally that would be a JDK interface.
>>>
>>> public interface Loggable {
>>>
>>>   void logTo(Appendable log);
>>>
>>> }
>>>
>>
>> Philippe, I completely agree. The only thing is that no such interface 
>> exists in the JDK, so Log4j 2.6 includes a custom interface:
>>
>> package org.apache.logging.log4j.util;
>> public interface StringBuilderFormattable {
>> /**
>>  * Writes a text representation of this object into the specified {@code 
>> StringBuilder},
>>  * ideally without allocating temporary objects.
>>
>>  *
>>  * @param buffer the StringBuilder to write into
>>  */
>> void formatTo(StringBuilder buffer);
>> }
>>
>>  
>> We chose StringBuilder because the Appendable API is not rich enough.
>> Any Object that is logged, either standalone or as a parameter, if it 
>> does not implement CharSequence but it does 
>> implement StringBuilderFormattable then Log4j 2.6 will call 
>> formatTo(StringBuilder) instead of toString() on it. You can use this to 
>> render the domain object to text without creating temporary objects.
>>
>> I hope this is useful.
>>
>
> This is exactly what I'm looking for, I somehow missed that part at the 
> bottom. Thank you for our work, hopefully this will get more exposure in 
> the future.
>
My fault: this was not properly documented. I've updated the docs and we 
will update the site with the upcoming 2.6.1 bugfix release.
Glad this is useful, feedback and feature requests always welcome! -Remko 

>
> Cheers
> Philippe 
>

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

Re: Garbage-free Log4j docs preview

[Remko Popma]

On Friday, June 3, 2016 at 4:42:51 PM UTC+9, Philippe Marschall wrote:
>
>
>
> On Tuesday, May 17, 2016 at 7:13:09 PM UTC+2, Remko Popma wrote:
>>
>> Hi all,
>>
>> First, my thanks to the many people who gave helpful advice and feedback 
>> on how to measure Log4j response time on this list some time ago.
>>
>> We're about to start the Log4j 2.6 release.
>> If anyone is interested, a preview of the garbage-free logging manual 
>> page is here: 
>> http://home.apache.org/~rpopma/log4j/2.6/manual/garbagefree.html
>> and a preview of the updated performance page is here: 
>> http://home.apache.org/~rpopma/log4j/2.6/performance.html
>>
>
> Forgive me my ignorance. Maybe I'm missing something or misunderstanding 
> something. If I want to a custom domain object like this
>
> LOG.info("something happened with {}", aDomainObject);
>
> then #toString() will be called on that object which very likely will 
> result in allocation. If I don't want this my domain object has to 
> implement CharSequence. I image this to be quite though to do without 
> allocation eg. how can I know the value of #charAt(10)? I would have to 
> "render" the entire object without allocation for every #charAt call.
>
> What I would really need is an alternative to #toString() that takes an 
> Appendable. Ideally that would be a JDK interface.
>
> public interface Loggable {
>
>   void logTo(Appendable log);
>
> }
>

Philippe, I completely agree. The only thing is that no such interface 
exists in the JDK, so Log4j 2.6 includes a custom interface:

package org.apache.logging.log4j.util;
public interface StringBuilderFormattable {
/**
 * Writes a text representation of this object into the specified {@code 
StringBuilder},
 * ideally without allocating temporary objects.

 *
 * @param buffer the StringBuilder to write into
 */
void formatTo(StringBuilder buffer);
}

 
We chose StringBuilder because the Appendable API is not rich enough.
Any Object that is logged, either standalone or as a parameter, if it does 
not implement CharSequence then Log4j 2.6 will check if it implements 
StringBuilderFormattable before calling toString() on it.

I hope this is useful.

Kind regards, Remko
 

> Cheers
> Philippe 
>

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

Re: Garbage-free Log4j docs preview

[Gary Gregory]

On Thu, May 26, 2016 at 11:33 AM, Matt Sicker  wrote:

> There's a bson dependency in log4j-nosql as well (from mongo).
>

Right, the wire format for MongoDB is BSON IIRC.

Gary


>
> On 26 May 2016 at 11:46, Gary Gregory  wrote:
>
>> I think we can support BSON through Jackson. That would be interesting
>> for 2.7.
>>
>> Gary
>> On May 26, 2016 6:47 AM, "Remko Popma"  wrote:
>>
>>> Kirk,
>>>
>>> Logging in binary format has been on my todo list for a while.
>>> We did some preliminary analysis here:
>>> https://issues.apache.org/jira/browse/LOG4J2-1305
>>> Your thoughts on this effort would be much appreciated.
>>>
>>> Remko
>>>
>>> On Thursday, May 26, 2016 at 5:32:27 PM UTC+9, Kirk Pepperdine wrote:

 Hi,

 Sorry this might read a bit provocative then intended. In general I
 applaud this effort and to be fair I’ve not only picked on Log4J in the
 past. IM(not so)HO, all logger and in particular JDK logging has been a
 disaster from both an API and underlying design POV.


 On May 26, 2016, at 9:41 AM, Mikael Ståldal 
 wrote:

 http://12factor.net/logs


 I actually see little wrong with this approach.  It is rare that I run
 into an application that isn’t bottlenecked on logging when you combine all
 of the problem that come from logging. The JDK logger, because of it’s
 design, is responsible for class loader leaks. The API’s in all loggers
 encourage programming styles that are responsible for excessive memory
 pressure. Though I gripe about the obscene amount of work that logging
 frameworks engage in, generally it’s not the logging framework that is
 directly responsible for memory pressure, it’s what has to be done to use
 the logging framework that is the source of the problem.

 To tackle this I’ve been pushing simple solutions such that the one
 pushed here. Loggers should only push messages directly to a sync point and
 do no more than that. Anything that injects extra work into a threads
 workflow should be discarded. This includes activities such as decorating
 and/or reformatting running through appenders.. and so on Even record
 ordering (if it needs to be done) should happen else where. Additionally, I
 give the ( very unpopular) advice) that logging should use binary/machine
 readable formats (a practice adopted by Twitter and a number of other
 players) in favor of eye readable formats (which tend to be neither human
 nor machine readable). In messaging, of which logging is a form of
 messaging, information density counts and human readable formats tend to be
 exceptionally information sparse. When you combine these techniques you can
 get tremendous (orders of magnitude) improvements in performance. As much
 as I’m a fan of the disruptor, I fail to see how building on top of it
 solves any of the above mentioned problems.

 Kind regards,
 Kirk


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



-- 
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: Garbage-free Log4j docs preview

[Matt Sicker]

There's a bson dependency in log4j-nosql as well (from mongo).

On 26 May 2016 at 11:46, Gary Gregory  wrote:

> I think we can support BSON through Jackson. That would be interesting for
> 2.7.
>
> Gary
> On May 26, 2016 6:47 AM, "Remko Popma"  wrote:
>
>> Kirk,
>>
>> Logging in binary format has been on my todo list for a while.
>> We did some preliminary analysis here:
>> https://issues.apache.org/jira/browse/LOG4J2-1305
>> Your thoughts on this effort would be much appreciated.
>>
>> Remko
>>
>> On Thursday, May 26, 2016 at 5:32:27 PM UTC+9, Kirk Pepperdine wrote:
>>>
>>> Hi,
>>>
>>> Sorry this might read a bit provocative then intended. In general I
>>> applaud this effort and to be fair I’ve not only picked on Log4J in the
>>> past. IM(not so)HO, all logger and in particular JDK logging has been a
>>> disaster from both an API and underlying design POV.
>>>
>>>
>>> On May 26, 2016, at 9:41 AM, Mikael Ståldal 
>>> wrote:
>>>
>>> http://12factor.net/logs
>>>
>>>
>>> I actually see little wrong with this approach.  It is rare that I run
>>> into an application that isn’t bottlenecked on logging when you combine all
>>> of the problem that come from logging. The JDK logger, because of it’s
>>> design, is responsible for class loader leaks. The API’s in all loggers
>>> encourage programming styles that are responsible for excessive memory
>>> pressure. Though I gripe about the obscene amount of work that logging
>>> frameworks engage in, generally it’s not the logging framework that is
>>> directly responsible for memory pressure, it’s what has to be done to use
>>> the logging framework that is the source of the problem.
>>>
>>> To tackle this I’ve been pushing simple solutions such that the one
>>> pushed here. Loggers should only push messages directly to a sync point and
>>> do no more than that. Anything that injects extra work into a threads
>>> workflow should be discarded. This includes activities such as decorating
>>> and/or reformatting running through appenders.. and so on Even record
>>> ordering (if it needs to be done) should happen else where. Additionally, I
>>> give the ( very unpopular) advice) that logging should use binary/machine
>>> readable formats (a practice adopted by Twitter and a number of other
>>> players) in favor of eye readable formats (which tend to be neither human
>>> nor machine readable). In messaging, of which logging is a form of
>>> messaging, information density counts and human readable formats tend to be
>>> exceptionally information sparse. When you combine these techniques you can
>>> get tremendous (orders of magnitude) improvements in performance. As much
>>> as I’m a fan of the disruptor, I fail to see how building on top of it
>>> solves any of the above mentioned problems.
>>>
>>> Kind regards,
>>> Kirk
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>>
>


-- 
Matt Sicker 

Re: Garbage-free Log4j docs preview

[Gary Gregory]

I think we can support BSON through Jackson. That would be interesting for
2.7.

Gary
On May 26, 2016 6:47 AM, "Remko Popma"  wrote:

> Kirk,
>
> Logging in binary format has been on my todo list for a while.
> We did some preliminary analysis here:
> https://issues.apache.org/jira/browse/LOG4J2-1305
> Your thoughts on this effort would be much appreciated.
>
> Remko
>
> On Thursday, May 26, 2016 at 5:32:27 PM UTC+9, Kirk Pepperdine wrote:
>>
>> Hi,
>>
>> Sorry this might read a bit provocative then intended. In general I
>> applaud this effort and to be fair I’ve not only picked on Log4J in the
>> past. IM(not so)HO, all logger and in particular JDK logging has been a
>> disaster from both an API and underlying design POV.
>>
>>
>> On May 26, 2016, at 9:41 AM, Mikael Ståldal 
>> wrote:
>>
>> http://12factor.net/logs
>>
>>
>> I actually see little wrong with this approach.  It is rare that I run
>> into an application that isn’t bottlenecked on logging when you combine all
>> of the problem that come from logging. The JDK logger, because of it’s
>> design, is responsible for class loader leaks. The API’s in all loggers
>> encourage programming styles that are responsible for excessive memory
>> pressure. Though I gripe about the obscene amount of work that logging
>> frameworks engage in, generally it’s not the logging framework that is
>> directly responsible for memory pressure, it’s what has to be done to use
>> the logging framework that is the source of the problem.
>>
>> To tackle this I’ve been pushing simple solutions such that the one
>> pushed here. Loggers should only push messages directly to a sync point and
>> do no more than that. Anything that injects extra work into a threads
>> workflow should be discarded. This includes activities such as decorating
>> and/or reformatting running through appenders.. and so on Even record
>> ordering (if it needs to be done) should happen else where. Additionally, I
>> give the ( very unpopular) advice) that logging should use binary/machine
>> readable formats (a practice adopted by Twitter and a number of other
>> players) in favor of eye readable formats (which tend to be neither human
>> nor machine readable). In messaging, of which logging is a form of
>> messaging, information density counts and human readable formats tend to be
>> exceptionally information sparse. When you combine these techniques you can
>> get tremendous (orders of magnitude) improvements in performance. As much
>> as I’m a fan of the disruptor, I fail to see how building on top of it
>> solves any of the above mentioned problems.
>>
>> Kind regards,
>> Kirk
>>
>>
>
> -
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>

Re: Garbage-free Log4j docs preview

[Mikael Ståldal]

I just tried, gives a 5x performance boost. See Git branch LOG4J2-1395
 .

On Tue, May 24, 2016 at 4:27 PM, Mikael Ståldal 
wrote:

> Could we avoid that by using FileDescriptor.out / FileDescriptor.err
> instead of System.out / System.err ?
>
> On Tue, May 24, 2016 at 4:09 PM, Matt Sicker  wrote:
>
>> All the PrintStream.write() methods have locks.
>>
>> On 24 May 2016 at 02:56, Mikael Ståldal 
>> wrote:
>>
>>> Do we know why Console has so bad performance (compared to File)? Is
>>> this true also if you redirect STDOUT to a file?
>>>
>>> On Tue, May 17, 2016 at 7:13 PM, Remko Popma 
>>> wrote:
>>>
 Hi all,

 First, my thanks to the many people who gave helpful advice and
 feedback on how to measure Log4j response time on this list some time ago.

 We're about to start the Log4j 2.6 release.
 If anyone is interested, a preview of the garbage-free logging manual
 page is here:
 http://home.apache.org/~rpopma/log4j/2.6/manual/garbagefree.html
 and a preview of the updated performance page is here:
 http://home.apache.org/~rpopma/log4j/2.6/performance.html

 Feedback welcome!

 Remko



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

>>>
>>>
>>>
>>> --
>>> [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.
>>>
>>
>>
>>
>> --
>> Matt Sicker 
>>
>
>
>
> --
> [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.
>



-- 
[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: Garbage-free Log4j docs preview

[Remko Popma]

I used no special config for the JMH benchmarks, so the ConsoleAppender
writes to the terminal.
Perhaps it is a good idea to suggest redirecting to a file in the text that
accompanies these benchmark results.
Or add a benchmark result for how fast ConsoleAppender is when redirected.

On Thu, May 26, 2016 at 11:09 PM, Mikael Ståldal 
wrote:

> Did you redirect standard out to a file, or did you let it write to the
> terminal, when running the Log4j2AppenderComparisonBenchmark?
>
> I just tried both, and that gives you a significant 5-10x difference.
>
> On Tue, May 17, 2016 at 7:13 PM, Remko Popma 
> wrote:
>
>> Hi all,
>>
>> First, my thanks to the many people who gave helpful advice and feedback
>> on how to measure Log4j response time on this list some time ago.
>>
>> We're about to start the Log4j 2.6 release.
>> If anyone is interested, a preview of the garbage-free logging manual
>> page is here:
>> http://home.apache.org/~rpopma/log4j/2.6/manual/garbagefree.html
>> and a preview of the updated performance page is here:
>> http://home.apache.org/~rpopma/log4j/2.6/performance.html
>>
>> Feedback welcome!
>>
>> Remko
>>
>>
>>
>> -
>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>>
>
>
>
> --
> [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: Garbage-free Log4j docs preview

[Mikael Ståldal]

Did you redirect standard out to a file, or did you let it write to the
terminal, when running the Log4j2AppenderComparisonBenchmark?

I just tried both, and that gives you a significant 5-10x difference.

On Tue, May 17, 2016 at 7:13 PM, Remko Popma  wrote:

> Hi all,
>
> First, my thanks to the many people who gave helpful advice and feedback
> on how to measure Log4j response time on this list some time ago.
>
> We're about to start the Log4j 2.6 release.
> If anyone is interested, a preview of the garbage-free logging manual page
> is here: http://home.apache.org/~rpopma/log4j/2.6/manual/garbagefree.html
> and a preview of the updated performance page is here:
> http://home.apache.org/~rpopma/log4j/2.6/performance.html
>
> Feedback welcome!
>
> Remko
>
>
>
> -
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>



-- 
[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: Garbage-free Log4j docs preview

[Remko Popma]

Kirk,

Logging in binary format has been on my todo list for a while.
We did some preliminary analysis here: 
https://issues.apache.org/jira/browse/LOG4J2-1305
Your thoughts on this effort would be much appreciated.

Remko

On Thursday, May 26, 2016 at 5:32:27 PM UTC+9, Kirk Pepperdine wrote:
>
> Hi,
>
> Sorry this might read a bit provocative then intended. In general I 
> applaud this effort and to be fair I’ve not only picked on Log4J in the 
> past. IM(not so)HO, all logger and in particular JDK logging has been a 
> disaster from both an API and underlying design POV.
>
>
> On May 26, 2016, at 9:41 AM, Mikael Ståldal  > wrote:
>
> http://12factor.net/logs
>
>
> I actually see little wrong with this approach.  It is rare that I run 
> into an application that isn’t bottlenecked on logging when you combine all 
> of the problem that come from logging. The JDK logger, because of it’s 
> design, is responsible for class loader leaks. The API’s in all loggers 
> encourage programming styles that are responsible for excessive memory 
> pressure. Though I gripe about the obscene amount of work that logging 
> frameworks engage in, generally it’s not the logging framework that is 
> directly responsible for memory pressure, it’s what has to be done to use 
> the logging framework that is the source of the problem.
>
> To tackle this I’ve been pushing simple solutions such that the one pushed 
> here. Loggers should only push messages directly to a sync point and do no 
> more than that. Anything that injects extra work into a threads workflow 
> should be discarded. This includes activities such as decorating and/or 
> reformatting running through appenders.. and so on Even record ordering 
> (if it needs to be done) should happen else where. Additionally, I give the 
> ( very unpopular) advice) that logging should use binary/machine readable 
> formats (a practice adopted by Twitter and a number of other players) in 
> favor of eye readable formats (which tend to be neither human nor machine 
> readable). In messaging, of which logging is a form of messaging, 
> information density counts and human readable formats tend to be 
> exceptionally information sparse. When you combine these techniques you can 
> get tremendous (orders of magnitude) improvements in performance. As much 
> as I’m a fan of the disruptor, I fail to see how building on top of it 
> solves any of the above mentioned problems.
>
> Kind regards,
> Kirk
>
>
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: Garbage-free Log4j docs preview

[Mikael Ståldal]

http://12factor.net/logs

(I don't fully agree with this, but it would be nice if we can support it
in an efficient way.)

On Wed, May 25, 2016 at 6:50 PM, Matt Sicker  wrote:

> Plus there's the fact that some people are encouraging all logging to
> happen to stdout (in containers) for simpler log configuration and
> handling. It would be nice if we can support that scenario better.
>
> On 25 May 2016 at 09:18, Mikael Ståldal  wrote:
>
>> There are use cases for logging to standard out/err and redirecting to a
>> file or something else than an actual console. It would be good if we would
>> optimize so that is not 50x slower than logging directly to file.
>>
>> On Wed, May 25, 2016 at 4:09 PM, Remko Popma 
>> wrote:
>>
>>>
>>>
>>> On Wednesday, May 25, 2016 at 3:02:33 AM UTC+9, Richard Warburton wrote:

 Hi,

 Could we avoid that by using FileDescriptor.out / FileDescriptor.err
> instead of System.out / System.err ?
>
> On Tue, May 24, 2016 at 4:09 PM, Matt Sicker  wrote:
>
>> All the PrintStream.write() methods have locks.
>>
>> On 24 May 2016 at 02:56, Mikael Ståldal 
>> wrote:
>>
>>> Do we know why Console has so bad performance (compared to File)? Is
>>> this true also if you redirect STDOUT to a file?
>>>
>>
 There's a couple of other things to consider:

  * Console writes in Java flush on every newline.
  * The terminal that is being written to might also spend time
 rendering text, if your benchmark actually writes STDOUT. I've seen
 terminals eat 3x more CPU rendering logs than a program was using to
 produce them.

>>> Is rendering the bottleneck? I'm just wondering what causes this. The
>>> 50x difference with writing to a file is staggering... (I haven't benchmark
>>> File I/O when flushing on every write, may be interesting to try.)
>>>
>>>
 regards,

   Richard Warburton

   http://insightfullogic.com
   @RichardWarburto 

>>>
>>>
>>> -
>>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>>>
>>
>>
>>
>> --
>> [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.
>>
>
>
>
> --
> Matt Sicker 
>



-- 
[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: Garbage-free Log4j docs preview

[Matt Sicker]

Plus there's the fact that some people are encouraging all logging to
happen to stdout (in containers) for simpler log configuration and
handling. It would be nice if we can support that scenario better.

On 25 May 2016 at 09:18, Mikael Ståldal  wrote:

> There are use cases for logging to standard out/err and redirecting to a
> file or something else than an actual console. It would be good if we would
> optimize so that is not 50x slower than logging directly to file.
>
> On Wed, May 25, 2016 at 4:09 PM, Remko Popma 
> wrote:
>
>>
>>
>> On Wednesday, May 25, 2016 at 3:02:33 AM UTC+9, Richard Warburton wrote:
>>>
>>> Hi,
>>>
>>> Could we avoid that by using FileDescriptor.out / FileDescriptor.err
 instead of System.out / System.err ?

 On Tue, May 24, 2016 at 4:09 PM, Matt Sicker  wrote:

> All the PrintStream.write() methods have locks.
>
> On 24 May 2016 at 02:56, Mikael Ståldal  wrote:
>
>> Do we know why Console has so bad performance (compared to File)? Is
>> this true also if you redirect STDOUT to a file?
>>
>
>>> There's a couple of other things to consider:
>>>
>>>  * Console writes in Java flush on every newline.
>>>  * The terminal that is being written to might also spend time rendering
>>> text, if your benchmark actually writes STDOUT. I've seen terminals eat 3x
>>> more CPU rendering logs than a program was using to produce them.
>>>
>> Is rendering the bottleneck? I'm just wondering what causes this. The 50x
>> difference with writing to a file is staggering... (I haven't benchmark
>> File I/O when flushing on every write, may be interesting to try.)
>>
>>
>>> regards,
>>>
>>>   Richard Warburton
>>>
>>>   http://insightfullogic.com
>>>   @RichardWarburto 
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>>
>
>
>
> --
> [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.
>



-- 
Matt Sicker 

Re: Garbage-free Log4j docs preview

[Mikael Ståldal]

There are use cases for logging to standard out/err and redirecting to a
file or something else than an actual console. It would be good if we would
optimize so that is not 50x slower than logging directly to file.

On Wed, May 25, 2016 at 4:09 PM, Remko Popma  wrote:

>
>
> On Wednesday, May 25, 2016 at 3:02:33 AM UTC+9, Richard Warburton wrote:
>>
>> Hi,
>>
>> Could we avoid that by using FileDescriptor.out / FileDescriptor.err
>>> instead of System.out / System.err ?
>>>
>>> On Tue, May 24, 2016 at 4:09 PM, Matt Sicker  wrote:
>>>
 All the PrintStream.write() methods have locks.

 On 24 May 2016 at 02:56, Mikael Ståldal  wrote:

> Do we know why Console has so bad performance (compared to File)? Is
> this true also if you redirect STDOUT to a file?
>

>> There's a couple of other things to consider:
>>
>>  * Console writes in Java flush on every newline.
>>  * The terminal that is being written to might also spend time rendering
>> text, if your benchmark actually writes STDOUT. I've seen terminals eat 3x
>> more CPU rendering logs than a program was using to produce them.
>>
> Is rendering the bottleneck? I'm just wondering what causes this. The 50x
> difference with writing to a file is staggering... (I haven't benchmark
> File I/O when flushing on every write, may be interesting to try.)
>
>
>> regards,
>>
>>   Richard Warburton
>>
>>   http://insightfullogic.com
>>   @RichardWarburto 
>>
>
>
> -
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>



-- 
[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: Garbage-free Log4j docs preview

[Remko Popma]

On Wednesday, May 25, 2016 at 3:02:33 AM UTC+9, Richard Warburton wrote:
>
> Hi,
>
> Could we avoid that by using FileDescriptor.out / FileDescriptor.err 
>> instead of System.out / System.err ?
>>
>> On Tue, May 24, 2016 at 4:09 PM, Matt Sicker > > wrote:
>>
>>> All the PrintStream.write() methods have locks.
>>>
>>> On 24 May 2016 at 02:56, Mikael Ståldal >> > wrote:
>>>
 Do we know why Console has so bad performance (compared to File)? Is 
 this true also if you redirect STDOUT to a file?

>>>
> There's a couple of other things to consider:
>
>  * Console writes in Java flush on every newline.
>  * The terminal that is being written to might also spend time rendering 
> text, if your benchmark actually writes STDOUT. I've seen terminals eat 3x 
> more CPU rendering logs than a program was using to produce them.
>
Is rendering the bottleneck? I'm just wondering what causes this. The 50x 
difference with writing to a file is staggering... (I haven't benchmark 
File I/O when flushing on every write, may be interesting to try.)


> regards,
>
>   Richard Warburton
>
>   http://insightfullogic.com
>   @RichardWarburto 
>

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

Re: Garbage-free Log4j docs preview

[Ralph Goers]

It may be that the spec says the FileDescriptor has to point at a 
FileInputStream, in which case System.out would have to wrap it.

Ralph

> On May 25, 2016, at 5:43 AM, Ralph Goers  wrote:
> 
> You are missing the point.  What does IBM's JDK do?  What does the gnu JDK 
> do?  What does Android do?  You can only rely on what the spec says. I 
> haven't read the spec, but the javadoc certainly says nothing.
> 
> Ralph
> 
>> On May 25, 2016, at 4:09 AM, Mikael Ståldal  
>> wrote:
>> 
>> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/lang/System.java#1087
>> 
>>> On Wed, May 25, 2016 at 12:51 PM, Ralph Goers  
>>> wrote:
>>> I haven't looked at the source, but the point is that FileDescriptor gives 
>>> no guarantees what it is referencing.
>>> 
>>> Sent from my iPad
>>> 
 On May 25, 2016, at 12:49 AM, Mikael Ståldal  
 wrote:
 
 > but I would guess the the FileDescriptor may just be a reference to the 
 > PrintStream.
 
 I think it's the other way around, System.out is a wrapper around 
 FileDescriptor.out. Look at the source code for java.lang.System in JDK 8.
 
> On Tue, May 24, 2016 at 7:53 PM, Ralph Goers  
> wrote:
> The javadoc for FileDescriptor is fairly ambiguous. I’d have to look at 
> the code, but I would guess the the FileDescriptor may just be a 
> reference to the PrintStream. I really don’t think you can count on what 
> it points to. I would also worry about us trying to use the 
> FileDescriptor while the application might be writing to System.out. 
> 
> Ralph
> 
>> On May 24, 2016, at 10:30 AM, Remko Popma  wrote:
>> 
>> 
>>> On Tuesday, May 24, 2016 at 11:27:33 PM UTC+9, Mikael Ståldal wrote:
>>> Could we avoid that by using FileDescriptor.out / FileDescriptor.err 
>>> instead of System.out / System.err ?
>>> 
 On Tue, May 24, 2016 at 4:09 PM, Matt Sicker  wrote:
 All the PrintStream.write() methods have locks.
 
> On 24 May 2016 at 02:56, Mikael Ståldal  wrote:
> Do we know why Console has so bad performance (compared to File)? Is 
> this true also if you redirect STDOUT to a file?
> 
>> and a preview of the updated performance page is here: 
>> http://home.apache.org/~rpopma/log4j/2.6/performance.html
>> 
>> I think these are really interesting questions, and I am curious if 
>> anyone on this list can share their insights
>>  
>> 
>> -
>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
> 
 
 
 
 -- 
  
 
 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.   
>> 
>> 
>> 
>> -- 
>>  
>> 
>> 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: Garbage-free Log4j docs preview

[Ralph Goers]

You are missing the point.  What does IBM's JDK do?  What does the gnu JDK do?  
What does Android do?  You can only rely on what the spec says. I haven't read 
the spec, but the javadoc certainly says nothing.

Ralph

> On May 25, 2016, at 4:09 AM, Mikael Ståldal  wrote:
> 
> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/lang/System.java#1087
> 
>> On Wed, May 25, 2016 at 12:51 PM, Ralph Goers  
>> wrote:
>> I haven't looked at the source, but the point is that FileDescriptor gives 
>> no guarantees what it is referencing.
>> 
>> Sent from my iPad
>> 
>>> On May 25, 2016, at 12:49 AM, Mikael Ståldal  
>>> wrote:
>>> 
>>> > but I would guess the the FileDescriptor may just be a reference to the 
>>> > PrintStream.
>>> 
>>> I think it's the other way around, System.out is a wrapper around 
>>> FileDescriptor.out. Look at the source code for java.lang.System in JDK 8.
>>> 
 On Tue, May 24, 2016 at 7:53 PM, Ralph Goers  
 wrote:
 The javadoc for FileDescriptor is fairly ambiguous. I’d have to look at 
 the code, but I would guess the the FileDescriptor may just be a reference 
 to the PrintStream. I really don’t think you can count on what it points 
 to. I would also worry about us trying to use the FileDescriptor while the 
 application might be writing to System.out. 
 
 Ralph
 
> On May 24, 2016, at 10:30 AM, Remko Popma  wrote:
> 
> 
>> On Tuesday, May 24, 2016 at 11:27:33 PM UTC+9, Mikael Ståldal wrote:
>> Could we avoid that by using FileDescriptor.out / FileDescriptor.err 
>> instead of System.out / System.err ?
>> 
>>> On Tue, May 24, 2016 at 4:09 PM, Matt Sicker  wrote:
>>> All the PrintStream.write() methods have locks.
>>> 
 On 24 May 2016 at 02:56, Mikael Ståldal  wrote:
 Do we know why Console has so bad performance (compared to File)? Is 
 this true also if you redirect STDOUT to a file?
 
> and a preview of the updated performance page is here: 
> http://home.apache.org/~rpopma/log4j/2.6/performance.html
> 
> I think these are really interesting questions, and I am curious if 
> anyone on this list can share their insights
>  
> 
> -
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>>> 
>>> 
>>> 
>>> -- 
>>>  
>>> 
>>> 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.   
> 
> 
> 
> -- 
>  
> 
> 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: Garbage-free Log4j docs preview

[Mikael Ståldal]

http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/lang/System.java#1087

On Wed, May 25, 2016 at 12:51 PM, Ralph Goers 
wrote:

> I haven't looked at the source, but the point is that FileDescriptor gives
> no guarantees what it is referencing.
>
> Sent from my iPad
>
> On May 25, 2016, at 12:49 AM, Mikael Ståldal 
> wrote:
>
> > but I would guess the the FileDescriptor may just be a reference to the
> PrintStream.
>
> I think it's the other way around, System.out is a wrapper around
> FileDescriptor.out. Look at the source code for java.lang.System in JDK 8.
>
> On Tue, May 24, 2016 at 7:53 PM, Ralph Goers 
> wrote:
>
>> The javadoc for FileDescriptor is fairly ambiguous. I’d have to look at
>> the code, but I would guess the the FileDescriptor may just be a reference
>> to the PrintStream. I really don’t think you can count on what it points
>> to. I would also worry about us trying to use the FileDescriptor while the
>> application might be writing to System.out.
>>
>> Ralph
>>
>> On May 24, 2016, at 10:30 AM, Remko Popma  wrote:
>>
>>
>> On Tuesday, May 24, 2016 at 11:27:33 PM UTC+9, Mikael Ståldal wrote:
>>>
>>> Could we avoid that by using FileDescriptor.out / FileDescriptor.err
>>> instead of System.out / System.err ?
>>>
>>> On Tue, May 24, 2016 at 4:09 PM, Matt Sicker  wrote:
>>>
 All the PrintStream.write() methods have locks.

 On 24 May 2016 at 02:56, Mikael Ståldal  wrote:

> Do we know why Console has so bad performance (compared to File)? Is
> this true also if you redirect STDOUT to a file?
>
> and a preview of the updated performance page is here:
>> http://home.apache.org/~rpopma/log4j/2.6/performance.html
>>
>
>> I think these are really interesting questions, and I am curious if
>> anyone on this list can share their insights
>>
>>
>> -
>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>>
>>
>>
>
>
> --
> [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.
>
>


-- 
[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: Garbage-free Log4j docs preview

[Ralph Goers]

I haven't looked at the source, but the point is that FileDescriptor gives no 
guarantees what it is referencing.

Sent from my iPad

> On May 25, 2016, at 12:49 AM, Mikael Ståldal  
> wrote:
> 
> > but I would guess the the FileDescriptor may just be a reference to the 
> > PrintStream.
> 
> I think it's the other way around, System.out is a wrapper around 
> FileDescriptor.out. Look at the source code for java.lang.System in JDK 8.
> 
>> On Tue, May 24, 2016 at 7:53 PM, Ralph Goers  
>> wrote:
>> The javadoc for FileDescriptor is fairly ambiguous. I’d have to look at the 
>> code, but I would guess the the FileDescriptor may just be a reference to 
>> the PrintStream. I really don’t think you can count on what it points to. I 
>> would also worry about us trying to use the FileDescriptor while the 
>> application might be writing to System.out. 
>> 
>> Ralph
>> 
>>> On May 24, 2016, at 10:30 AM, Remko Popma  wrote:
>>> 
>>> 
 On Tuesday, May 24, 2016 at 11:27:33 PM UTC+9, Mikael Ståldal wrote:
 Could we avoid that by using FileDescriptor.out / FileDescriptor.err 
 instead of System.out / System.err ?
 
> On Tue, May 24, 2016 at 4:09 PM, Matt Sicker  wrote:
> All the PrintStream.write() methods have locks.
> 
>> On 24 May 2016 at 02:56, Mikael Ståldal  wrote:
>> Do we know why Console has so bad performance (compared to File)? Is 
>> this true also if you redirect STDOUT to a file?
>> 
>>> and a preview of the updated performance page is here: 
>>> http://home.apache.org/~rpopma/log4j/2.6/performance.html
>>> 
>>> I think these are really interesting questions, and I am curious if anyone 
>>> on this list can share their insights
>>>  
>>> 
>>> -
>>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>> 
> 
> 
> 
> -- 
>  
> 
> 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: Garbage-free Log4j docs preview

[Mikael Ståldal]

> but I would guess the the FileDescriptor may just be a reference to the
PrintStream.

I think it's the other way around, System.out is a wrapper around
FileDescriptor.out. Look at the source code for java.lang.System in JDK 8.

On Tue, May 24, 2016 at 7:53 PM, Ralph Goers 
wrote:

> The javadoc for FileDescriptor is fairly ambiguous. I’d have to look at
> the code, but I would guess the the FileDescriptor may just be a reference
> to the PrintStream. I really don’t think you can count on what it points
> to. I would also worry about us trying to use the FileDescriptor while the
> application might be writing to System.out.
>
> Ralph
>
> On May 24, 2016, at 10:30 AM, Remko Popma  wrote:
>
>
> On Tuesday, May 24, 2016 at 11:27:33 PM UTC+9, Mikael Ståldal wrote:
>>
>> Could we avoid that by using FileDescriptor.out / FileDescriptor.err
>> instead of System.out / System.err ?
>>
>> On Tue, May 24, 2016 at 4:09 PM, Matt Sicker  wrote:
>>
>>> All the PrintStream.write() methods have locks.
>>>
>>> On 24 May 2016 at 02:56, Mikael Ståldal  wrote:
>>>
 Do we know why Console has so bad performance (compared to File)? Is
 this true also if you redirect STDOUT to a file?

 and a preview of the updated performance page is here:
> http://home.apache.org/~rpopma/log4j/2.6/performance.html
>

> I think these are really interesting questions, and I am curious if anyone
> on this list can share their insights
>
>
> -
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>
>
>


-- 
[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: Garbage-free Log4j docs preview

[Remko Popma]

On Wednesday, May 25, 2016 at 3:25:00 AM UTC+9, Benedict Elliott Smith 
wrote:
>
> There is a "major" downside for some users - as an example, imagine a user 
> with a single core server that performs a high rate of logging, and does so 
> once every 100us.  This user is interested in throughput only.  There is 
> reasonable chance of a material slow down with an async appender.  Perhaps 
> as much as 10%; or more, dependent on kernel, vm, core count, core 
> affinity and way in which the runnable status is transitioned - for old 
> paravirtualised boxes running old linux kernels, we could be talking a much 
> worse degradation.
>
Okay. I added some text to the trade-offs section for this.
 

>
> A similar calculus can be done for many cores, but the likely impact in 
> throughput reduces as the involved application core count rises (for a 
> fixed application log rate), or the likely cost of lock contention 
> increases (for a fixed per-thread log rate), both of which mitigating the 
> downside.
>
> The number of users facing a *major* downside is likely very low (and 
> dependent on how you define "major"), but there are a range of scenarios 
> that vary from a meaningful to an irrelevant downside.
>
> I understood your previous messages to mean that your argument against 
>> async logging is that the producer thread needs to take a lock to wake up 
>> the consumer thread
>
>
> The problem is not the taking of a lock to wake-up anybody, the problem is 
> the *waking up*.  LiteBlockingWaitStrategy still has to transition the 
> runnable state of the consumer for every log message, and this is costly 
> with or without contention.  Semi-synchronous avoids this cost except when 
> it is known to be helpful *and* can be amortized.  The overall cost to 
> the application will be lower than for async, even in fairly high traffic 
> use cases.
>

> On 24 May 2016 at 18:22, Remko Popma  
> wrote:
>
>>
>>
>> On Tuesday, May 24, 2016 at 6:13:37 PM UTC+9, Benedict Elliott Smith 
>> wrote:
>>>
>>> But "response time pauses" are only an issue if you are latency 
>>> sensitive, which was one of my explicit criteria.  Most users aren't 
>>> latency sensitive.
>>>
>>> Holding a lock is not inherently expensive; in fact it is very cheap on 
>>> the scale of things we are discussing.  What is expensive is interacting 
>>> with the scheduler, and "writing to an IO device" (typically just writing 
>>> to the page cache, so actually not very expensive - again, unless you care 
>>> about outlier latency).  In one situation you do just one of these things; 
>>> in the other you do both.  The synchronous behaviour is worse if the lock 
>>> is highly contended, but that is one of the other criteria: there is a 
>>> performance/throughput bottleneck in the logging calls.  The 
>>> semi-synchronous behaviour would avoid this situation, leaving only latency 
>>> sensitivity.
>>>
>> So to summarize, you are saying that for low workload situations, in 
>> addition to synchronous and asynchronous logging, we should consider 
>> another algorithm, which is semi-synchronous. This algorithm may not be 
>> suitable for latency sensitive applications but has other desirable 
>> properties.
>>
>>
>>> NB: There is another possible criteria not mentioned, of course:  Having 
>>> spare cores, and the logging work being more expensive than the scheduler 
>>> interaction.  I've not benchmarked log4j, but I'm pretty sure this is not 
>>> the case for anything resembling a typical log message.
>>>
>>> The "LiteBlockingWaitStrategy" does not address this.  In the majority 
>>> of situations (i.e. a log message rate of < 1-10/ms, as a very rough bound) 
>>> its behaviour would be extremely similar to any other blocking wait 
>>> strategy, since at this rate you would *on average* expect only about 
>>> one unpark to be inflight at once - with all the usual caveats of depending 
>>> on overall system load etc etc.
>>>
>> This one I didn't get: I understood your previous messages to mean that 
>> your argument against async logging is that the producer thread needs to 
>> take a lock to wake up the consumer thread. My understanding is that an 
>> uncontended lock is very fast. Taking a lock is only a problem if it is 
>> contended. LiteBlockingWaitStrategy ensures the lock is not contended. 
>> While not the only way, this is certainly one way to address the concern 
>> you expressed against async logging.
>>
>> Semi-synchronous may be another way to solve the problem, and it may or 
>> may not be better (we'd need more data on how it behaves in the field).
>>
>>
>>> Semi-synchronous is simply a producer transitioning to a consumer to 
>>> process its own message, as waking up the consumer is costlier than doing 
>>> so.  When it finds work piling up, it decides the cost of waking up the 
>>> consumer is no longer negative, and does so.
>>>
>>> I will also note that for most users these extra costs aren't 
>>> particularly 

Re: Garbage-free Log4j docs preview

[Ralph Goers]

The javadoc for FileDescriptor is fairly ambiguous. I’d have to look at the 
code, but I would guess the the FileDescriptor may just be a reference to the 
PrintStream. I really don’t think you can count on what it points to. I would 
also worry about us trying to use the FileDescriptor while the application 
might be writing to System.out. 

Ralph

> On May 24, 2016, at 10:30 AM, Remko Popma  wrote:
> 
> 
> On Tuesday, May 24, 2016 at 11:27:33 PM UTC+9, Mikael Ståldal wrote:
> Could we avoid that by using FileDescriptor.out / FileDescriptor.err instead 
> of System.out / System.err ?
> 
> On Tue, May 24, 2016 at 4:09 PM, Matt Sicker  
> wrote:
> All the PrintStream.write() methods have locks.
> 
> On 24 May 2016 at 02:56, Mikael Ståldal  
> wrote:
> Do we know why Console has so bad performance (compared to File)? Is this 
> true also if you redirect STDOUT to a file?
> 
> and a preview of the updated performance page is here: 
> http://home.apache.org/~rpopma/log4j/2.6/performance.html 
> 
> 
> I think these are really interesting questions, and I am curious if anyone on 
> this list can share their insights
>  
> 
> -
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: Garbage-free Log4j docs preview

[Remko Popma]

On Tuesday, May 24, 2016 at 11:27:33 PM UTC+9, Mikael Ståldal wrote:
>
> Could we avoid that by using FileDescriptor.out / FileDescriptor.err 
> instead of System.out / System.err ?
>
> On Tue, May 24, 2016 at 4:09 PM, Matt Sicker  > wrote:
>
>> All the PrintStream.write() methods have locks.
>>
>> On 24 May 2016 at 02:56, Mikael Ståldal > > wrote:
>>
>>> Do we know why Console has so bad performance (compared to File)? Is 
>>> this true also if you redirect STDOUT to a file?
>>>
>>> and a preview of the updated performance page is here: 
 http://home.apache.org/~rpopma/log4j/2.6/performance.html

>>>
I think these are really interesting questions, and I am curious if anyone 
on this list can share their insights
 

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

Re: Garbage-free Log4j docs preview

[Remko Popma]

On Tuesday, May 24, 2016 at 6:13:37 PM UTC+9, Benedict Elliott Smith wrote:
>
> But "response time pauses" are only an issue if you are latency sensitive, 
> which was one of my explicit criteria.  Most users aren't latency sensitive.
>
> Holding a lock is not inherently expensive; in fact it is very cheap on 
> the scale of things we are discussing.  What is expensive is interacting 
> with the scheduler, and "writing to an IO device" (typically just writing 
> to the page cache, so actually not very expensive - again, unless you care 
> about outlier latency).  In one situation you do just one of these things; 
> in the other you do both.  The synchronous behaviour is worse if the lock 
> is highly contended, but that is one of the other criteria: there is a 
> performance/throughput bottleneck in the logging calls.  The 
> semi-synchronous behaviour would avoid this situation, leaving only latency 
> sensitivity.
>
So to summarize, you are saying that for low workload situations, in 
addition to synchronous and asynchronous logging, we should consider 
another algorithm, which is semi-synchronous. This algorithm may not be 
suitable for latency sensitive applications but has other desirable 
properties.


> NB: There is another possible criteria not mentioned, of course:  Having 
> spare cores, and the logging work being more expensive than the scheduler 
> interaction.  I've not benchmarked log4j, but I'm pretty sure this is not 
> the case for anything resembling a typical log message.
>
> The "LiteBlockingWaitStrategy" does not address this.  In the majority of 
> situations (i.e. a log message rate of < 1-10/ms, as a very rough bound) 
> its behaviour would be extremely similar to any other blocking wait 
> strategy, since at this rate you would *on average* expect only about one 
> unpark to be inflight at once - with all the usual caveats of depending on 
> overall system load etc etc.
>
This one I didn't get: I understood your previous messages to mean that 
your argument against async logging is that the producer thread needs to 
take a lock to wake up the consumer thread. My understanding is that an 
uncontended lock is very fast. Taking a lock is only a problem if it is 
contended. LiteBlockingWaitStrategy ensures the lock is not contended. 
While not the only way, this is certainly one way to address the concern 
you expressed against async logging.

Semi-synchronous may be another way to solve the problem, and it may or may 
not be better (we'd need more data on how it behaves in the field).


> Semi-synchronous is simply a producer transitioning to a consumer to 
> process its own message, as waking up the consumer is costlier than doing 
> so.  When it finds work piling up, it decides the cost of waking up the 
> consumer is no longer negative, and does so.
>
> I will also note that for most users these extra costs aren't particularly 
> material either; as soon as your log rate goes down to < 0.1/ms, the extra 
> costs start to become very small as a proportion of total work. So there's 
> definitely no reason to panic.  But these users are still not deriving the 
> advertised benefits from async.
>
Ok, understood. So the main concern is that the advertised benefits may not 
materialize under low loads. There are no other downsides or major ill 
effects. Please correct me if I'm wrong. If there is a major downside I 
would like to document it on the Log4j web site. (But please don't wait too 
long, we'll start the release soon.)

 

>
>
> On 23 May 2016 at 13:38, Remko Popma  
> wrote:
>
>>
>>
>> On Monday, May 23, 2016 at 2:47:05 AM UTC+9, Benedict Elliott Smith wrote:
>>>
>>> Your pride should be saved by your gracious recognition of the error :)
>>>
>>>
>>> However this is the core of my point: you’re clearly an intelligent, 
>>> conscientious and talented developer, and yet you did not fully understand 
>>> these concerns.  You are writing core infrastructure many people will 
>>> deploy, and a majority will understand it much much less well.  So the very 
>>> best thing you can do is to educate them.  Doubly so if you needed 
>>> educating yourself!
>>>
>> ;-) 
>>
>>>
>>> I would make it very clear that users should only consider asynchronous 
>>> logging if they are having performance problems caused by their logging.  
>>> Only with sub-millisecond latency requirements should async be considered, 
>>> and below 100 micros you are entering busy-spinning territory.  Or if huge 
>>> message rates are being seen.  The best default is a blocking strategy, as 
>>> this has the closest performance profile to synchronous, and will prevent 
>>> the many users who deploy this without needing it from suffering any major 
>>> ill-effect.
>>>
>> I think I missed a step here. You made it plausible that under low 
>> workload, the Disruptor may not be better than ArrayBlockingQueue. 
>> Understood.
>>
>> But I don't understand why users should only configure async logging 

Re: Garbage-free Log4j docs preview

[Gary Gregory]

But wouldn't that mess up output when another thread does sys out println?
Or do we hook in to System.setOut and setErr?

Gary
On May 24, 2016 7:27 AM, "Mikael Ståldal"  wrote:

> Could we avoid that by using FileDescriptor.out / FileDescriptor.err
> instead of System.out / System.err ?
>
> On Tue, May 24, 2016 at 4:09 PM, Matt Sicker  wrote:
>
>> All the PrintStream.write() methods have locks.
>>
>> On 24 May 2016 at 02:56, Mikael Ståldal 
>> wrote:
>>
>>> Do we know why Console has so bad performance (compared to File)? Is
>>> this true also if you redirect STDOUT to a file?
>>>
>>> On Tue, May 17, 2016 at 7:13 PM, Remko Popma 
>>> wrote:
>>>
 Hi all,

 First, my thanks to the many people who gave helpful advice and
 feedback on how to measure Log4j response time on this list some time ago.

 We're about to start the Log4j 2.6 release.
 If anyone is interested, a preview of the garbage-free logging manual
 page is here:
 http://home.apache.org/~rpopma/log4j/2.6/manual/garbagefree.html
 and a preview of the updated performance page is here:
 http://home.apache.org/~rpopma/log4j/2.6/performance.html

 Feedback welcome!

 Remko



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

>>>
>>>
>>>
>>> --
>>> [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.
>>>
>>
>>
>>
>> --
>> Matt Sicker 
>>
>
>
>
> --
> [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: Garbage-free Log4j docs preview

[Mikael Ståldal]

Could we avoid that by using FileDescriptor.out / FileDescriptor.err
instead of System.out / System.err ?

On Tue, May 24, 2016 at 4:09 PM, Matt Sicker  wrote:

> All the PrintStream.write() methods have locks.
>
> On 24 May 2016 at 02:56, Mikael Ståldal  wrote:
>
>> Do we know why Console has so bad performance (compared to File)? Is this
>> true also if you redirect STDOUT to a file?
>>
>> On Tue, May 17, 2016 at 7:13 PM, Remko Popma 
>> wrote:
>>
>>> Hi all,
>>>
>>> First, my thanks to the many people who gave helpful advice and feedback
>>> on how to measure Log4j response time on this list some time ago.
>>>
>>> We're about to start the Log4j 2.6 release.
>>> If anyone is interested, a preview of the garbage-free logging manual
>>> page is here:
>>> http://home.apache.org/~rpopma/log4j/2.6/manual/garbagefree.html
>>> and a preview of the updated performance page is here:
>>> http://home.apache.org/~rpopma/log4j/2.6/performance.html
>>>
>>> Feedback welcome!
>>>
>>> Remko
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>>>
>>
>>
>>
>> --
>> [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.
>>
>
>
>
> --
> Matt Sicker 
>



-- 
[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: Garbage-free Log4j docs preview

[Matt Sicker]

All the PrintStream.write() methods have locks.

On 24 May 2016 at 02:56, Mikael Ståldal  wrote:

> Do we know why Console has so bad performance (compared to File)? Is this
> true also if you redirect STDOUT to a file?
>
> On Tue, May 17, 2016 at 7:13 PM, Remko Popma 
> wrote:
>
>> Hi all,
>>
>> First, my thanks to the many people who gave helpful advice and feedback
>> on how to measure Log4j response time on this list some time ago.
>>
>> We're about to start the Log4j 2.6 release.
>> If anyone is interested, a preview of the garbage-free logging manual
>> page is here:
>> http://home.apache.org/~rpopma/log4j/2.6/manual/garbagefree.html
>> and a preview of the updated performance page is here:
>> http://home.apache.org/~rpopma/log4j/2.6/performance.html
>>
>> Feedback welcome!
>>
>> Remko
>>
>>
>>
>> -
>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>>
>
>
>
> --
> [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.
>



-- 
Matt Sicker 

Re: Garbage-free Log4j docs preview

[Mikael Ståldal]

Do we know why Console has so bad performance (compared to File)? Is this
true also if you redirect STDOUT to a file?

On Tue, May 17, 2016 at 7:13 PM, Remko Popma  wrote:

> Hi all,
>
> First, my thanks to the many people who gave helpful advice and feedback
> on how to measure Log4j response time on this list some time ago.
>
> We're about to start the Log4j 2.6 release.
> If anyone is interested, a preview of the garbage-free logging manual page
> is here: http://home.apache.org/~rpopma/log4j/2.6/manual/garbagefree.html
> and a preview of the updated performance page is here:
> http://home.apache.org/~rpopma/log4j/2.6/performance.html
>
> Feedback welcome!
>
> Remko
>
>
>
> -
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>



-- 
[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: Garbage-free Log4j docs preview

[Mikael Ståldal]

> But I don't understand why users should only configure async logging in
rare cases? Synchronous logging also involves holding a lock. Log4j 2 makes
an effort to release this lock as soon as
> possible (locking only while copying a byte array from a thread-local
buffer to the I/O device), but as Martin pointed out, in addition to the
lock contention, other things may cause response time
> pauses when writing to the I/O device.

There is also another reason for using async logging, to protect the app
from errors and unpredictable response time from a network based appender.
However, for that the ArrayBlockingQueue based AsyncAppender is sufficient.

On Mon, May 23, 2016 at 2:38 PM, Remko Popma  wrote:

>
>
> On Monday, May 23, 2016 at 2:47:05 AM UTC+9, Benedict Elliott Smith wrote:
>>
>> Your pride should be saved by your gracious recognition of the error :)
>>
>>
>> However this is the core of my point: you’re clearly an intelligent,
>> conscientious and talented developer, and yet you did not fully understand
>> these concerns.  You are writing core infrastructure many people will
>> deploy, and a majority will understand it much much less well.  So the very
>> best thing you can do is to educate them.  Doubly so if you needed
>> educating yourself!
>>
> ;-)
>
>>
>> I would make it very clear that users should only consider asynchronous
>> logging if they are having performance problems caused by their logging.
>> Only with sub-millisecond latency requirements should async be considered,
>> and below 100 micros you are entering busy-spinning territory.  Or if huge
>> message rates are being seen.  The best default is a blocking strategy, as
>> this has the closest performance profile to synchronous, and will prevent
>> the many users who deploy this without needing it from suffering any major
>> ill-effect.
>>
> I think I missed a step here. You made it plausible that under low
> workload, the Disruptor may not be better than ArrayBlockingQueue.
> Understood.
>
> But I don't understand why users should only configure async logging in
> rare cases? Synchronous logging also involves holding a lock. Log4j 2 makes
> an effort to release this lock as soon as possible (locking only while
> copying a byte array from a thread-local buffer to the I/O device), but as
> Martin pointed out, in addition to the lock contention, other things may
> cause response time pauses when writing to the I/O device.
>
> So which is "better": holding a lock to signal a
> java.util.concurrent.locks.Condition, versus holding a lock to write a byte
> array to the I/O device? The latter sounds like it has more risk of latency
> spikes. So I'm not sure I agree with your assessment that async logging has
> more risk of major ill effects.
>
> Under low loads the upside of Async Loggers may not be as high as the
> graph suggests but I don't see any real downsides either. Please let me
> know if I'm missing something.
>
>
>>
>> I would also do a performance comparison with a real application.
>> Cassandra uses log4j, and the community has an easily utilised performance
>> tool.  You could try both DEBUG and INFO level, and put up some graphs.
>> This would help users make a more realistic and informed decision.
>>
> I agree it may be interesting for users to see a case study of some sort
> with a real application. Can you point me to the tool you are referring to?
>
>
>>
>> This may all seem a little disappointing: to *reduce* the number of
>> people who might use your amazing new technology.  But there will be
>> plenty, who both need it and do not and don't read or heed the warnings.
>>
> That's okay. It is garbage-free logging that is new in the 2.6 release,
> not the Async Loggers. The Disruptor-based Async Loggers have been used in
> the wild for about three years now. The response has generally been
> positive so I'm not panicking just yet.
> I do intend to follow up though and I take your point that under low load
> this technology may not give as much benefit as under high load. (Again,
> please correct me if there is a bigger problem and I'm missing any other
> downsides/risks.)
>
>
>>
>> Regarding improvements: In my opinion, a better algorithm for this
>> majority, of low-to-moderate traffic that is not extremely latency
>> sensitive, is semi-synchronous.  By which I mean for the first log call in
>> a batch to take exclusive ownership of the output and to write its message
>> synchronously; any messages that arrive while it has ownership are passed
>> to the owner to persist, i.e. they are written asynchronously.  To ensure
>> any thread’s ownership is brief, it would impose a time-limit, after which
>> a dedicated consumer could be started if the queue is still not exhausted.
>> This would have better than synchronous behaviour for low-to-moderate
>> traffic and scale gracefully to high traffic.
>>
> This is really interesting. It reminds me of one of the co-operative
> algorithms I read about in the 

Re: Garbage-free Log4j docs preview

[Mikael Ståldal]

Can the support for Intel TSX in Java 8u20 be relevant here?

https://bugs.openjdk.java.net/browse/JDK-8031320

On Sun, May 22, 2016 at 3:42 PM, Remko Popma  wrote:

>
>
> On Sunday, May 22, 2016 at 6:34:13 PM UTC+9, Benedict Elliott Smith wrote:
>>
>> Hi Remko,
>>
>> I realise that I was looking at the old log4j code without realising it,
>> in which there is always a futex involved.
>>
> Which class is this? Async Loggers in Log4j 2 have always been lock-free.
> What may be confusing is that Log4j 2 also has an Async*Appender*, which
> does not use the Disruptor but uses a JDK BlockingArrayQueue. This appender
> is very similar to how Logback and Log4j 1 do asynchronous logging. Async
> *Appender* (in Log4j 2, Log4j 1 and Logback, they all use a blocking
> queue) is sensitive to lock contention and does not scale with more threads.
>
>
>>
>> However the behaviour of the disruptor that backs the new code will
>> depend on the wait strategy employed (and I'll note your default is a
>> blocking strategy, for which my prior statement holds*).
>>
> Perhaps the key misunderstanding is here. I think I did not explain it
> well in my previous message. Let me try again.
>
> Async Loggers use the Disruptor and are lock-free. This means that
> multiple application threads can log concurrently and are not blocked by
> each other. This is true for very low workloads, medium workloads and high
> workloads.
>
> Only if an application logs messages at a very high rate for a long period
> of time, or uses a slow appender, the Disruptor ringbuffer can fill up and
> application threads will have to wait until a slot in the ringbuffer
> becomes available. For the 2.6 release I have added text to the
> Trade-offs section
> 
> to explain this last point, based on your feedback.
>
> Note that the Disruptor wait strategy is irrelevant to all this.
> Application threads are *not *impacted by the wait strategy.
>
>
>> Here we obviously get into the territory of people needing to understand
>> the disruptor as well as your logging framework, but since you have a whole
>> section labelled "Trade-offs" in which you draw attention to the improved
>> throughput and latency profile under "Benefits," under "Drawbacks" it might
>> be nice to mention these possible confounders.  Or at least raise a bat
>> signal to go and understand the tradeoffs for the disruptor (which is also
>> regrettably poorly understood).
>>
>> It might also be helpful to explicitly call out the configuration used
>> for your benchmarks,
>>
> Tests on the 2.6 performance page
>  are mostly
> done with JMH benchmarks where parameters are in the javadoc.
> Tests on the Async Loggers page are partly with the new ResponseTimeTest
> class
> (params in the doc
> ) and
> partly still shows results from the older PerfTestDriver
> 
> class. This last one has parameters in the code. You'll need to spend some
> time to get familiar with it if you want to run it.
>
> and perhaps to run a comparison against some real software - github does
>> not lack for applications using log4j!  Unfortunately I bet this would
>> result in a much less sexy graph.
>>
> Log4j 2 has had lock-free Async Loggers from its 2.0-beta5 release
> ,
> three years ago. If there are any serious performance drawbacks like you
> seem to think there are I hope I would have heard of them. Fortunately the
> opposite is true. People report very positive experiences
> .
> People who did their own measurements reported it makes their logging as
> fast as if it was switched off
> .
>
>
>> Finally, I really think people should (in your wiki page) explicitly be
>> *discouraged* from using this part of your framework *unless they know
>> they need it*.  It's a fantastic piece of work for people who *do* need
>> it.
>>
> Again, I think you are laboring under a misapprehension. I cannot imagine
> a scenario where lock-free logging would be a bad thing. If you think there
> is, please show evidence.
>
>
>> But 99.99% of people would be better off with a logger that just avoids
>> blocking threads when one is already in the process of logging.
>>
> Avoiding blocking is exactly what the Async Loggers are for. (So I really
> think there is some 

Re: Garbage-free Log4j docs preview

[Mikael Ståldal]

> But I don't understand why users should only configure async logging in
rare cases? Synchronous logging also involves holding a lock. Log4j 2 makes
an effort to release this lock as soon as
> possible (locking only while copying a byte array from a thread-local
buffer to the I/O device), but as Martin pointed out, in addition to the
lock contention, other things may cause response time
> pauses when writing to the I/O device.

There is also another reason for using async logging, to protect the app
from errors and unpredictable response time from a network based appender.
However, for that the ArrayBlockingQueue based AsyncAppender is sufficient.

On Mon, May 23, 2016 at 2:38 PM, Remko Popma  wrote:

>
>
> On Monday, May 23, 2016 at 2:47:05 AM UTC+9, Benedict Elliott Smith wrote:
>>
>> Your pride should be saved by your gracious recognition of the error :)
>>
>>
>> However this is the core of my point: you’re clearly an intelligent,
>> conscientious and talented developer, and yet you did not fully understand
>> these concerns.  You are writing core infrastructure many people will
>> deploy, and a majority will understand it much much less well.  So the very
>> best thing you can do is to educate them.  Doubly so if you needed
>> educating yourself!
>>
> ;-)
>
>>
>> I would make it very clear that users should only consider asynchronous
>> logging if they are having performance problems caused by their logging.
>> Only with sub-millisecond latency requirements should async be considered,
>> and below 100 micros you are entering busy-spinning territory.  Or if huge
>> message rates are being seen.  The best default is a blocking strategy, as
>> this has the closest performance profile to synchronous, and will prevent
>> the many users who deploy this without needing it from suffering any major
>> ill-effect.
>>
> I think I missed a step here. You made it plausible that under low
> workload, the Disruptor may not be better than ArrayBlockingQueue.
> Understood.
>
> But I don't understand why users should only configure async logging in
> rare cases? Synchronous logging also involves holding a lock. Log4j 2 makes
> an effort to release this lock as soon as possible (locking only while
> copying a byte array from a thread-local buffer to the I/O device), but as
> Martin pointed out, in addition to the lock contention, other things may
> cause response time pauses when writing to the I/O device.
>
> So which is "better": holding a lock to signal a
> java.util.concurrent.locks.Condition, versus holding a lock to write a byte
> array to the I/O device? The latter sounds like it has more risk of latency
> spikes. So I'm not sure I agree with your assessment that async logging has
> more risk of major ill effects.
>
> Under low loads the upside of Async Loggers may not be as high as the
> graph suggests but I don't see any real downsides either. Please let me
> know if I'm missing something.
>
>
>>
>> I would also do a performance comparison with a real application.
>> Cassandra uses log4j, and the community has an easily utilised performance
>> tool.  You could try both DEBUG and INFO level, and put up some graphs.
>> This would help users make a more realistic and informed decision.
>>
> I agree it may be interesting for users to see a case study of some sort
> with a real application. Can you point me to the tool you are referring to?
>
>
>>
>> This may all seem a little disappointing: to *reduce* the number of
>> people who might use your amazing new technology.  But there will be
>> plenty, who both need it and do not and don't read or heed the warnings.
>>
> That's okay. It is garbage-free logging that is new in the 2.6 release,
> not the Async Loggers. The Disruptor-based Async Loggers have been used in
> the wild for about three years now. The response has generally been
> positive so I'm not panicking just yet.
> I do intend to follow up though and I take your point that under low load
> this technology may not give as much benefit as under high load. (Again,
> please correct me if there is a bigger problem and I'm missing any other
> downsides/risks.)
>
>
>>
>> Regarding improvements: In my opinion, a better algorithm for this
>> majority, of low-to-moderate traffic that is not extremely latency
>> sensitive, is semi-synchronous.  By which I mean for the first log call in
>> a batch to take exclusive ownership of the output and to write its message
>> synchronously; any messages that arrive while it has ownership are passed
>> to the owner to persist, i.e. they are written asynchronously.  To ensure
>> any thread’s ownership is brief, it would impose a time-limit, after which
>> a dedicated consumer could be started if the queue is still not exhausted.
>> This would have better than synchronous behaviour for low-to-moderate
>> traffic and scale gracefully to high traffic.
>>
> This is really interesting. It reminds me of one of the co-operative
> algorithms I read about in the 

Re: Garbage-free Log4j docs preview

[Remko Popma]

Yes, potentially *very* relevant!
Please post this on the mechanical sympathy mailing list!

On Monday, 23 May 2016, Mikael Ståldal  wrote:

> Can the support for Intel TSX in Java 8u20 be relevant here?
>
> https://bugs.openjdk.java.net/browse/JDK-8031320
>
> On Sun, May 22, 2016 at 5:40 PM, Remko Popma  > wrote:
>
>>
>>
>> On Sunday, May 22, 2016 at 11:08:37 PM UTC+9, Benedict Elliott Smith
>> wrote:
>>>
>>> It's possible I'm missing some other aspect that insulates the
>>> application thread from the disruptor, but from your message it seems to me
>>> that you fall into the all-too-common category of people who do not fully
>>> understand the semantics of the disruptor.  Application threads (i.e.
>>> disruptor producers) very much *are* affected by the wait strategy.
>>> Under normal use, *if the disruptor consumer thread is employing a
>>> blocking strategy, there will be futex call to unblock it when work is
>>> provided*.  i.e. whenever the queue transitions from empty to
>>> non-empty, i.e. for most messages with low-to-medium logging rates.
>>>
>>> In this situation the enqueueing of a message is also* not lock free*,
>>> as while futexes can in theory be lock-free, the JVM uses a lock to
>>> synchronise access to the semaphore that controls its runnable state, so
>>> all threads attempting to wake it up concurrently will compete for this
>>> lock.
>>>
>>
>> Well... Looks like you were right and I was wrong.
>>
>> Interesting. Apart from the dent in my pride here, this is actually good
>> news. It means we can do better!
>>
>> So in the worst-case scenario Async Loggers/Disruptor with the blocking
>> wait strategy give performance equivalent to AsyncAppender with a
>> BlockingArrayQueue. We can expect Async Loggers with Disruptor to
>> outperform AsyncAppender with BlockingArrayQueue when workloads are high or
>> bursts of work keep the background thread busy for some time. At least this
>> is my understanding now. Or did I miss something and are there cases where
>> Async Loggers with Disruptor will perform worse than AsyncAppender with
>> BlockingArrayQueue?
>>
>> In terms of how to improve, short-term we should probably look at using
>> the PhasedBackoffWaitStrategy as the default, although there will always be
>> workloads that "miss the window". The trade-off is increased CPU. We need
>> to tread carefully here because users reporting high CPU is why we changed
>> from the sleeping wait strategy to blocking. (The default in Log4j 2.6 will
>> be timeout blocking wait to deal with a deadlock issue in Solaris.)
>>
>> Long-term we should probably explore other data structures.
>>
>> Exciting times. Thanks for correcting me!
>>
>>
>>>
>>> On 22 May 2016 at 15:07, Benedict Elliott Smith 
>>> wrote:
>>>
 It's possible I'm missing some other aspect that insulates the
 application thread from the disruptor, but from your message it seems to me
 that you fall into the all-too-common category of people who do not fully
 understand the semantics of the disruptor.  Application threads (i.e.
 disruptor producers) very much *are* affected by the wait strategy.
 Under normal use, *if the disruptor consumer thread is employing a
 blocking strategy, there will be futex call to unblock it when work is
 provided*.  i.e. whenever the queue transitions from empty to
 non-empty, i.e. for most messages with low-to-medium logging rates.

 In this situation the enqueueing of a message is also* not lock free*,
 as while futexes can in theory be lock-free, the JVM uses a lock to
 synchronise access to the semaphore that controls its runnable state, so
 all threads attempting to wake it up concurrently will compete for this
 lock.



 On 22 May 2016 at 14:42, Remko Popma  wrote:

>
>
> On Sunday, May 22, 2016 at 6:34:13 PM UTC+9, Benedict Elliott Smith
> wrote:
>>
>> Hi Remko,
>>
>> I realise that I was looking at the old log4j code without realising
>> it, in which there is always a futex involved.
>>
> Which class is this? Async Loggers in Log4j 2 have always been
> lock-free. What may be confusing is that Log4j 2 also has an Async
> *Appender*, which does not use the Disruptor but uses a JDK
> BlockingArrayQueue. This appender is very similar to how Logback and Log4j
> 1 do asynchronous logging. Async*Appender* (in Log4j 2, Log4j 1 and
> Logback, they all use a blocking queue) is sensitive to lock contention 
> and
> does not scale with more threads.
>
>
>>
>> However the behaviour of the disruptor that backs the new code will
>> depend on the wait strategy employed (and I'll note your default is a
>> blocking strategy, for which my prior statement holds*).
>>
> Perhaps the key misunderstanding 

Re: Garbage-free Log4j docs preview

[Remko Popma]

On Monday, May 23, 2016 at 2:47:05 AM UTC+9, Benedict Elliott Smith wrote:
>
> Your pride should be saved by your gracious recognition of the error :)
>
>
> However this is the core of my point: you’re clearly an intelligent, 
> conscientious and talented developer, and yet you did not fully understand 
> these concerns.  You are writing core infrastructure many people will 
> deploy, and a majority will understand it much much less well.  So the very 
> best thing you can do is to educate them.  Doubly so if you needed 
> educating yourself!
>
;-) 

>
> I would make it very clear that users should only consider asynchronous 
> logging if they are having performance problems caused by their logging.  
> Only with sub-millisecond latency requirements should async be considered, 
> and below 100 micros you are entering busy-spinning territory.  Or if huge 
> message rates are being seen.  The best default is a blocking strategy, as 
> this has the closest performance profile to synchronous, and will prevent 
> the many users who deploy this without needing it from suffering any major 
> ill-effect.
>
I think I missed a step here. You made it plausible that under low 
workload, the Disruptor may not be better than ArrayBlockingQueue. 
Understood.

But I don't understand why users should only configure async logging in 
rare cases? Synchronous logging also involves holding a lock. Log4j 2 makes 
an effort to release this lock as soon as possible (locking only while 
copying a byte array from a thread-local buffer to the I/O device), but as 
Martin pointed out, in addition to the lock contention, other things may 
cause response time pauses when writing to the I/O device.

So which is "better": holding a lock to signal a 
java.util.concurrent.locks.Condition, versus holding a lock to write a byte 
array to the I/O device? The latter sounds like it has more risk of latency 
spikes. So I'm not sure I agree with your assessment that async logging has 
more risk of major ill effects.

Under low loads the upside of Async Loggers may not be as high as the graph 
suggests but I don't see any real downsides either. Please let me know if 
I'm missing something.
 

>
> I would also do a performance comparison with a real application.  
> Cassandra uses log4j, and the community has an easily utilised performance 
> tool.  You could try both DEBUG and INFO level, and put up some graphs.  
> This would help users make a more realistic and informed decision.
>
I agree it may be interesting for users to see a case study of some sort 
with a real application. Can you point me to the tool you are referring to?
 

>
> This may all seem a little disappointing: to *reduce* the number of 
> people who might use your amazing new technology.  But there will be 
> plenty, who both need it and do not and don't read or heed the warnings.
>
That's okay. It is garbage-free logging that is new in the 2.6 release, not 
the Async Loggers. The Disruptor-based Async Loggers have been used in the 
wild for about three years now. The response has generally been positive so 
I'm not panicking just yet. 
I do intend to follow up though and I take your point that under low load 
this technology may not give as much benefit as under high load. (Again, 
please correct me if there is a bigger problem and I'm missing any other 
downsides/risks.)
 

>
> Regarding improvements: In my opinion, a better algorithm for this 
> majority, of low-to-moderate traffic that is not extremely latency 
> sensitive, is semi-synchronous.  By which I mean for the first log call in 
> a batch to take exclusive ownership of the output and to write its message 
> synchronously; any messages that arrive while it has ownership are passed 
> to the owner to persist, i.e. they are written asynchronously.  To ensure 
> any thread’s ownership is brief, it would impose a time-limit, after which 
> a dedicated consumer could be started if the queue is still not exhausted.  
> This would have better than synchronous behaviour for low-to-moderate 
> traffic and scale gracefully to high traffic.
>
This is really interesting. It reminds me of one of the co-operative 
algorithms I read about in the Art of Multiprocessor Programming (I tried 
to look it up but could not find it last night).

It may be an idea to enhance the Disruptor for lower workloads: I guess the 
question is whether it is possible to incorporate a cheap check before 
calling waitStrategy.signalAllWhenBlocking() in MultiProducerSequence, and 
avoid calling that method if another thread is already signalling the 
consumer thread.
...and it turns out this already exists and is called 
LiteBlockingWaitStrategy. Good stuff! Perhaps all that is needed is combine 
the TimeoutBlockingWaitStrategy with this one and we can improve things 
nicely for lower workloads.

Does anyone on this list have any experience with LiteBlockingWaitStrategy? 
I see it was used in projectreactor.io, would be interested to hear how 
that 

Re: Garbage-free Log4j docs preview

[Mikael Ståldal]

Can the support for Intel TSX in Java 8u20 be relevant here?

https://bugs.openjdk.java.net/browse/JDK-8031320

On Sun, May 22, 2016 at 5:40 PM, Remko Popma  wrote:

>
>
> On Sunday, May 22, 2016 at 11:08:37 PM UTC+9, Benedict Elliott Smith wrote:
>>
>> It's possible I'm missing some other aspect that insulates the
>> application thread from the disruptor, but from your message it seems to me
>> that you fall into the all-too-common category of people who do not fully
>> understand the semantics of the disruptor.  Application threads (i.e.
>> disruptor producers) very much *are* affected by the wait strategy.
>> Under normal use, *if the disruptor consumer thread is employing a
>> blocking strategy, there will be futex call to unblock it when work is
>> provided*.  i.e. whenever the queue transitions from empty to non-empty,
>> i.e. for most messages with low-to-medium logging rates.
>>
>> In this situation the enqueueing of a message is also* not lock free*,
>> as while futexes can in theory be lock-free, the JVM uses a lock to
>> synchronise access to the semaphore that controls its runnable state, so
>> all threads attempting to wake it up concurrently will compete for this
>> lock.
>>
>
> Well... Looks like you were right and I was wrong.
>
> Interesting. Apart from the dent in my pride here, this is actually good
> news. It means we can do better!
>
> So in the worst-case scenario Async Loggers/Disruptor with the blocking
> wait strategy give performance equivalent to AsyncAppender with a
> BlockingArrayQueue. We can expect Async Loggers with Disruptor to
> outperform AsyncAppender with BlockingArrayQueue when workloads are high or
> bursts of work keep the background thread busy for some time. At least this
> is my understanding now. Or did I miss something and are there cases where
> Async Loggers with Disruptor will perform worse than AsyncAppender with
> BlockingArrayQueue?
>
> In terms of how to improve, short-term we should probably look at using
> the PhasedBackoffWaitStrategy as the default, although there will always be
> workloads that "miss the window". The trade-off is increased CPU. We need
> to tread carefully here because users reporting high CPU is why we changed
> from the sleeping wait strategy to blocking. (The default in Log4j 2.6 will
> be timeout blocking wait to deal with a deadlock issue in Solaris.)
>
> Long-term we should probably explore other data structures.
>
> Exciting times. Thanks for correcting me!
>
>
>>
>> On 22 May 2016 at 15:07, Benedict Elliott Smith 
>> wrote:
>>
>>> It's possible I'm missing some other aspect that insulates the
>>> application thread from the disruptor, but from your message it seems to me
>>> that you fall into the all-too-common category of people who do not fully
>>> understand the semantics of the disruptor.  Application threads (i.e.
>>> disruptor producers) very much *are* affected by the wait strategy.
>>> Under normal use, *if the disruptor consumer thread is employing a
>>> blocking strategy, there will be futex call to unblock it when work is
>>> provided*.  i.e. whenever the queue transitions from empty to
>>> non-empty, i.e. for most messages with low-to-medium logging rates.
>>>
>>> In this situation the enqueueing of a message is also* not lock free*,
>>> as while futexes can in theory be lock-free, the JVM uses a lock to
>>> synchronise access to the semaphore that controls its runnable state, so
>>> all threads attempting to wake it up concurrently will compete for this
>>> lock.
>>>
>>>
>>>
>>> On 22 May 2016 at 14:42, Remko Popma  wrote:
>>>


 On Sunday, May 22, 2016 at 6:34:13 PM UTC+9, Benedict Elliott Smith
 wrote:
>
> Hi Remko,
>
> I realise that I was looking at the old log4j code without realising
> it, in which there is always a futex involved.
>
 Which class is this? Async Loggers in Log4j 2 have always been
 lock-free. What may be confusing is that Log4j 2 also has an Async
 *Appender*, which does not use the Disruptor but uses a JDK
 BlockingArrayQueue. This appender is very similar to how Logback and Log4j
 1 do asynchronous logging. Async*Appender* (in Log4j 2, Log4j 1 and
 Logback, they all use a blocking queue) is sensitive to lock contention and
 does not scale with more threads.


>
> However the behaviour of the disruptor that backs the new code will
> depend on the wait strategy employed (and I'll note your default is a
> blocking strategy, for which my prior statement holds*).
>
 Perhaps the key misunderstanding is here. I think I did not explain it
 well in my previous message. Let me try again.

 Async Loggers use the Disruptor and are lock-free. This means that
 multiple application threads can log concurrently and are not blocked by
 each other. This is true for very low workloads, medium workloads and high
 workloads.

Re: Garbage-free Log4j docs preview

[Remko Popma]

On Sunday, May 22, 2016 at 11:08:37 PM UTC+9, Benedict Elliott Smith wrote:
>
> It's possible I'm missing some other aspect that insulates the application 
> thread from the disruptor, but from your message it seems to me that you 
> fall into the all-too-common category of people who do not fully understand 
> the semantics of the disruptor.  Application threads (i.e. disruptor 
> producers) very much *are* affected by the wait strategy.  Under normal 
> use, *if the disruptor consumer thread is employing a blocking strategy, 
> there will be futex call to unblock it when work is provided*.  i.e. 
> whenever the queue transitions from empty to non-empty, i.e. for most 
> messages with low-to-medium logging rates.
>
> In this situation the enqueueing of a message is also* not lock free*, as 
> while futexes can in theory be lock-free, the JVM uses a lock to 
> synchronise access to the semaphore that controls its runnable state, so 
> all threads attempting to wake it up concurrently will compete for this 
> lock.
>

Well... Looks like you were right and I was wrong. 

Interesting. Apart from the dent in my pride here, this is actually good 
news. It means we can do better!

So in the worst-case scenario Async Loggers/Disruptor with the blocking 
wait strategy give performance equivalent to AsyncAppender with a 
BlockingArrayQueue. We can expect Async Loggers with Disruptor to 
outperform AsyncAppender with BlockingArrayQueue when workloads are high or 
bursts of work keep the background thread busy for some time. At least this 
is my understanding now. Or did I miss something and are there cases where 
Async Loggers with Disruptor will perform worse than AsyncAppender with 
BlockingArrayQueue?

In terms of how to improve, short-term we should probably look at using 
the PhasedBackoffWaitStrategy as the default, although there will always be 
workloads that "miss the window". The trade-off is increased CPU. We need 
to tread carefully here because users reporting high CPU is why we changed 
from the sleeping wait strategy to blocking. (The default in Log4j 2.6 will 
be timeout blocking wait to deal with a deadlock issue in Solaris.)

Long-term we should probably explore other data structures.

Exciting times. Thanks for correcting me!


>
> On 22 May 2016 at 15:07, Benedict Elliott Smith  > wrote:
>
>> It's possible I'm missing some other aspect that insulates the 
>> application thread from the disruptor, but from your message it seems to me 
>> that you fall into the all-too-common category of people who do not fully 
>> understand the semantics of the disruptor.  Application threads (i.e. 
>> disruptor producers) very much *are* affected by the wait strategy.  
>> Under normal use, *if the disruptor consumer thread is employing a 
>> blocking strategy, there will be futex call to unblock it when work is 
>> provided*.  i.e. whenever the queue transitions from empty to non-empty, 
>> i.e. for most messages with low-to-medium logging rates.
>>
>> In this situation the enqueueing of a message is also* not lock free*, 
>> as while futexes can in theory be lock-free, the JVM uses a lock to 
>> synchronise access to the semaphore that controls its runnable state, so 
>> all threads attempting to wake it up concurrently will compete for this 
>> lock.
>>
>>
>>
>> On 22 May 2016 at 14:42, Remko Popma  
>> wrote:
>>
>>>
>>>
>>> On Sunday, May 22, 2016 at 6:34:13 PM UTC+9, Benedict Elliott Smith 
>>> wrote:

 Hi Remko,

 I realise that I was looking at the old log4j code without realising 
 it, in which there is always a futex involved.

>>> Which class is this? Async Loggers in Log4j 2 have always been 
>>> lock-free. What may be confusing is that Log4j 2 also has an Async
>>> *Appender*, which does not use the Disruptor but uses a JDK 
>>> BlockingArrayQueue. This appender is very similar to how Logback and Log4j 
>>> 1 do asynchronous logging. Async*Appender* (in Log4j 2, Log4j 1 and 
>>> Logback, they all use a blocking queue) is sensitive to lock contention and 
>>> does not scale with more threads.
>>>  
>>>

 However the behaviour of the disruptor that backs the new code will 
 depend on the wait strategy employed (and I'll note your default is a 
 blocking strategy, for which my prior statement holds*).

>>> Perhaps the key misunderstanding is here. I think I did not explain it 
>>> well in my previous message. Let me try again.
>>>
>>> Async Loggers use the Disruptor and are lock-free. This means that 
>>> multiple application threads can log concurrently and are not blocked by 
>>> each other. This is true for very low workloads, medium workloads and high 
>>> workloads. 
>>>
>>> Only if an application logs messages at a very high rate for a long 
>>> period of time, or uses a slow appender, the Disruptor ringbuffer can fill 
>>> up and application threads will have to wait until a slot in the ringbuffer 
>>> 

Re: Garbage-free Log4j docs preview

[Benedict Elliott Smith]

It's possible I'm missing some other aspect that insulates the application
thread from the disruptor, but from your message it seems to me that you
fall into the all-too-common category of people who do not fully understand
the semantics of the disruptor.  Application threads (i.e. disruptor
producers) very much *are* affected by the wait strategy.  Under normal
use, *if the disruptor consumer thread is employing a blocking strategy,
there will be futex call to unblock it when work is provided*.  i.e.
whenever the queue transitions from empty to non-empty, i.e. for most
messages with low-to-medium logging rates.

In this situation the enqueueing of a message is also* not lock free*, as
while futexes can in theory be lock-free, the JVM uses a lock to
synchronise access to the semaphore that controls its runnable state, so
all threads attempting to wake it up concurrently will compete for this
lock.



On 22 May 2016 at 14:42, Remko Popma  wrote:

>
>
> On Sunday, May 22, 2016 at 6:34:13 PM UTC+9, Benedict Elliott Smith wrote:
>>
>> Hi Remko,
>>
>> I realise that I was looking at the old log4j code without realising it,
>> in which there is always a futex involved.
>>
> Which class is this? Async Loggers in Log4j 2 have always been lock-free.
> What may be confusing is that Log4j 2 also has an Async*Appender*, which
> does not use the Disruptor but uses a JDK BlockingArrayQueue. This appender
> is very similar to how Logback and Log4j 1 do asynchronous logging. Async
> *Appender* (in Log4j 2, Log4j 1 and Logback, they all use a blocking
> queue) is sensitive to lock contention and does not scale with more threads.
>
>
>>
>> However the behaviour of the disruptor that backs the new code will
>> depend on the wait strategy employed (and I'll note your default is a
>> blocking strategy, for which my prior statement holds*).
>>
> Perhaps the key misunderstanding is here. I think I did not explain it
> well in my previous message. Let me try again.
>
> Async Loggers use the Disruptor and are lock-free. This means that
> multiple application threads can log concurrently and are not blocked by
> each other. This is true for very low workloads, medium workloads and high
> workloads.
>
> Only if an application logs messages at a very high rate for a long period
> of time, or uses a slow appender, the Disruptor ringbuffer can fill up and
> application threads will have to wait until a slot in the ringbuffer
> becomes available. For the 2.6 release I have added text to the
> Trade-offs section
> 
> to explain this last point, based on your feedback.
>
> Note that the Disruptor wait strategy is irrelevant to all this.
> Application threads are *not *impacted by the wait strategy.
>
>
>> Here we obviously get into the territory of people needing to understand
>> the disruptor as well as your logging framework, but since you have a whole
>> section labelled "Trade-offs" in which you draw attention to the improved
>> throughput and latency profile under "Benefits," under "Drawbacks" it might
>> be nice to mention these possible confounders.  Or at least raise a bat
>> signal to go and understand the tradeoffs for the disruptor (which is also
>> regrettably poorly understood).
>>
>> It might also be helpful to explicitly call out the configuration used
>> for your benchmarks,
>>
> Tests on the 2.6 performance page
>  are mostly
> done with JMH benchmarks where parameters are in the javadoc.
> Tests on the Async Loggers page are partly with the new ResponseTimeTest
> class
> (params in the doc
> ) and
> partly still shows results from the older PerfTestDriver
> 
> class. This last one has parameters in the code. You'll need to spend some
> time to get familiar with it if you want to run it.
>
> and perhaps to run a comparison against some real software - github does
>> not lack for applications using log4j!  Unfortunately I bet this would
>> result in a much less sexy graph.
>>
> Log4j 2 has had lock-free Async Loggers from its 2.0-beta5 release
> ,
> three years ago. If there are any serious performance drawbacks like you
> seem to think there are I hope I would have heard of them. Fortunately the
> opposite is true. People report very positive experiences
> .
> People who did their own measurements reported it makes 

Re: Garbage-free Log4j docs preview

[Remko Popma]

On Sunday, May 22, 2016 at 6:34:13 PM UTC+9, Benedict Elliott Smith wrote:
>
> Hi Remko,
>
> I realise that I was looking at the old log4j code without realising it, 
> in which there is always a futex involved.
>
Which class is this? Async Loggers in Log4j 2 have always been lock-free. 
What may be confusing is that Log4j 2 also has an Async*Appender*, which 
does not use the Disruptor but uses a JDK BlockingArrayQueue. This appender 
is very similar to how Logback and Log4j 1 do asynchronous logging. Async
*Appender* (in Log4j 2, Log4j 1 and Logback, they all use a blocking queue) 
is sensitive to lock contention and does not scale with more threads.
 

>
> However the behaviour of the disruptor that backs the new code will depend 
> on the wait strategy employed (and I'll note your default is a blocking 
> strategy, for which my prior statement holds*).
>
Perhaps the key misunderstanding is here. I think I did not explain it well 
in my previous message. Let me try again.

Async Loggers use the Disruptor and are lock-free. This means that multiple 
application threads can log concurrently and are not blocked by each other. 
This is true for very low workloads, medium workloads and high workloads. 

Only if an application logs messages at a very high rate for a long period 
of time, or uses a slow appender, the Disruptor ringbuffer can fill up and 
application threads will have to wait until a slot in the ringbuffer 
becomes available. For the 2.6 release I have added text to the Trade-offs 
section 
 to 
explain this last point, based on your feedback.

Note that the Disruptor wait strategy is irrelevant to all this. 
Application threads are *not *impacted by the wait strategy.


> Here we obviously get into the territory of people needing to understand 
> the disruptor as well as your logging framework, but since you have a whole 
> section labelled "Trade-offs" in which you draw attention to the improved 
> throughput and latency profile under "Benefits," under "Drawbacks" it might 
> be nice to mention these possible confounders.  Or at least raise a bat 
> signal to go and understand the tradeoffs for the disruptor (which is also 
> regrettably poorly understood).  
>
> It might also be helpful to explicitly call out the configuration used for 
> your benchmarks, 
>
Tests on the 2.6 performance page 
 are mostly done 
with JMH benchmarks where parameters are in the javadoc.
Tests on the Async Loggers page are partly with the new ResponseTimeTest 
class
 
(params in the doc 
) and 
partly still shows results from the older PerfTestDriver 

 
class. This last one has parameters in the code. You'll need to spend some 
time to get familiar with it if you want to run it.

and perhaps to run a comparison against some real software - github does 
> not lack for applications using log4j!  Unfortunately I bet this would 
> result in a much less sexy graph.
>
Log4j 2 has had lock-free Async Loggers from its 2.0-beta5 release 
, three 
years ago. If there are any serious performance drawbacks like you seem to 
think there are I hope I would have heard of them. Fortunately the opposite 
is true. People report very positive experiences 
. 
People who did their own measurements reported it makes their logging as 
fast as if it was switched off 
.


> Finally, I really think people should (in your wiki page) explicitly be 
> *discouraged* from using this part of your framework *unless they know 
> they need it*.  It's a fantastic piece of work for people who *do* need 
> it.  
>
Again, I think you are laboring under a misapprehension. I cannot imagine a 
scenario where lock-free logging would be a bad thing. If you think there 
is, please show evidence.
 

> But 99.99% of people would be better off with a logger that just avoids 
> blocking threads when one is already in the process of logging. 
>
Avoiding blocking is exactly what the Async Loggers are for. (So I really 
think there is some misunderstanding somewhere.)
Based on your feedback, I've updated 
 the side nav 
menu and page title for the 2.6 release to clarify that Async Loggers are 
lock-free. I hope this will help avoid misunderstandings.
 

Re: Garbage-free Log4j docs preview

[Remko Popma]

After looking more closely I found that the 
org.slf4j.spi.LocationAwareLogger::log 
 method is currently not implemented in a garbage-free 
manner in the log4j-slf4j-impl binding. It creates a new message object for 
each call. If there is interest we can address this in a future release. 
Other methods seem okay. 


On Thursday, May 19, 2016 at 4:57:10 PM UTC+9, Jerry Shea wrote:
>
> Ok thanks!
> On 19 May 2016 5:10 pm, "Remko Popma"  
> wrote:
>
>> On Thursday, May 19, 2016 at 11:10:45 AM UTC+9, Jerry Shea wrote:
>> > This is fantastic, thanks for this Remko.
>> >
>> >
>> > Can I ask a couple of questions?
>> > 1. is log4j 2.6 designed to operate garbage-free when used as an SLF4J 
>> implementation too, or only with the native API?
>>
>> The log4j-slf4j-impl binding is trying to be garbage-free, but the SLF4J 
>> API only offers up to two parameters for a parameterized message. More than 
>> that uses varargs which creates a temporary object for the parameter array. 
>> The native Log4j 2.6 API has methods for up to ten unrolled parameters.
>>
>> Another consideration is that the native Log4j 2 API lets you log 
>> Objects, not just Strings. Any Object that implements CharSequence can be 
>> logged without creating garbage.
>>
>> You can also implement the log4j Message interface if you want to 
>> separate formatting from your business domain objects.
>>
>> Finally, the native Log4j 2 API has support for logging Java 8 lambdas 
>> (since 2.4).
>>
>> > 2. when do you expect log4j 2.6 to be released GA i.e. ready for 
>> production use?
>>
>> Barring any showstoppers, I expect it will be available in a week or so.
>>
>>
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: Garbage-free Log4j docs preview

[Remko Popma]

On Thursday, May 19, 2016 at 11:10:45 AM UTC+9, Jerry Shea wrote:
> This is fantastic, thanks for this Remko.
> 
> 
> Can I ask a couple of questions?
> 1. is log4j 2.6 designed to operate garbage-free when used as an SLF4J 
> implementation too, or only with the native API?

The log4j-slf4j-impl binding is trying to be garbage-free, but the SLF4J API 
only offers up to two parameters for a parameterized message. More than that 
uses varargs which creates a temporary object for the parameter array. The 
native Log4j 2.6 API has methods for up to ten unrolled parameters. 

Another consideration is that the native Log4j 2 API lets you log Objects, not 
just Strings. Any Object that implements CharSequence can be logged without 
creating garbage.

You can also implement the log4j Message interface if you want to separate 
formatting from your business domain objects. 

Finally, the native Log4j 2 API has support for logging Java 8 lambdas (since 
2.4).
 
> 2. when do you expect log4j 2.6 to be released GA i.e. ready for production 
> use?

Barring any showstoppers, I expect it will be available in a week or so. 

> 
> 
> Thansk, Jerry
> 
> On Thursday, 19 May 2016 09:36:01 UTC+10, Remko Popma  wrote:
> Thank you Martin, appreciated! :-)
> 
> On Wednesday, May 18, 2016 at 2:33:55 AM UTC+9, Martin Thompson wrote:
> Hi Remko,
> 
> 
> I'd just like to say that it is a great service to the community as a whole 
> that someone is seriously looking at improving logging.
> 
> 
> If you keep it up you'll be putting folks like me out of a job :)
> 
> 
> Martin...
> 
> 
> 
> 
> On 17 May 2016 at 18:13, Remko Popma  wrote:
> 
> Hi all,
> 
> 
> First, my thanks to the many people who gave helpful advice and feedback on 
> how to measure Log4j response time on this list some time ago.
> 
> 
> We're about to start the Log4j 2.6 release.
> If anyone is interested, a preview of the garbage-free logging manual page is 
> here: http://home.apache.org/~rpopma/log4j/2.6/manual/garbagefree.html
> and a preview of the updated performance page is here: 
> http://home.apache.org/~rpopma/log4j/2.6/performance.html
> 
> 
> Feedback welcome!
> 
> 
> Remko
> 
> 
> 
> 
> 
> 
> -- 
> 
> You received this message because you are subscribed to the Google Groups 
> "mechanical-sympathy" group.
> 
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to mechanical-sympathy+unsubscr...@googlegroups.com.
> 
> For more options, visit https://groups.google.com/d/optout.



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

Re: Garbage-free Log4j docs preview

[Remko Popma]

Thank you Martin, appreciated! :-)

On Wednesday, May 18, 2016 at 2:33:55 AM UTC+9, Martin Thompson wrote:
>
> Hi Remko,
>
> I'd just like to say that it is a great service to the community as a 
> whole that someone is seriously looking at improving logging.
>
> If you keep it up you'll be putting folks like me out of a job :)
>
> Martin...
>
>
> On 17 May 2016 at 18:13, Remko Popma  
> wrote:
>
>> Hi all,
>>
>> First, my thanks to the many people who gave helpful advice and feedback 
>> on how to measure Log4j response time on this list some time ago.
>>
>> We're about to start the Log4j 2.6 release.
>> If anyone is interested, a preview of the garbage-free logging manual 
>> page is here: 
>> http://home.apache.org/~rpopma/log4j/2.6/manual/garbagefree.html
>> and a preview of the updated performance page is here: 
>> http://home.apache.org/~rpopma/log4j/2.6/performance.html
>>
>> Feedback welcome!
>>
>> Remko
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "mechanical-sympathy" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to mechanical-sympathy+unsubscr...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: Garbage-free Log4j docs preview

[Remko Popma]

I see. I was under the impression that the Filter checked
by Logger.isEnabled() was a composite of the global filters and the Logger
filter, but I just assumed and never really checked. Thanks for correcting
me.

Yes, I agree this is a good idea for a future enhancement.

I don't know how often people configure filters on AppenderRef though.
Depending on how expensive it is to check AppenderRef filters it may make
most sense to just check the LoggerConfig filters before enqueuing the log
event.

Remko

On Wednesday, 18 May 2016, Ralph Goers  wrote:

> That is only checking the global filters.  Filters can also be on the
> Logger (or more accurately, the LoggerConfig), AppenderRef, or Appender. I
> don’t think it would ever work to check the filters on the appenders, but I
> would think it would be possible to check those on the Logger and possibly
> even the AppenderRef, although checking the AppenderRef could get very
> complicated.
>
> Ralph
>
> On May 17, 2016, at 6:37 PM, Remko Popma  > wrote:
>
> Ralph,
>
> I don't think so: AbstractLogger calls logIfEnabled() which calls
> isEnabled() before calling logMessage().
>
> So, even with AsyncLogger the Filters on the Logger are checked before the
> event is created or enqueued.
>
> I don't see an issue with the current code.
>
> Remko
>
> Sent from my iPhone
>
> On 2016/05/18, at 6:33, Ralph Goers  > wrote:
>
> Remko,
>
> Benedict makes a good point. While I don’t think filters on appenders
> should be called before putting events on the queue we should probably be
> executing the filters on the Logger. But currently those are called in the
> LoggerConfig, which I think is after the events are added to the queue.
>
> Ralph
>
> On May 17, 2016, at 12:55 PM, Benedict Elliott Smith  > wrote:
>
> Could I suggest that you run tests for latency and throughput effects of
> using this in systems with only moderate-to-low numbers of logging calls?
>  (i.e. the vast majority of systems!)
>
> It's very likely that in such systems messages will not reach a velocity
> to keep the Dispatcher running, and so logging calls may often (or always)
> involve a Futex call - which is not a trivial cost.  There will almost
> certainly be systems out there with anti-ideal characteristics - logging
> just often enough that these costs materially impact throughput, but not
> often enough that they suddenly disappear.
>
> Even though a majority of systems *do not need this*, because it "async"
> and the new hotness, and there are no advertised downsides, everyone will
> try to use it.  It's up to those who know better to make sure these people
> are informed it isn't a free lunch.  Making sure all of the caveats are
> reported on the advertising page would be a great start IMO.
>
> Might I also separately suggest you consider filtering events prior to
> placing them on the queue for processing by the dispatcher?  I've only
> briefly glanced at the code, but it seems not to be the case currently.
>
>
> On 17 May 2016 at 18:50, Benedict Elliott Smith <_...@belliottsmith.com
> > wrote:
>
>> Could I suggest that you run tests for latency and throughput effects of
>> using this in systems with only moderate-to-low numbers of logging calls?
>>  (i.e. the vast majority of systems!)
>>
>> It's very likely that in such systems messages will not reach a velocity
>> to keep the Dispatcher running, and so logging calls may often (or always)
>> involve a Futex call - which is not a trivial cost.  There will almost
>> certainly be systems out there with anti-ideal characteristics - logging
>> just often enough that these costs materially impact throughput, but not
>> often enough that they suddenly disappear.
>>
>> Even though a majority of systems *do not need this*, because it "async"
>> and the new hotness, and there are no advertised downsides, everyone will
>> try to use it.  It's up to those who know better to make sure these people
>> are informed it isn't a free lunch.  Making sure all of the caveats are
>> reported on the advertising page would be a great start IMO.
>>
>> Might I also separately suggest you consider filtering events prior to
>> placing them on the queue for processing by the dispatcher?  I've only
>> briefly glanced at the code, but it seems not to be the case currently.
>>
>> On 17 May 2016 at 18:33, Martin Thompson > > wrote:
>>
>>> Hi Remko,
>>>
>>> I'd just like to say that it is a great service to the community as a
>>> whole that someone is seriously looking at improving logging.
>>>
>>> If you keep it up you'll be putting folks like me out of a job :)
>>>
>>> Martin...
>>>

Re: Garbage-free Log4j docs preview

[Ralph Goers]

That is only checking the global filters.  Filters can also be on the Logger 
(or more accurately, the LoggerConfig), AppenderRef, or Appender. I don’t think 
it would ever work to check the filters on the appenders, but I would think it 
would be possible to check those on the Logger and possibly even the 
AppenderRef, although checking the AppenderRef could get very complicated. 

Ralph

> On May 17, 2016, at 6:37 PM, Remko Popma  wrote:
> 
> Ralph,
> 
> I don't think so: AbstractLogger calls logIfEnabled() which calls isEnabled() 
> before calling logMessage(). 
> 
> So, even with AsyncLogger the Filters on the Logger are checked before the 
> event is created or enqueued. 
> 
> I don't see an issue with the current code. 
> 
> Remko
> 
> Sent from my iPhone
> 
> On 2016/05/18, at 6:33, Ralph Goers  > wrote:
> 
>> Remko,  
>> 
>> Benedict makes a good point. While I don’t think filters on appenders should 
>> be called before putting events on the queue we should probably be executing 
>> the filters on the Logger. But currently those are called in the 
>> LoggerConfig, which I think is after the events are added to the queue.
>> 
>> Ralph
>> 
>>> On May 17, 2016, at 12:55 PM, Benedict Elliott Smith >> > wrote:
>>> 
>>> Could I suggest that you run tests for latency and throughput effects of 
>>> using this in systems with only moderate-to-low numbers of logging calls?  
>>> (i.e. the vast majority of systems!)
>>> 
>>> It's very likely that in such systems messages will not reach a velocity to 
>>> keep the Dispatcher running, and so logging calls may often (or always) 
>>> involve a Futex call - which is not a trivial cost.  There will almost 
>>> certainly be systems out there with anti-ideal characteristics - logging 
>>> just often enough that these costs materially impact throughput, but not 
>>> often enough that they suddenly disappear.  
>>> 
>>> Even though a majority of systems do not need this, because it "async" and 
>>> the new hotness, and there are no advertised downsides, everyone will try 
>>> to use it.  It's up to those who know better to make sure these people are 
>>> informed it isn't a free lunch.  Making sure all of the caveats are 
>>> reported on the advertising page would be a great start IMO.
>>> 
>>> Might I also separately suggest you consider filtering events prior to 
>>> placing them on the queue for processing by the dispatcher?  I've only 
>>> briefly glanced at the code, but it seems not to be the case currently.
>>> 
>>> 
>>> On 17 May 2016 at 18:50, Benedict Elliott Smith <_...@belliottsmith.com 
>>> > wrote:
>>> Could I suggest that you run tests for latency and throughput effects of 
>>> using this in systems with only moderate-to-low numbers of logging calls?  
>>> (i.e. the vast majority of systems!)
>>> 
>>> It's very likely that in such systems messages will not reach a velocity to 
>>> keep the Dispatcher running, and so logging calls may often (or always) 
>>> involve a Futex call - which is not a trivial cost.  There will almost 
>>> certainly be systems out there with anti-ideal characteristics - logging 
>>> just often enough that these costs materially impact throughput, but not 
>>> often enough that they suddenly disappear.  
>>> 
>>> Even though a majority of systems do not need this, because it "async" and 
>>> the new hotness, and there are no advertised downsides, everyone will try 
>>> to use it.  It's up to those who know better to make sure these people are 
>>> informed it isn't a free lunch.  Making sure all of the caveats are 
>>> reported on the advertising page would be a great start IMO.
>>> 
>>> Might I also separately suggest you consider filtering events prior to 
>>> placing them on the queue for processing by the dispatcher?  I've only 
>>> briefly glanced at the code, but it seems not to be the case currently.
>>> 
>>> On 17 May 2016 at 18:33, Martin Thompson >> > wrote:
>>> Hi Remko,
>>> 
>>> I'd just like to say that it is a great service to the community as a whole 
>>> that someone is seriously looking at improving logging.
>>> 
>>> If you keep it up you'll be putting folks like me out of a job :)
>>> 
>>> Martin...
>>> 
>>> 
>>> On 17 May 2016 at 18:13, Remko Popma >> > wrote:
>>> Hi all,
>>> 
>>> First, my thanks to the many people who gave helpful advice and feedback on 
>>> how to measure Log4j response time on this list some time ago.
>>> 
>>> We're about to start the Log4j 2.6 release.
>>> If anyone is interested, a preview of the garbage-free logging manual page 
>>> is here: http://home.apache.org/~rpopma/log4j/2.6/manual/garbagefree.html 
>>> 
>>> and a preview of the updated performance 

Re: Garbage-free Log4j docs preview

[Ralph Goers]

Remko,  

Benedict makes a good point. While I don’t think filters on appenders should be 
called before putting events on the queue we should probably be executing the 
filters on the Logger. But currently those are called in the LoggerConfig, 
which I think is after the events are added to the queue.

Ralph

> On May 17, 2016, at 12:55 PM, Benedict Elliott Smith  
> wrote:
> 
> Could I suggest that you run tests for latency and throughput effects of 
> using this in systems with only moderate-to-low numbers of logging calls?  
> (i.e. the vast majority of systems!)
> 
> It's very likely that in such systems messages will not reach a velocity to 
> keep the Dispatcher running, and so logging calls may often (or always) 
> involve a Futex call - which is not a trivial cost.  There will almost 
> certainly be systems out there with anti-ideal characteristics - logging just 
> often enough that these costs materially impact throughput, but not often 
> enough that they suddenly disappear.  
> 
> Even though a majority of systems do not need this, because it "async" and 
> the new hotness, and there are no advertised downsides, everyone will try to 
> use it.  It's up to those who know better to make sure these people are 
> informed it isn't a free lunch.  Making sure all of the caveats are reported 
> on the advertising page would be a great start IMO.
> 
> Might I also separately suggest you consider filtering events prior to 
> placing them on the queue for processing by the dispatcher?  I've only 
> briefly glanced at the code, but it seems not to be the case currently.
> 
> 
> On 17 May 2016 at 18:50, Benedict Elliott Smith <_...@belliottsmith.com 
> > wrote:
> Could I suggest that you run tests for latency and throughput effects of 
> using this in systems with only moderate-to-low numbers of logging calls?  
> (i.e. the vast majority of systems!)
> 
> It's very likely that in such systems messages will not reach a velocity to 
> keep the Dispatcher running, and so logging calls may often (or always) 
> involve a Futex call - which is not a trivial cost.  There will almost 
> certainly be systems out there with anti-ideal characteristics - logging just 
> often enough that these costs materially impact throughput, but not often 
> enough that they suddenly disappear.  
> 
> Even though a majority of systems do not need this, because it "async" and 
> the new hotness, and there are no advertised downsides, everyone will try to 
> use it.  It's up to those who know better to make sure these people are 
> informed it isn't a free lunch.  Making sure all of the caveats are reported 
> on the advertising page would be a great start IMO.
> 
> Might I also separately suggest you consider filtering events prior to 
> placing them on the queue for processing by the dispatcher?  I've only 
> briefly glanced at the code, but it seems not to be the case currently.
> 
> On 17 May 2016 at 18:33, Martin Thompson  > wrote:
> Hi Remko,
> 
> I'd just like to say that it is a great service to the community as a whole 
> that someone is seriously looking at improving logging.
> 
> If you keep it up you'll be putting folks like me out of a job :)
> 
> Martin...
> 
> 
> On 17 May 2016 at 18:13, Remko Popma  > wrote:
> Hi all,
> 
> First, my thanks to the many people who gave helpful advice and feedback on 
> how to measure Log4j response time on this list some time ago.
> 
> We're about to start the Log4j 2.6 release.
> If anyone is interested, a preview of the garbage-free logging manual page is 
> here: http://home.apache.org/~rpopma/log4j/2.6/manual/garbagefree.html 
> 
> and a preview of the updated performance page is here: 
> http://home.apache.org/~rpopma/log4j/2.6/performance.html 
> 
> 
> Feedback welcome!
> 
> Remko
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "mechanical-sympathy" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to mechanical-sympathy+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "mechanical-sympathy" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to mechanical-sympathy+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 

Re: Garbage-free Log4j docs preview

[Benedict Elliott Smith]

Could I suggest that you run tests for latency and throughput effects of
using this in systems with only moderate-to-low numbers of logging calls?
 (i.e. the vast majority of systems!)

It's very likely that in such systems messages will not reach a velocity to
keep the Dispatcher running, and so logging calls may often (or always)
involve a Futex call - which is not a trivial cost.  There will almost
certainly be systems out there with anti-ideal characteristics - logging
just often enough that these costs materially impact throughput, but not
often enough that they suddenly disappear.

Even though a majority of systems *do not need this*, because it "async"
and the new hotness, and there are no advertised downsides, everyone will
try to use it.  It's up to those who know better to make sure these people
are informed it isn't a free lunch.  Making sure all of the caveats are
reported on the advertising page would be a great start IMO.

Might I also separately suggest you consider filtering events prior to
placing them on the queue for processing by the dispatcher?  I've only
briefly glanced at the code, but it seems not to be the case currently.


On 17 May 2016 at 18:50, Benedict Elliott Smith <_...@belliottsmith.com> wrote:

> Could I suggest that you run tests for latency and throughput effects of
> using this in systems with only moderate-to-low numbers of logging calls?
>  (i.e. the vast majority of systems!)
>
> It's very likely that in such systems messages will not reach a velocity
> to keep the Dispatcher running, and so logging calls may often (or always)
> involve a Futex call - which is not a trivial cost.  There will almost
> certainly be systems out there with anti-ideal characteristics - logging
> just often enough that these costs materially impact throughput, but not
> often enough that they suddenly disappear.
>
> Even though a majority of systems *do not need this*, because it "async"
> and the new hotness, and there are no advertised downsides, everyone will
> try to use it.  It's up to those who know better to make sure these people
> are informed it isn't a free lunch.  Making sure all of the caveats are
> reported on the advertising page would be a great start IMO.
>
> Might I also separately suggest you consider filtering events prior to
> placing them on the queue for processing by the dispatcher?  I've only
> briefly glanced at the code, but it seems not to be the case currently.
>
> On 17 May 2016 at 18:33, Martin Thompson  wrote:
>
>> Hi Remko,
>>
>> I'd just like to say that it is a great service to the community as a
>> whole that someone is seriously looking at improving logging.
>>
>> If you keep it up you'll be putting folks like me out of a job :)
>>
>> Martin...
>>
>>
>> On 17 May 2016 at 18:13, Remko Popma  wrote:
>>
>>> Hi all,
>>>
>>> First, my thanks to the many people who gave helpful advice and feedback
>>> on how to measure Log4j response time on this list some time ago.
>>>
>>> We're about to start the Log4j 2.6 release.
>>> If anyone is interested, a preview of the garbage-free logging manual
>>> page is here:
>>> http://home.apache.org/~rpopma/log4j/2.6/manual/garbagefree.html
>>> and a preview of the updated performance page is here:
>>> http://home.apache.org/~rpopma/log4j/2.6/performance.html
>>>
>>> Feedback welcome!
>>>
>>> Remko
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "mechanical-sympathy" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to mechanical-sympathy+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "mechanical-sympathy" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to mechanical-sympathy+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

Re: Garbage-free Log4j docs preview

[Remko Popma]

To log4j-dev:

FYI the Mechanical Sympathy Google group is where a number of Java
performance experts hang out.

My previous post there was:
https://groups.google.com/forum/m/#!topic/mechanical-sympathy/HwTrOMnm6h0

Remko

On Wednesday, 18 May 2016, Remko Popma  wrote:

> Hi all,
>
> First, my thanks to the many people who gave helpful advice and feedback
> on how to measure Log4j response time on this list some time ago.
>
> We're about to start the Log4j 2.6 release.
> If anyone is interested, a preview of the garbage-free logging manual page
> is here: http://home.apache.org/~rpopma/log4j/2.6/manual/garbagefree.html
> and a preview of the updated performance page is here:
> http://home.apache.org/~rpopma/log4j/2.6/performance.html
>
> Feedback welcome!
>
> Remko
>
>

Garbage-free Log4j docs preview

[Remko Popma]

Hi all,

First, my thanks to the many people who gave helpful advice and feedback on 
how to measure Log4j response time on this list some time ago.

We're about to start the Log4j 2.6 release.
If anyone is interested, a preview of the garbage-free logging manual page 
is here: http://home.apache.org/~rpopma/log4j/2.6/manual/garbagefree.html
and a preview of the updated performance page is here: 
http://home.apache.org/~rpopma/log4j/2.6/performance.html

Feedback welcome!

Remko


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

Re: Bad PatternLayout site docs

[Gary Gregory]

Thanks Remko. Fixed.

G

On Thu, Oct 1, 2015 at 12:04 AM, Remko Popma <remko.po...@gmail.com> wrote:

> Good catch! The 2nd explanation has more detail, looks like the 1st row
> can be deleted.
>
> Small detail:  the "{pattern}" part of "enc{pattern} encode{pattern}" in
> the 2nd row should not use bold font.
>
> Sent from my iPhone
>
> On 2015/10/01, at 1:43, Gary Gregory <garydgreg...@gmail.com> wrote:
>
> The site docs at
> https://logging.apache.org/log4j/2.x/manual/layouts.html#PatternLayout
>
> shows this conversion pattern twice:
>
> enc{pattern}
> encode{pattern>
>
> and
>
> enc{pattern}
> encode{pattern}
>
> Something's not right! :-(
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> 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
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Bad PatternLayout site docs

[Remko Popma]

Good catch! The 2nd explanation has more detail, looks like the 1st row can be 
deleted. 

Small detail:  the "{pattern}" part of "enc{pattern} encode{pattern}" in the 
2nd row should not use bold font. 

Sent from my iPhone

> On 2015/10/01, at 1:43, Gary Gregory <garydgreg...@gmail.com> wrote:
> 
> The site docs at 
> https://logging.apache.org/log4j/2.x/manual/layouts.html#PatternLayout
> 
> shows this conversion pattern twice:
> 
> enc{pattern}
> encode{pattern>   
> 
> and 
> 
> enc{pattern}
> encode{pattern}
> 
> Something's not right! :-(
> 
> -- 
> 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

Bad PatternLayout site docs

[Gary Gregory]

The site docs at
https://logging.apache.org/log4j/2.x/manual/layouts.html#PatternLayout

shows this conversion pattern twice:

enc{pattern}
encode{pattern>

and

enc{pattern}
encode{pattern}

Something's not right! :-(

-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[jira] [Created] (LOG4NET-459) Generated API docs are unreadable

[Berin Loritsch (JIRA)]

Berin Loritsch created LOG4NET-459:
--

 Summary: Generated API docs are unreadable
 Key: LOG4NET-459
 URL: https://issues.apache.org/jira/browse/LOG4NET-459
 Project: Log4net
  Issue Type: Bug
Reporter: Berin Loritsch


Due to a character encoding problem, important characters like  and  and 
whatever character is used as a leader in the object hierarchy are completely 
mangled and hinders readability.

For an example see:

http://logging.apache.org/log4net/release/sdk/log4net.Appender.RollingFileAppender.html

Something in the build processing is messing things up, or the HTML is really 
UTF-8 but we are calling it Windows 1521.  See the following line the header 
section of the HTML:

{code}
meta http-equiv=Content-Type content=text/html; charset=Windows-1252 /
{code}

By manually changing that line to 

{code}
meta http-equiv=Content-Type content=text/html; charset=UTF-8 /
{code}

The readability improves, but is still not the correct character encoding.  Not 
sure what the encoding is supposed to be, or if the tool is introducing another 
layer of mangling.

The API docs really help, but having to sort through visual noise doesn't help.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (LOG4J2-946) [docs] Using Log4j 2 in Web Applications: Update example (Log4jWebLifeCycle is not visible)

[Gary Gregory (JIRA)]

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

Gary Gregory resolved LOG4J2-946.
-
   Resolution: Fixed
Fix Version/s: 2.2

Fixed docs in git master. Please verify that the new example works for you.

 [docs] Using Log4j 2 in Web Applications: Update example (Log4jWebLifeCycle 
 is not visible)
 ---

 Key: LOG4J2-946
 URL: https://issues.apache.org/jira/browse/LOG4J2-946
 Project: Log4j 2
  Issue Type: Bug
  Components: Documentation
Affects Versions: 2.0.2
Reporter: artemonster
 Fix For: 2.2


 On the http://logging.apache.org/log4j/2.x/manual/webapp.html page you 
 mention following code snippet:
 {code}
 final Log4jWebLifeCycle webLifeCycle = 
 WebLoggerContextUtils.getWebLifeCycle(TestAsyncServlet.this.getServletContext());
 {code}
 The problem is, Log4jWebLifeCycle is package-private and you can't use it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LOG4J2-946) [docs] Log4jWebLifeCycle is not visible

[Gary Gregory (JIRA)]

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

Gary Gregory updated LOG4J2-946:

Summary: [docs] Log4jWebLifeCycle is not visible  (was: Log4jWebLifeCycle 
is not visible)

 [docs] Log4jWebLifeCycle is not visible
 ---

 Key: LOG4J2-946
 URL: https://issues.apache.org/jira/browse/LOG4J2-946
 Project: Log4j 2
  Issue Type: Bug
  Components: Documentation
Affects Versions: 2.0.2
Reporter: artemonster

 On the http://logging.apache.org/log4j/2.x/manual/webapp.html page you 
 mention following code snippet:
 {code}
 final Log4jWebLifeCycle webLifeCycle = 
 WebLoggerContextUtils.getWebLifeCycle(TestAsyncServlet.this.getServletContext());
 {code}
 The problem is, Log4jWebLifeCycle is package-private and you can't use it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (LOG4J2-946) [docs] Using Log4j 2 in Web Applications: Update example (Log4jWebLifeCycle is not visible)

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14297066#comment-14297066
 ] 

Gary Gregory edited comment on LOG4J2-946 at 1/29/15 4:24 PM:
--

The docs are wrong, it was not updated to the latest version of 
{{org.apache.logging.log4j.web.TestAsyncServlet}} (see git).

Just change {{Log4jWebLifeCycle}} to {{Log4jWebSupport}}:

{code:java}
 final Log4jWebSupport webLifeCycle = 
WebLoggerContextUtils.getWebLifeCycle(TestAsyncServlet.this.getServletContext());
{code}

Gary


was (Author: garydgregory):
The docs are wrong, it was not updated to the latest version of 
{{org.apache.logging.log4j.web.TestAsyncServlet}} (see git).

Just change {{Log4jWebLifeCycle}} to {{Log4jWebSupport}}:

{code:java}
 final Log4jWebSupport webLifeCycle = 
WebLoggerContextUtils.getWebLifeCycle(TestAsyncServlet.this.getServletContext());
{code}

Gary

 [docs] Using Log4j 2 in Web Applications: Update example (Log4jWebLifeCycle 
 is not visible)
 ---

 Key: LOG4J2-946
 URL: https://issues.apache.org/jira/browse/LOG4J2-946
 Project: Log4j 2
  Issue Type: Bug
  Components: Documentation
Affects Versions: 2.0.2
Reporter: artemonster
 Fix For: 2.2


 On the http://logging.apache.org/log4j/2.x/manual/webapp.html page you 
 mention following code snippet:
 {code}
 final Log4jWebLifeCycle webLifeCycle = 
 WebLoggerContextUtils.getWebLifeCycle(TestAsyncServlet.this.getServletContext());
 {code}
 The problem is, Log4jWebLifeCycle is package-private and you can't use it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LOG4J2-946) [docs] Using Log4j 2 in Web Applications: Update example (Log4jWebLifeCycle is not visible)

[Gary Gregory (JIRA)]

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

Gary Gregory updated LOG4J2-946:

Summary: [docs] Using Log4j 2 in Web Applications: Update example 
(Log4jWebLifeCycle is not visible)  (was: [docs] Log4jWebLifeCycle is not 
visible)

 [docs] Using Log4j 2 in Web Applications: Update example (Log4jWebLifeCycle 
 is not visible)
 ---

 Key: LOG4J2-946
 URL: https://issues.apache.org/jira/browse/LOG4J2-946
 Project: Log4j 2
  Issue Type: Bug
  Components: Documentation
Affects Versions: 2.0.2
Reporter: artemonster

 On the http://logging.apache.org/log4j/2.x/manual/webapp.html page you 
 mention following code snippet:
 {code}
 final Log4jWebLifeCycle webLifeCycle = 
 WebLoggerContextUtils.getWebLifeCycle(TestAsyncServlet.this.getServletContext());
 {code}
 The problem is, Log4jWebLifeCycle is package-private and you can't use it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LOG4J2-901) Update docs for SyslogAppender: No structured id name was supplied

[Gary Gregory (JIRA)]

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

Gary Gregory updated LOG4J2-901:

Summary: Update docs for SyslogAppender: No structured id name was 
supplied  (was: SyslogAppender not working - No structured id name was 
supplied)

 Update docs for SyslogAppender: No structured id name was supplied
 

 Key: LOG4J2-901
 URL: https://issues.apache.org/jira/browse/LOG4J2-901
 Project: Log4j 2
  Issue Type: Bug
  Components: Appenders
Affects Versions: 2.1
 Environment: Linux
Reporter: Tihomir Meščić

 I'm using Log4j version 2.1 and trying to use a Syslog appender to log to a 
 syslog server (rsyslog). I'm using the configuration given at the official 
 site 
 (http://logging.apache.org/log4j/2.x/manual/appenders.html#SyslogAppender):
 {noformat}
 Syslog name=RFC5424 format=RFC5424 host=localhost port=514
 protocol=UDP appName=MyApp includeMDC=true
 facility=LOCAL0 enterpriseNumber=18060 newLine=true
 messageId=Audit id=App/
 {noformat}
 When I start my app and do a LogManager.getLogger(), I get an error:
 {noformat}
 014-11-17 18:26:23,640 ERROR Unable to invoke factory method in class class 
 org.apache.logging.log4j.core.appender.SyslogAppender for element Syslog. 
 java.lang.reflect.InvocationTargetException
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:606)
   at 
 org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:135)
   at 
 org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:766)
   at 
 org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:706)
   at 
 org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:698)
   at 
 org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:358)
   at 
 org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:161)
   at 
 org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:359)
   at 
 org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:420)
   at org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:138)
   at 
 org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:147)
   at 
 org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:41)
   at org.apache.logging.log4j.LogManager.getContext(LogManager.java:175)
   at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:426)
   at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:408)
   at Log.clinit(Log.java:7)
 Caused by: java.lang.IllegalArgumentException: No structured id name was 
 supplied
   at 
 org.apache.logging.log4j.message.StructuredDataId.init(StructuredDataId.java:92)
   at 
 org.apache.logging.log4j.core.layout.Rfc5424Layout.init(Rfc5424Layout.java:139)
   at 
 org.apache.logging.log4j.core.layout.Rfc5424Layout.createLayout(Rfc5424Layout.java:657)
   at 
 org.apache.logging.log4j.core.appender.SyslogAppender.createAppender(SyslogAppender.java:133)
 ... 19 more
 {noformat}
 The same thing works on an older version of log4j 2.0-beta9.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (LOG4J2-901) Update docs for SyslogAppender: No structured id name was supplied

[Gary Gregory (JIRA)]

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

Gary Gregory resolved LOG4J2-901.
-
   Resolution: Fixed
Fix Version/s: 2.2

Docs updated. Site needs to be regenerated.

 Update docs for SyslogAppender: No structured id name was supplied
 

 Key: LOG4J2-901
 URL: https://issues.apache.org/jira/browse/LOG4J2-901
 Project: Log4j 2
  Issue Type: Bug
  Components: Appenders
Affects Versions: 2.1
 Environment: Linux
Reporter: Tihomir Meščić
 Fix For: 2.2


 I'm using Log4j version 2.1 and trying to use a Syslog appender to log to a 
 syslog server (rsyslog). I'm using the configuration given at the official 
 site 
 (http://logging.apache.org/log4j/2.x/manual/appenders.html#SyslogAppender):
 {noformat}
 Syslog name=RFC5424 format=RFC5424 host=localhost port=514
 protocol=UDP appName=MyApp includeMDC=true
 facility=LOCAL0 enterpriseNumber=18060 newLine=true
 messageId=Audit id=App/
 {noformat}
 When I start my app and do a LogManager.getLogger(), I get an error:
 {noformat}
 014-11-17 18:26:23,640 ERROR Unable to invoke factory method in class class 
 org.apache.logging.log4j.core.appender.SyslogAppender for element Syslog. 
 java.lang.reflect.InvocationTargetException
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:606)
   at 
 org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:135)
   at 
 org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:766)
   at 
 org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:706)
   at 
 org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:698)
   at 
 org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:358)
   at 
 org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:161)
   at 
 org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:359)
   at 
 org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:420)
   at org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:138)
   at 
 org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:147)
   at 
 org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:41)
   at org.apache.logging.log4j.LogManager.getContext(LogManager.java:175)
   at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:426)
   at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:408)
   at Log.clinit(Log.java:7)
 Caused by: java.lang.IllegalArgumentException: No structured id name was 
 supplied
   at 
 org.apache.logging.log4j.message.StructuredDataId.init(StructuredDataId.java:92)
   at 
 org.apache.logging.log4j.core.layout.Rfc5424Layout.init(Rfc5424Layout.java:139)
   at 
 org.apache.logging.log4j.core.layout.Rfc5424Layout.createLayout(Rfc5424Layout.java:657)
   at 
 org.apache.logging.log4j.core.appender.SyslogAppender.createAppender(SyslogAppender.java:133)
 ... 19 more
 {noformat}
 The same thing works on an older version of log4j 2.0-beta9.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

GELF site docs

[Gary Gregory]

FYI: I updated the site in master for GELF.

Gary

-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
http://www.manning.com/bauer3/
JUnit in Action, Second Edition http://www.manning.com/tahchiev/
Spring Batch in Action http://www.manning.com/templier/
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Docs and Subversion

[Gary Gregory]

Here us one:

https://logging.apache.org/log4j/2.x/build.html

Hm... but maybe that is fixed in the repo but it should also be fixed in the 
branch and published...


Gary

div Original message /divdivFrom: Remko Popma 
remko.po...@gmail.com /divdivDate:09/20/2014  21:56  (GMT-05:00) 
/divdivTo: Log4J Developers List log4j-dev@logging.apache.org 
/divdivSubject: Re: Docs and Subversion /divdiv
/divWhich doc pages?

Sent from my iPhone

On 2014/09/19, at 20:11, Gary Gregory garydgreg...@gmail.com wrote:

Just a TODO here that the wiki and some doc pages still refer to Subversion.

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: Docs and Subversion

[Remko Popma]

Which doc pages?

Sent from my iPhone

 On 2014/09/19, at 20:11, Gary Gregory garydgreg...@gmail.com wrote:
 
 Just a TODO here that the wiki and some doc pages still refer to Subversion.
 
 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

Docs and Subversion

[Gary Gregory]

Just a TODO here that the wiki and some doc pages still refer to Subversion.

Gary

-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
http://www.manning.com/bauer3/
JUnit in Action, Second Edition http://www.manning.com/tahchiev/
Spring Batch in Action http://www.manning.com/templier/
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Docs changelog entry for IO Streams module

[Matt Sicker]

Thanks for the JIRA ticket. Closed the issue and added it to the changelog
(not in that order).

On 16 September 2014 18:08, Remko Popma remko.po...@gmail.com wrote:

 I see, thanks! Perhaps the changelog entry could point to LOG4J2-547
 https://issues.apache.org/jira/browse/LOG4J2-547.
 (481 was already included in RC1.)

 On Wed, Sep 17, 2014 at 2:00 AM, Ralph Goers ralph.go...@dslextreme.com
 wrote:

 LOG4J2-481  LOG4J2-547

 On Sep 16, 2014, at 9:50 AM, Remko Popma remko.po...@gmail.com wrote:

 I did a few searches but couldn't find anything for streams or iostreams
 so I gave up...


 On Wednesday, September 17, 2014, Ralph Goers ralph.go...@dslextreme.com
 wrote:

 I thought there was at least 1 Jira related to this that spawned the
 whole adventure.

 Ralph

 On Sep 16, 2014, at 9:42 AM, Remko Popma remko.po...@gmail.com wrote:

  Looks like the IO Streams module does not have any docs yet.
  I added a link to the left-hand side nav menu, but there is nothing to
 link to...
 
  Also we need an entry in changes.xml so this feature gets mentioned in
 the release notes. Should we create a Jira that explains the motivation for
 this feature?
 
  Remko


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






-- 
Matt Sicker boa...@gmail.com

Re: [1/4] git commit: Update JUL bridge docs.

[Remko Popma]

Thanks!

I just realized that if a JUL custom level is used without specifying a 
LevelConverter, it's actually not a problem: the Logger's level will be null 
and it will just use the log level of its parent (that's a fairly recent 
change, I think)!

Is it worth mentioning that in the docs?

Sent from my iPhone

 On 2014/09/19, at 7:47, mattsic...@apache.org wrote:
 
 Repository: logging-log4j2
 Updated Branches:
  refs/heads/master b1783a0aa - c8406750d
 
 
 Update JUL bridge docs.
 
 
 Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
 Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/2a06bf1b
 Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/2a06bf1b
 Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/2a06bf1b
 
 Branch: refs/heads/master
 Commit: 2a06bf1b4f6456f3322d923e2e36e38e15a20f12
 Parents: b1783a0
 Author: Matt Sicker mattsic...@apache.org
 Authored: Thu Sep 18 17:33:29 2014 -0500
 Committer: Matt Sicker mattsic...@apache.org
 Committed: Thu Sep 18 17:33:29 2014 -0500
 
 --
 log4j-jul/src/site/xdoc/index.xml | 65 ++
 1 file changed, 10 insertions(+), 55 deletions(-)
 --
 
 
 http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/2a06bf1b/log4j-jul/src/site/xdoc/index.xml
 --
 diff --git a/log4j-jul/src/site/xdoc/index.xml 
 b/log4j-jul/src/site/xdoc/index.xml
 index 5429092..216dceb 100644
 --- a/log4j-jul/src/site/xdoc/index.xml
 +++ b/log4j-jul/src/site/xdoc/index.xml
 @@ -34,7 +34,7 @@
 /section
 section name=Requirements
   p
 -The JDK Logging Adaptor requires at least Java 6 and is dependent on 
 the Log4j API and Log4j Core.
 +The JDK Logging Adaptor requires at least Java 6 and is dependent on 
 the Log4j API and optionally Log4j Core.
   /p
 /section
 section name=Usage
 @@ -66,103 +66,58 @@
   /p
   p
 Java logging levels are translated into Log4j logging levels 
 dynamically. The following table lists the
 -conversions between a Java logging level and its equivalent Log4j 
 level.
 +conversions between a Java logging level and its equivalent Log4j 
 level. Custom levels should be implemented
 +as an implementation of
 +a class=javadoc 
 href=apidocs/org/apache/logging/log4j/jul/LevelConverter.htmlLevelConverter/a,
  and the
 +Log4j property kbdlog4j.jul.levelConverter/kbd must be set to 
 your custom class name.
   /p
   table
 -captionLevel conversions/caption
 +captionDefault Level conversions/caption
 thead
   tr
 thJava Level/th
 -thLevel Range/th
 thLog4j Level/th
   /tr
 /thead
 tbody
   tr
 tda class=javadoc 
 href=http://docs.oracle.com/javase/6/docs/api/java/util/logging/Level.html#OFF;OFF/a/td
 -tda class=javadoc 
 href=http://docs.oracle.com/javase/6/docs/api/java/lang/Integer.html#MAX_VALUE;Integer.MAX_VALUE/a/td
 tdOFF/td
   /tr
   tr
 -td class=mutedn/a/td
 -td1000 lt; varlevel/var lt; a class=javadoc 
 href=http://docs.oracle.com/javase/6/docs/api/java/lang/Integer.html#MAX_VALUE;Integer.MAX_VALUE/a/td
 -tdFATAL/td
 -  /tr
 -  tr
 tda class=javadoc 
 href=http://docs.oracle.com/javase/6/docs/api/java/util/logging/Level.html#SEVERE;SEVERE/a/td
 -td900 lt; varlevel/var le; 1000/td
 tdERROR/td
   /tr
   tr
 tda class=javadoc 
 href=http://docs.oracle.com/javase/6/docs/api/java/util/logging/Level.html#WARNING;WARNING/a/td
 -td800 lt; varlevel/var le; 900/td
 tdWARN/td
   /tr
   tr
 tda class=javadoc 
 href=http://docs.oracle.com/javase/6/docs/api/java/util/logging/Level.html#INFO;INFO/a/td
 -td700 lt; varlevel/var le; 800/td
 tdINFO/td
   /tr
   tr
 tda class=javadoc 
 href=http://docs.oracle.com/javase/6/docs/api/java/util/logging/Level.html#CONFIG;CONFIG/a/td
 -td500 lt; varlevel/var le; 700/td
 -tdINFO/td
 +tda class=javadoc 
 href=apidocs/org/apache/logging/log4j/jul/LevelTranslator.html#CONFIGCONFIG/a/td
   /tr
   tr
 tda class=javadoc 
 href=http://docs.oracle.com/javase/6/docs/api/java/util/logging/Level.html#FINE;FINE/a/td
 -td400 lt; varlevel/var le; 500/td
 tdDEBUG/td
   /tr
   tr
 tda class=javadoc 
 href=http://docs.oracle.com/javase/6/docs/api/java/util/logging/Level.html#FINER;FINER/a/td
 -td300 lt; varlevel/var le; 400/td
 -tdDEBUG/td

Re: [1/4] git commit: Update JUL bridge docs.

[Matt Sicker]

Good catch. I'll push an update in a sec.

On 18 September 2014 18:50, Remko Popma remko.po...@gmail.com wrote:

 Thanks!

 I just realized that if a JUL custom level is used without specifying a
 LevelConverter, it's actually not a problem: the Logger's level will be
 null and it will just use the log level of its parent (that's a fairly
 recent change, I think)!

 Is it worth mentioning that in the docs?

 Sent from my iPhone

  On 2014/09/19, at 7:47, mattsic...@apache.org wrote:
 
  Repository: logging-log4j2
  Updated Branches:
   refs/heads/master b1783a0aa - c8406750d
 
 
  Update JUL bridge docs.
 
 
  Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
  Commit:
 http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/2a06bf1b
  Tree:
 http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/2a06bf1b
  Diff:
 http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/2a06bf1b
 
  Branch: refs/heads/master
  Commit: 2a06bf1b4f6456f3322d923e2e36e38e15a20f12
  Parents: b1783a0
  Author: Matt Sicker mattsic...@apache.org
  Authored: Thu Sep 18 17:33:29 2014 -0500
  Committer: Matt Sicker mattsic...@apache.org
  Committed: Thu Sep 18 17:33:29 2014 -0500
 
  --
  log4j-jul/src/site/xdoc/index.xml | 65 ++
  1 file changed, 10 insertions(+), 55 deletions(-)
  --
 
 
 
 http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/2a06bf1b/log4j-jul/src/site/xdoc/index.xml
  --
  diff --git a/log4j-jul/src/site/xdoc/index.xml
 b/log4j-jul/src/site/xdoc/index.xml
  index 5429092..216dceb 100644
  --- a/log4j-jul/src/site/xdoc/index.xml
  +++ b/log4j-jul/src/site/xdoc/index.xml
  @@ -34,7 +34,7 @@
  /section
  section name=Requirements
p
  -The JDK Logging Adaptor requires at least Java 6 and is
 dependent on the Log4j API and Log4j Core.
  +The JDK Logging Adaptor requires at least Java 6 and is
 dependent on the Log4j API and optionally Log4j Core.
/p
  /section
  section name=Usage
  @@ -66,103 +66,58 @@
/p
p
  Java logging levels are translated into Log4j logging levels
 dynamically. The following table lists the
  -conversions between a Java logging level and its equivalent
 Log4j level.
  +conversions between a Java logging level and its equivalent
 Log4j level. Custom levels should be implemented
  +as an implementation of
  +a class=javadoc
 href=apidocs/org/apache/logging/log4j/jul/LevelConverter.htmlLevelConverter/a,
 and the
  +Log4j property kbdlog4j.jul.levelConverter/kbd must be set
 to your custom class name.
/p
table
  -captionLevel conversions/caption
  +captionDefault Level conversions/caption
  thead
tr
  thJava Level/th
  -thLevel Range/th
  thLog4j Level/th
/tr
  /thead
  tbody
tr
  tda class=javadoc href=
 http://docs.oracle.com/javase/6/docs/api/java/util/logging/Level.html#OFF
 OFF/a/td
  -tda class=javadoc href=
 http://docs.oracle.com/javase/6/docs/api/java/lang/Integer.html#MAX_VALUE
 Integer.MAX_VALUE/a/td
  tdOFF/td
/tr
tr
  -td class=mutedn/a/td
  -td1000 lt; varlevel/var lt; a class=javadoc
 href=
 http://docs.oracle.com/javase/6/docs/api/java/lang/Integer.html#MAX_VALUE
 Integer.MAX_VALUE/a/td
  -tdFATAL/td
  -  /tr
  -  tr
  tda class=javadoc href=
 http://docs.oracle.com/javase/6/docs/api/java/util/logging/Level.html#SEVERE
 SEVERE/a/td
  -td900 lt; varlevel/var le; 1000/td
  tdERROR/td
/tr
tr
  tda class=javadoc href=
 http://docs.oracle.com/javase/6/docs/api/java/util/logging/Level.html#WARNING
 WARNING/a/td
  -td800 lt; varlevel/var le; 900/td
  tdWARN/td
/tr
tr
  tda class=javadoc href=
 http://docs.oracle.com/javase/6/docs/api/java/util/logging/Level.html#INFO
 INFO/a/td
  -td700 lt; varlevel/var le; 800/td
  tdINFO/td
/tr
tr
  tda class=javadoc href=
 http://docs.oracle.com/javase/6/docs/api/java/util/logging/Level.html#CONFIG
 CONFIG/a/td
  -td500 lt; varlevel/var le; 700/td
  -tdINFO/td
  +tda class=javadoc
 href=apidocs/org/apache/logging/log4j/jul/LevelTranslator.html#CONFIGCONFIG/a/td
/tr
tr
  tda class=javadoc href=
 http://docs.oracle.com/javase/6/docs/api/java/util/logging/Level.html#FINE
 FINE/a/td
  -td400 lt; varlevel/var le; 500/td
  tdDEBUG/td
/tr
tr

Docs changelog entry for IO Streams module

[Remko Popma]

Looks like the IO Streams module does not have any docs yet.
I added a link to the left-hand side nav menu, but there is nothing to link
to...

Also we need an entry in changes.xml so this feature gets mentioned in the
release notes. Should we create a Jira that explains the motivation for
this feature?

Remko

Re: Docs changelog entry for IO Streams module

[Ralph Goers]

I thought there was at least 1 Jira related to this that spawned the whole 
adventure.

Ralph

On Sep 16, 2014, at 9:42 AM, Remko Popma remko.po...@gmail.com wrote:

 Looks like the IO Streams module does not have any docs yet.
 I added a link to the left-hand side nav menu, but there is nothing to link 
 to...
 
 Also we need an entry in changes.xml so this feature gets mentioned in the 
 release notes. Should we create a Jira that explains the motivation for this 
 feature?
 
 Remko


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

Re: Docs changelog entry for IO Streams module

[Remko Popma]

I did a few searches but couldn't find anything for streams or iostreams so
I gave up...


On Wednesday, September 17, 2014, Ralph Goers ralph.go...@dslextreme.com
wrote:

 I thought there was at least 1 Jira related to this that spawned the whole
 adventure.

 Ralph

 On Sep 16, 2014, at 9:42 AM, Remko Popma remko.po...@gmail.com
 javascript:; wrote:

  Looks like the IO Streams module does not have any docs yet.
  I added a link to the left-hand side nav menu, but there is nothing to
 link to...
 
  Also we need an entry in changes.xml so this feature gets mentioned in
 the release notes. Should we create a Jira that explains the motivation for
 this feature?
 
  Remko


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

Re: Docs changelog entry for IO Streams module

[Ralph Goers]

LOG4J2-481  LOG4J2-547

On Sep 16, 2014, at 9:50 AM, Remko Popma remko.po...@gmail.com wrote:

 I did a few searches but couldn't find anything for streams or iostreams so I 
 gave up...
 
 
 On Wednesday, September 17, 2014, Ralph Goers ralph.go...@dslextreme.com 
 wrote:
 I thought there was at least 1 Jira related to this that spawned the whole 
 adventure.
 
 Ralph
 
 On Sep 16, 2014, at 9:42 AM, Remko Popma remko.po...@gmail.com wrote:
 
  Looks like the IO Streams module does not have any docs yet.
  I added a link to the left-hand side nav menu, but there is nothing to link 
  to...
 
  Also we need an entry in changes.xml so this feature gets mentioned in the 
  release notes. Should we create a Jira that explains the motivation for 
  this feature?
 
  Remko
 
 
 -
 To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
 For additional commands, e-mail: log4j-dev-h...@logging.apache.org
 

Re: Docs changelog entry for IO Streams module

[Remko Popma]

I see, thanks! Perhaps the changelog entry could point to LOG4J2-547
https://issues.apache.org/jira/browse/LOG4J2-547.
(481 was already included in RC1.)

On Wed, Sep 17, 2014 at 2:00 AM, Ralph Goers ralph.go...@dslextreme.com
wrote:

 LOG4J2-481  LOG4J2-547

 On Sep 16, 2014, at 9:50 AM, Remko Popma remko.po...@gmail.com wrote:

 I did a few searches but couldn't find anything for streams or iostreams
 so I gave up...


 On Wednesday, September 17, 2014, Ralph Goers ralph.go...@dslextreme.com
 wrote:

 I thought there was at least 1 Jira related to this that spawned the
 whole adventure.

 Ralph

 On Sep 16, 2014, at 9:42 AM, Remko Popma remko.po...@gmail.com wrote:

  Looks like the IO Streams module does not have any docs yet.
  I added a link to the left-hand side nav menu, but there is nothing to
 link to...
 
  Also we need an entry in changes.xml so this feature gets mentioned in
 the release notes. Should we create a Jira that explains the motivation for
 this feature?
 
  Remko


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

[jira] [Created] (LOG4J2-740) Invalid servlet configuration in docs

[Kosta Krauth (JIRA)]

Kosta Krauth created LOG4J2-740:
---

 Summary: Invalid servlet configuration in docs
 Key: LOG4J2-740
 URL: https://issues.apache.org/jira/browse/LOG4J2-740
 Project: Log4j 2
  Issue Type: Documentation
  Components: Documentation
Affects Versions: 2.0
Reporter: Kosta Krauth
Priority: Minor


http://logging.apache.org/log4j/2.x/manual/webapp.html#Servlet-2.5

The packages for the web classes have changed and no longer contain .core. as 
specified in the docs:

listener-classorg.apache.logging.log4j.core.web.Log4jServletContextListener/listener-class

filter-classorg.apache.logging.log4j.core.web.Log4jServletFilter/filter-class

should be changed to:

listener-classorg.apache.logging.log4j.web.Log4jServletContextListener/listener-class

filter-classorg.apache.logging.log4j.web.Log4jServletFilter/filter-class



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Resolved] (LOG4J2-740) Invalid servlet configuration in docs

[Matt Sicker (JIRA)]

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

Matt Sicker resolved LOG4J2-740.


   Resolution: Fixed
Fix Version/s: 2.0.1
 Assignee: Matt Sicker

Fixed in trunk, revision 1613337. Please verify and close.

 Invalid servlet configuration in docs
 -

 Key: LOG4J2-740
 URL: https://issues.apache.org/jira/browse/LOG4J2-740
 Project: Log4j 2
  Issue Type: Documentation
  Components: Documentation
Affects Versions: 2.0
Reporter: Kosta Krauth
Assignee: Matt Sicker
Priority: Minor
 Fix For: 2.0.1


 http://logging.apache.org/log4j/2.x/manual/webapp.html#Servlet-2.5
 The packages for the web classes have changed and no longer contain .core. as 
 specified in the docs:
 listener-classorg.apache.logging.log4j.core.web.Log4jServletContextListener/listener-class
 filter-classorg.apache.logging.log4j.core.web.Log4jServletFilter/filter-class
 should be changed to:
 listener-classorg.apache.logging.log4j.web.Log4jServletContextListener/listener-class
 filter-classorg.apache.logging.log4j.web.Log4jServletFilter/filter-class



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Updated] (LOG4J2-631) Update docs to clarify how to use formatter logger and standard logger together

[Remko Popma (JIRA)]

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

Remko Popma updated LOG4J2-631:
---

  Component/s: Documentation
Fix Version/s: 2.0
 Assignee: Remko Popma
  Summary: Update docs to clarify how to use formatter logger and 
standard logger together  (was: Cannot use formatter logger and standard logger 
with same name)

Changed title to reflect the remaining task.

 Update docs to clarify how to use formatter logger and standard logger 
 together
 ---

 Key: LOG4J2-631
 URL: https://issues.apache.org/jira/browse/LOG4J2-631
 Project: Log4j 2
  Issue Type: Bug
  Components: Documentation
Affects Versions: 2.0-rc1
Reporter: Alexandre Gattiker
Assignee: Remko Popma
 Fix For: 2.0


 {code}
 public class Example {
   private final static Logger FORMATTER_LOGGER = 
 LogManager.getFormatterLogger(Example.class);
   private final static Logger LOGGER = 
 LogManager.getLogger(Example.class);
   public static void main(String[] args) {
   LOGGER.log(ERROR, {} happened, Something);
   FORMATTER_LOGGER.log(ERROR, %s happened, Something);
   }
 }
 {code}
 {noformat}
 13:40:35.401 [main] ERROR com.example.Example - {} happened
 13:40:35.404 [main] ERROR com.example.Example - Something happened
 {noformat}
 After inverting the two constant declarations:
 {noformat}
 13:41:13.730 [main] ERROR com.example.Example - Something happened
 13:41:13.732 [main] ERROR com.example.Example - %s happened
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Resolved] (LOG4J2-631) Update docs to clarify how to use formatter logger and standard logger together

[Remko Popma (JIRA)]

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

Remko Popma resolved LOG4J2-631.


Resolution: Fixed

Fixed in revision 1609755.
Please verify and close.

 Update docs to clarify how to use formatter logger and standard logger 
 together
 ---

 Key: LOG4J2-631
 URL: https://issues.apache.org/jira/browse/LOG4J2-631
 Project: Log4j 2
  Issue Type: Bug
  Components: Documentation
Affects Versions: 2.0-rc1
Reporter: Alexandre Gattiker
Assignee: Remko Popma
 Fix For: 2.0


 {code}
 public class Example {
   private final static Logger FORMATTER_LOGGER = 
 LogManager.getFormatterLogger(Example.class);
   private final static Logger LOGGER = 
 LogManager.getLogger(Example.class);
   public static void main(String[] args) {
   LOGGER.log(ERROR, {} happened, Something);
   FORMATTER_LOGGER.log(ERROR, %s happened, Something);
   }
 }
 {code}
 {noformat}
 13:40:35.401 [main] ERROR com.example.Example - {} happened
 13:40:35.404 [main] ERROR com.example.Example - Something happened
 {noformat}
 After inverting the two constant declarations:
 {noformat}
 13:41:13.730 [main] ERROR com.example.Example - Something happened
 13:41:13.732 [main] ERROR com.example.Example - %s happened
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

JMX and docs

[Gary Gregory]

Hi all:

Reading https://issues.apache.org/jira/browse/LOG4J2-423 I wonder how
to best document JMX. Should each feature (like each appenders) (1)
document what it exposes through JMX, or, (2) should the JMX section
list all that is exposed. I'm thinking (1).

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

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

Re: JMX and docs

[Remko Popma]

What kind of docs do you have in mind?

The JMX API is documented in detail here:
http://logging.apache.org/log4j/2.x/log4j-core/apidocs/org/apache/logging/log4j/core/jmx/package-summary.html

In addition to API, the JMX section has pointers for connectivity, and of
course docs for the GUI.

To be honest, there is actually not that much that users can do via the JMX
interface, at least at the moment. The interesting stuff (looking at the
StatusLogger output, and reconfiguring log4j from a file or from an XML
string) is covered in the JMX GUI docs.


On Wednesday, October 16, 2013, Gary Gregory wrote:

 Hi all:

 Reading https://issues.apache.org/jira/browse/LOG4J2-423 I wonder how
 to best document JMX. Should each feature (like each appenders) (1)
 document what it exposes through JMX, or, (2) should the JMX section
 list all that is exposed. I'm thinking (1).

 Gary

 --
 E-Mail: garydgreg...@gmail.com javascript:; | 
 ggreg...@apache.orgjavascript:;
 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

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

Re: JMX and docs

[Gary Gregory]

On Wed, Oct 16, 2013 at 9:44 AM, Remko Popma remko.po...@gmail.com wrote:

 What kind of docs do you have in mind?


Well, I suppose we have it covered by this blanket statement: Appenders
are instrumented with MBeans and can be remotely monitored and controlled.

I was just wondering if it would be useful to describe what, in more
detailed, is monitored for each appender. But it sounds like actually using
JMX will just tell you that. So, never mind ;)

Gary


 The JMX API is documented in detail here:

 http://logging.apache.org/log4j/2.x/log4j-core/apidocs/org/apache/logging/log4j/core/jmx/package-summary.html

 In addition to API, the JMX section has pointers for connectivity, and of
 course docs for the GUI.

 To be honest, there is actually not that much that users can do via the
 JMX interface, at least at the moment. The interesting stuff (looking at
 the StatusLogger output, and reconfiguring log4j from a file or from an XML
 string) is covered in the JMX GUI docs.


 On Wednesday, October 16, 2013, Gary Gregory wrote:

 Hi all:

 Reading https://issues.apache.org/jira/browse/LOG4J2-423 I wonder how
 to best document JMX. Should each feature (like each appenders) (1)
 document what it exposes through JMX, or, (2) should the JMX section
 list all that is exposed. I'm thinking (1).

 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

 -
 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 Editionhttp://www.manning.com/bauer3/
JUnit in Action, Second Edition http://www.manning.com/tahchiev/
Spring Batch in Action http://www.manning.com/templier/
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: JMX and docs

[Remko Popma]

On Wednesday, October 16, 2013, Gary Gregory wrote:

 On Wed, Oct 16, 2013 at 9:44 AM, Remko Popma 
 remko.po...@gmail.comjavascript:_e({}, 'cvml', 'remko.po...@gmail.com');
  wrote:

 What kind of docs do you have in mind?


 Well, I suppose we have it covered by this blanket statement: Appenders
 are instrumented with MBeans and can be remotely monitored and controlled.

 I was just wondering if it would be useful to describe what, in more
 detailed, is monitored for each appender. But it sounds like actually using
 JMX will just tell you that.


That was my thinking exactly!


 So, never mind ;)

Cool!


 Gary


 The JMX API is documented in detail here:

 http://logging.apache.org/log4j/2.x/log4j-core/apidocs/org/apache/logging/log4j/core/jmx/package-summary.html

 In addition to API, the JMX section has pointers for connectivity, and of
 course docs for the GUI.

 To be honest, there is actually not that much that users can do via the
 JMX interface, at least at the moment. The interesting stuff (looking at
 the StatusLogger output, and reconfiguring log4j from a file or from an XML
 string) is covered in the JMX GUI docs.


 On Wednesday, October 16, 2013, Gary Gregory wrote:

 Hi all:

 Reading https://issues.apache.org/jira/browse/LOG4J2-423 I wonder how
 to best document JMX. Should each feature (like each appenders) (1)
 document what it exposes through JMX, or, (2) should the JMX section
 list all that is exposed. I'm thinking (1).

 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

 -
 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 javascript:_e({}, 'cvml',
 'garydgreg...@gmail.com'); | ggreg...@apache.org javascript:_e({},
 'cvml', 'ggreg...@apache.org');
 Java Persistence with Hibernate, Second 
 Editionhttp://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory

Re: docs

[chand priyankara]

Please refer to below URL for the moment.

https://svn.apache.org/repos/asf/logging/site/trunk/docs/log4cxx/apidocs/index.html


regards,


*Chand Priyankara*  [image: Facebook]http://www.facebook.com/chand.priyankara
 [image: LinkedIn] http://lk.linkedin.com/in/chandpriyankara [image:
Blogger] http://chandpriyankara.blogspot.com/ [image: Google
Plus]http://plus.google.com/104246340732624023499

|BSc(Eng) - Electrical  Information
|(094) 773-361-566
|ch...@engineering.com
|http://chandpriyankara.blogspot.com
http://www.iucnredlist.org/amazing-speciessent via internet


On Mon, Sep 9, 2013 at 9:03 PM, Littlefield, Tyler ty...@tysdomain.comwrote:

 Hello:
 I clicked on the log4cxx apidocs link as well as the manual link on the
 log4cxx wiki and kepe getting 404 errors. Is log4cxx still being
 used/developed? Any idea where the docs might be? I am evaluating logging
 libraries and this is my third this morning. Glog has almost no docs to
 speak of, boost::logging is well, boost and log4cxx seems to have misplaced
 it's documentation.

 --
 Take care,
 Ty
 http://tds-solutions.net
 He that will not reason is a bigot; he that cannot reason is a fool; he
 that dares not reason is a slave.

Re: small patch: Fix install location for docs

[Alexandru Zbârcea]

Sorry for posting a patch on users@. I created a Jira Issue [1] and
attached the patch.

Thx,
Alex

[1] https://issues.apache.org/jira/browse/LOGCXX-414

On Wed, Jun 26, 2013 at 6:02 PM, Alexandru Zbârcea zbarce...@gmail.comwrote:

 Hi,

 As stated by: http://www.gnu.org/software/automake/manual/automake.html

 Documentation files should go to *docdir* and not to *pkgdatadir*.

 Hope it helps,
 Alex

small patch: Fix install location for docs

[Alexandru Zbârcea]

Hi,

As stated by: http://www.gnu.org/software/automake/manual/automake.html

Documentation files should go to *docdir* and not to *pkgdatadir*.

Hope it helps,
Alex


fix-install-location-for-docs.patch
Description: Binary data

[jira] [Commented] (LOG4J2-73) docs: download site and how to use RolloverStrategy.

[Tushar (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13672087#comment-13672087
 ] 

Tushar commented on LOG4J2-73:
--

thank you

 docs: download site and how to use  RolloverStrategy.
 -

 Key: LOG4J2-73
 URL: https://issues.apache.org/jira/browse/LOG4J2-73
 Project: Log4j 2
  Issue Type: Improvement
  Components: Documentation
Affects Versions: 2.0-alpha2
 Environment: all
Reporter: Tushar
Priority: Minor
 Fix For: 2.0-beta1


 can you show a sample in 
 http://logging.apache.org/log4j/2.x/manual/appenders.html#RolloverStrategies 
 on how to use RolloverStrategy tag?
 also be a good idea to give us a command or better a zip/ gz of the doc files 
 so we can store them locally

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Closed] (LOG4J2-73) docs: download site and how to use RolloverStrategy.

[Tushar (JIRA)]

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

Tushar closed LOG4J2-73.



 docs: download site and how to use  RolloverStrategy.
 -

 Key: LOG4J2-73
 URL: https://issues.apache.org/jira/browse/LOG4J2-73
 Project: Log4j 2
  Issue Type: Improvement
  Components: Documentation
Affects Versions: 2.0-alpha2
 Environment: all
Reporter: Tushar
Priority: Minor
 Fix For: 2.0-beta1


 can you show a sample in 
 http://logging.apache.org/log4j/2.x/manual/appenders.html#RolloverStrategies 
 on how to use RolloverStrategy tag?
 also be a good idea to give us a command or better a zip/ gz of the doc files 
 so we can store them locally

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Closed] (LOG4J2-87) docs in zip and pdf

[Tushar (JIRA)]

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

Tushar closed LOG4J2-87.



thank you

 docs in zip and pdf
 ---

 Key: LOG4J2-87
 URL: https://issues.apache.org/jira/browse/LOG4J2-87
 Project: Log4j 2
  Issue Type: Improvement
  Components: Documentation
 Environment: all
Reporter: Tushar
Priority: Minor
 Fix For: 2.0-beta3


 please make a zip of all docs in html that we can download and view offline
 should be html zip at least. Pdf is not always convenient.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Resolved] (LOG4J2-87) docs in zip and pdf

[Ralph Goers (JIRA)]

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

Ralph Goers resolved LOG4J2-87.
---

   Resolution: Fixed
Fix Version/s: 2.0-beta3

The site build will now generate a PDF version of the user's guide. The release 
instructions at http://wiki.apache.org/logging/Log4j2ReleaseGuide now include 
instructions to publish the zip of the site.

 docs in zip and pdf
 ---

 Key: LOG4J2-87
 URL: https://issues.apache.org/jira/browse/LOG4J2-87
 Project: Log4j 2
  Issue Type: Improvement
  Components: Documentation
 Environment: all
Reporter: Tushar
Priority: Minor
 Fix For: 2.0-beta3


 please make a zip of all docs in html that we can download and view offline
 should be html zip at least. Pdf is not always convenient.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Closed] (LOG4J2-90) docs - tip for -server

[Tushar (JIRA)]

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

Tushar closed LOG4J2-90.



 docs - tip for -server
 --

 Key: LOG4J2-90
 URL: https://issues.apache.org/jira/browse/LOG4J2-90
 Project: Log4j 2
  Issue Type: Improvement
  Components: Documentation
 Environment: windows
Reporter: Tushar
Priority: Minor
 Fix For: 2.0-beta2


 Should add following to a FAQ or a page called 'improving log4j performance'
 I discovered that adding -Dmaven.surefire.debug=-server to the command 
 line for SimplePerfTest yields performance similar to OS/X and Linux. The 
 implication is that Log4j2 is benefitting greatly from the Hotspot compiler 
 (27 nanoseconds per iteration with the default and 2 nanoseconds per 
 iteration with -server). This probably also explains why, when I tried to to 
 profiling with YourKit making changes to eliminate what YourKit was finding 
 as hot spots made absolutely no difference as HotSpot was already eliminating 
 them. However, making the changes manually might bring the performance in 
 -client mode closer to -server.
 But talk about adding it to your server java call. Also might be mentioning - 
 On windows server systems this happens automatically - I guess Java figured 
 out its being called on a server class environment. but it does make a 
 difference on a developer/ QA system 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Resolved] (LOG4J2-90) docs - tip for -server

[Ralph Goers (JIRA)]

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

Ralph Goers resolved LOG4J2-90.
---

   Resolution: Fixed
Fix Version/s: 2.0-beta2

Add information on client vs server to the performance page.

 docs - tip for -server
 --

 Key: LOG4J2-90
 URL: https://issues.apache.org/jira/browse/LOG4J2-90
 Project: Log4j 2
  Issue Type: Improvement
  Components: Documentation
 Environment: windows
Reporter: Tushar
Priority: Minor
 Fix For: 2.0-beta2


 Should add following to a FAQ or a page called 'improving log4j performance'
 I discovered that adding -Dmaven.surefire.debug=-server to the command 
 line for SimplePerfTest yields performance similar to OS/X and Linux. The 
 implication is that Log4j2 is benefitting greatly from the Hotspot compiler 
 (27 nanoseconds per iteration with the default and 2 nanoseconds per 
 iteration with -server). This probably also explains why, when I tried to to 
 profiling with YourKit making changes to eliminate what YourKit was finding 
 as hot spots made absolutely no difference as HotSpot was already eliminating 
 them. However, making the changes manually might bring the performance in 
 -client mode closer to -server.
 But talk about adding it to your server java call. Also might be mentioning - 
 On windows server systems this happens automatically - I guess Java figured 
 out its being called on a server class environment. but it does make a 
 difference on a developer/ QA system 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Created] (LOG4J2-90) docs - tip for -server

[Tushar (JIRA)]

Tushar created LOG4J2-90:


 Summary: docs - tip for -server
 Key: LOG4J2-90
 URL: https://issues.apache.org/jira/browse/LOG4J2-90
 Project: Log4j 2
  Issue Type: Improvement
  Components: Documentation
 Environment: windows
Reporter: Tushar
Priority: Minor


Should add following to a FAQ or a page called 'improving log4j performance'

I discovered that adding -Dmaven.surefire.debug=-server to the command line 
for SimplePerfTest yields performance similar to OS/X and Linux. The 
implication is that Log4j2 is benefitting greatly from the Hotspot compiler (27 
nanoseconds per iteration with the default and 2 nanoseconds per iteration with 
-server). This probably also explains why, when I tried to to profiling with 
YourKit making changes to eliminate what YourKit was finding as hot spots made 
absolutely no difference as HotSpot was already eliminating them. However, 
making the changes manually might bring the performance in -client mode closer 
to -server.

But talk about adding it to your server java call. Also might be mentioning - 
On windows server systems this happens automatically - I guess Java figured out 
its being called on a server class environment. but it does make a difference 
on a developer/ QA system 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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