Günter Bögel | 16 Apr 15:47 2014
Picon

RE: Flush on idle (BufferingForwardingAppender)

Hi,
 
would be nice if the BufferingForwardingAppender could be configured to flush during idle times. So how about adding:
 
        private int m_flushOnIdle;
        private DateTime m_lastAppendTime=DateTime.Now;
 
        virtual public int FlushOnIdle
        {
            get { return m_flushOnIdle; }
            set
            {
                m_flushOnIdle = value;
                if (m_flushOnIdle==0) return;
                new Thread(() =>
                {
                    while (m_flushOnIdle>0) {
                        Thread.Sleep(m_flushOnIdle/2);
                        if (DateTime.Now - m_lastAppendTime > new TimeSpan(0, 0, 0, 0, m_flushOnIdle))
                            Flush();
                    }
                }){IsBackground = true}.Start();
            }
        }
 
And:
 
    override protected void Append(LoggingEvent loggingEvent)
    {
        m_lastAppendTime = DateTime.Now;
        ........
 
Regards,
Günter
           
Fyodor Soikin (JIRA | 5 Apr 03:52 2014
Picon

[jira] [Created] (LOG4NET-431) The AppenderSkeleton.DoAppend methods may cause deadlocks

Fyodor Soikin created LOG4NET-431:
-------------------------------------

             Summary: The AppenderSkeleton.DoAppend methods may cause deadlocks
                 Key: LOG4NET-431
                 URL: https://issues.apache.org/jira/browse/LOG4NET-431
             Project: Log4net
          Issue Type: Bug
          Components: Appenders
            Reporter: Fyodor Soikin

The AppenderSkeleton.DoAppender method calls a few methods (in particular, FilterEvent,
PreAppendCheck, and Append), which are virtual.

Calling code you don't control from within a synchronization block is a major no-no, thread-safely
speaking. It may cause deadlocks - and, in my case, does cause them.

In my particular case, the runaway code path starts with calling .ToString() on one of the format
arguments. That particular argument is a complex object, whose ToString() implementation calls a few
other components, some of which also use [poorly designed] synchronization constructs.

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

ehmdjii (JIRA | 4 Apr 11:22 2014
Picon

[jira] [Commented] (LOG4NET-418) Recursive read lock acquisitions not allowed in this mode.


    [
https://issues.apache.org/jira/browse/LOG4NET-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13959799#comment-13959799
] 

ehmdjii commented on LOG4NET-418:
---------------------------------

this can be reproduced like this:

            var stack = new StackTrace();
            var current = stack.GetFrames();
            if (current != null)
            {
                foreach (var stackframe in current)
                {
                    if (_assemblies.Contains(stackframe.GetMethod().Module.Assembly)) // condition to check if it is a
certain assebly
                    {
                        log.Info(value);
                        return;
                    }
                }
            }

> Recursive read lock acquisitions not allowed in this mode.
> ----------------------------------------------------------
>
>                 Key: LOG4NET-418
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-418
>             Project: Log4net
>          Issue Type: Bug
>          Components: Appenders
>            Reporter: Fabio Marini
>
> I'm getting the unhandled exception above when calling log.Logger.Repository.GetAppenders(); -
understand unhandled exceptions should not occur and should be treated as bugs?

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

Dominik Psenner (JIRA | 26 Mar 13:13 2014
Picon

[jira] [Commented] (LOG4NET-429) Pattern with Context property causes severe slowdown


    [
https://issues.apache.org/jira/browse/LOG4NET-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13947840#comment-13947840
] 

Dominik Psenner commented on LOG4NET-429:
-----------------------------------------

Did someone actually test the patch against the current trunk? I would appreciate if someone did that
before I commit the patch.

> Pattern with Context property causes severe slowdown
> ----------------------------------------------------
>
>                 Key: LOG4NET-429
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-429
>             Project: Log4net
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 1.2.13
>            Reporter: Jonas Versén
>            Assignee: Dominik Psenner
>            Priority: Minor
>              Labels: performance
>         Attachments: LOG4NET-429.patch
>
>
> If you use a context property in your appenders pattern, there will be a significant logging slowdown. In
my experience anywhere from 3 to 5 times slower (this will depend on the appender).
> I believe that as soon as you use a context property log4net will internally access the windows user name
even though it's not the property you want to access. This theory comes from the fact that printing all
properties in the pattern (including the costly property username) compared to just printing one will
slow down the logging with the same factor.
> I've made a stackoverflow question with more details as well
> http://stackoverflow.com/questions/22612286/using-log4net-context-properties-has-negative-impact-on-performance/

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

Jonas Versén (JIRA | 26 Mar 10:47 2014
Picon

[jira] [Commented] (LOG4NET-429) Pattern with Context property causes severe slowdown


    [
https://issues.apache.org/jira/browse/LOG4NET-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13947735#comment-13947735
] 

Jonas Versén commented on LOG4NET-429:
--------------------------------------

Solution 3 sounds like the best solution given the circumstances you've listed. +1 from me

> Pattern with Context property causes severe slowdown
> ----------------------------------------------------
>
>                 Key: LOG4NET-429
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-429
>             Project: Log4net
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 1.2.13
>            Reporter: Jonas Versén
>            Assignee: Dominik Psenner
>            Priority: Minor
>              Labels: performance
>         Attachments: LOG4NET-429.patch
>
>
> If you use a context property in your appenders pattern, there will be a significant logging slowdown. In
my experience anywhere from 3 to 5 times slower (this will depend on the appender).
> I believe that as soon as you use a context property log4net will internally access the windows user name
even though it's not the property you want to access. This theory comes from the fact that printing all
properties in the pattern (including the costly property username) compared to just printing one will
slow down the logging with the same factor.
> I've made a stackoverflow question with more details as well
> http://stackoverflow.com/questions/22612286/using-log4net-context-properties-has-negative-impact-on-performance/

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

Natanael Arndt (JIRA | 25 Mar 16:38 2014
Picon

[jira] [Closed] (LOG4NET-430) Wrong space handling in FileModelAssembler


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

Natanael Arndt closed LOG4NET-430.
----------------------------------

    Resolution: Invalid

> Wrong space handling in FileModelAssembler
> ------------------------------------------
>
>                 Key: LOG4NET-430
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-430
>             Project: Log4net
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.2.13
>            Reporter: Natanael Arndt
>
> The method {{getDirectoryName}} in
{{com.hp.hpl.jena.assembler.assemblers.FileModelAssembler}} should also make sure that at some
chars, like space should be urldecoded again. E.g. If the URI is
{{file:///tmp/file%20name%20with%20space}} the corresponding file can not be found under
{{/tmp/file%20name%20with%20space}} but under  {{/tmp/file name with space}}.
> There might be some other chars which have to be taken into account, e.g. "%25" -> "%", but I don't think a
urldecode over the whole string is correct.
> Sorry I can't provide an example yet, because I couldn't isolate this part of the code so far and I didn't try
to write a test for this.

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

Natanael Arndt (JIRA | 25 Mar 16:36 2014
Picon

[jira] [Commented] (LOG4NET-430) Wrong space handling in FileModelAssembler


    [
https://issues.apache.org/jira/browse/LOG4NET-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13946682#comment-13946682
] 

Natanael Arndt commented on LOG4NET-430:
----------------------------------------

Sorry this issue was meant for jena

> Wrong space handling in FileModelAssembler
> ------------------------------------------
>
>                 Key: LOG4NET-430
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-430
>             Project: Log4net
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.2.13
>            Reporter: Natanael Arndt
>
> The method {{getDirectoryName}} in
{{com.hp.hpl.jena.assembler.assemblers.FileModelAssembler}} should also make sure that at some
chars, like space should be urldecoded again. E.g. If the URI is
{{file:///tmp/file%20name%20with%20space}} the corresponding file can not be found under
{{/tmp/file%20name%20with%20space}} but under  {{/tmp/file name with space}}.
> There might be some other chars which have to be taken into account, e.g. "%25" -> "%", but I don't think a
urldecode over the whole string is correct.
> Sorry I can't provide an example yet, because I couldn't isolate this part of the code so far and I didn't try
to write a test for this.

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

Natanael Arndt (JIRA | 25 Mar 16:34 2014
Picon

[jira] [Created] (LOG4NET-430) Wrong space handling in FileModelAssembler

Natanael Arndt created LOG4NET-430:
--------------------------------------

             Summary: Wrong space handling in FileModelAssembler
                 Key: LOG4NET-430
                 URL: https://issues.apache.org/jira/browse/LOG4NET-430
             Project: Log4net
          Issue Type: Bug
          Components: Core
    Affects Versions: 1.2.13
            Reporter: Natanael Arndt

The method {{getDirectoryName}} in {{com.hp.hpl.jena.assembler.assemblers.FileModelAssembler}}
should also make sure that at some chars, like space should be urldecoded again. E.g. If the URI is
{{file:///tmp/file%20name%20with%20space}} the corresponding file can not be found under
{{/tmp/file%20name%20with%20space}} but under  {{/tmp/file name with space}}.

There might be some other chars which have to be taken into account, e.g. "%25" -> "%", but I don't think a
urldecode over the whole string is correct.

Sorry I can't provide an example yet, because I couldn't isolate this part of the code so far and I didn't try
to write a test for this.

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

Tom Voros (JIRA | 25 Mar 14:58 2014
Picon

[jira] [Commented] (LOG4NET-421) Inclusion of UserName in composite properties dictionary has a significant performance impact


    [
https://issues.apache.org/jira/browse/LOG4NET-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13946552#comment-13946552
] 

Tom Voros commented on LOG4NET-421:
-----------------------------------

Thank you for acknowledging the issue.  I'm optimistic about the solution you've offered in LOG4NET-429.  :)

I can't seem to edit the description above but I wanted to clarify that the "fix" workaround will not work in
all cases.  Only certain appender types support the <fix ... /> option and unfortunately
RollingFileAppender (the most common appender type?) is not one of them.

> Inclusion of UserName in composite properties dictionary has a significant performance impact
> ---------------------------------------------------------------------------------------------
>
>                 Key: LOG4NET-421
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-421
>             Project: Log4net
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.2.13
>         Environment: Issue was observed on Windows Server 2008 R2 with an ASP.NET 4.0 application.
>            Reporter: Tom Voros
>            Assignee: Dominik Psenner
>              Labels: performance
>
> A change made for LOG4NET-205 has the LoggingEvent.CreateCompositeProperties method get the UserName
property for every log event.  Since getting the UserName is very slow, this change has a significant
impact on performance in log4net.
> In one trace captured with dotTrace on a large web application we found that the get UserName property
(called from CreateCompositeProperties) accounted for 34% of all time spent in log4net code.
> Our workaround for the issue has been to "fix" the UserName property by adding <fix value="32" /> to all our appenders.

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

Dominik Psenner (JIRA | 25 Mar 14:32 2014
Picon

[jira] [Commented] (LOG4NET-429) Pattern with Context property causes severe slowdown


    [
https://issues.apache.org/jira/browse/LOG4NET-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13946509#comment-13946509
] 

Dominik Psenner commented on LOG4NET-429:
-----------------------------------------

Alright, with another +1 for solution 3 I'll commit the patch. So far I've tested the functionality and ran
performance tests, meaning that the username appears in the rendered log messages and the performance
penalty is hit only in those cases where the username is rendered. However, the performance hit is still
doubled when one uses a combination of _%username_ and _%properties\{log4net:UserName}_ in one
pattern but unfortunately there's no easy way around that. I'm considering that as a bearable compromise.

> Pattern with Context property causes severe slowdown
> ----------------------------------------------------
>
>                 Key: LOG4NET-429
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-429
>             Project: Log4net
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 1.2.13
>            Reporter: Jonas Versén
>            Assignee: Dominik Psenner
>            Priority: Minor
>              Labels: performance
>         Attachments: LOG4NET-429.patch
>
>
> If you use a context property in your appenders pattern, there will be a significant logging slowdown. In
my experience anywhere from 3 to 5 times slower (this will depend on the appender).
> I believe that as soon as you use a context property log4net will internally access the windows user name
even though it's not the property you want to access. This theory comes from the fact that printing all
properties in the pattern (including the costly property username) compared to just printing one will
slow down the logging with the same factor.
> I've made a stackoverflow question with more details as well
> http://stackoverflow.com/questions/22612286/using-log4net-context-properties-has-negative-impact-on-performance/

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

Dominik Psenner (JIRA | 25 Mar 14:20 2014
Picon

[jira] [Commented] (LOG4NET-429) Pattern with Context property causes severe slowdown


    [
https://issues.apache.org/jira/browse/LOG4NET-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13946500#comment-13946500
] 

Dominik Psenner commented on LOG4NET-429:
-----------------------------------------

Indeed, I've linked and closed LOG4NET-421.

> Pattern with Context property causes severe slowdown
> ----------------------------------------------------
>
>                 Key: LOG4NET-429
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-429
>             Project: Log4net
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 1.2.13
>            Reporter: Jonas Versén
>            Assignee: Dominik Psenner
>            Priority: Minor
>              Labels: performance
>         Attachments: LOG4NET-429.patch
>
>
> If you use a context property in your appenders pattern, there will be a significant logging slowdown. In
my experience anywhere from 3 to 5 times slower (this will depend on the appender).
> I believe that as soon as you use a context property log4net will internally access the windows user name
even though it's not the property you want to access. This theory comes from the fact that printing all
properties in the pattern (including the costly property username) compared to just printing one will
slow down the logging with the same factor.
> I've made a stackoverflow question with more details as well
> http://stackoverflow.com/questions/22612286/using-log4net-context-properties-has-negative-impact-on-performance/

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


Gmane