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

Stefan Bodewig commented on LOG4NET-212:
----------------------------------------

The same is true fro AppenderSkeleton.RenderLoggingEvent(LoggingEvent).

I agree that proper locking would impact performance more than simply creating 
new StringWriters as needed.  I'll set up some simplistic multi-threaded test 
scenario.

> Threading bug in the PatternConverter.cs
> ----------------------------------------
>
>                 Key: LOG4NET-212
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-212
>             Project: Log4net
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.2.10
>         Environment: Windows, .NET 2.0 / 3.5, C#
>            Reporter: Jerry van Leeuwen
>             Fix For: 1.2.11
>
>
> Every once in a while I get the following exception:
>    System.ArgumentOutOfRangeException: Index and length must refer to a 
> location within the string.
>     Parameter name: length
>        at System.String.InternalSubStringWithChecks(Int32 startIndex, Int32 
> length, Boolean fAlwaysCopy)
>        at System.Text.StringBuilder.ToString(Int32 startIndex, Int32 length)
>        at log4net.Util.PatternConverter.Format(TextWriter writer, Object 
> state) in xxx\Log4Net\src\Util\PatternConverter.cs:line 187
>        at log4net.Layout.PatternLayout.Format(TextWriter writer, LoggingEvent 
> loggingEvent) in xxx\Log4Net\src\Layout\PatternLayout.cs:line 1009
>        at 
> Nemmco.Common.Initialization.Internal.NemLoggingAppender.Execute(DateTime 
> lastTrigger, DateTime currentTrigger) in 
> xxxInitialization\Internal\InitializationLogging.cs:line 765
> --snip--
> From my own investigation it looks like the problem occurs because the shared 
> string buffer (from the m_formatWriter.GetStringBuilder() call) may end up in 
> a state where its size is adjusted differently on separate threads, causing 
> one thread to over-estimate the available length.
> I wonder if the re-use of a StringWriter / StringBuilder in this scenario 
> actually outweighs the threading implications? The simplest fix would be to 
> replace use of m_formatWriter with use of a local StringWriter / 
> StringBuilder.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to