[
https://issues.apache.org/jira/browse/LOG4NET-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13100271#comment-13100271
]
Stefan Bodewig edited comment on LOG4NET-212 at 9/8/11 12:50 PM:
-----------------------------------------------------------------
The same is true for 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.
was (Author: bodewig):
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
