[jira] [Commented] (LOG4NET-562) LogicalThreadContext is not per Thread
[
https://issues.apache.org/jira/browse/LOG4NET-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15960445#comment-15960445
]
Dominik Psenner commented on LOG4NET-562:
-
Have you tried to include the actual thread that the code executes in by
logging System.Threading.Thread.CurrentThread.ManagedThreadId?
> LogicalThreadContext is not per Thread
> --
>
> Key: LOG4NET-562
> URL: https://issues.apache.org/jira/browse/LOG4NET-562
> Project: Log4net
> Issue Type: Bug
> Components: Other
>Affects Versions: 2.0.8
> Environment: Windows 10, Visual Studio 17, .NET Framework 4.5.2
>Reporter: Husain Alshehhi
>
> LogicalThreadContext values are spread to many threads when they shouldn't.
> This is an example:
> {code:title=console.cs|borderStyle=solid}
> LogicalThreadContext.Properties["x-corralation-Id"] =
> "original-value";
> var list = new List {1, 2, 3, 4, 5, 6, 7, 8, 9, 0};
> Parallel.ForEach(list, (i) =>
> {
> if (i == 3)
> LogicalThreadContext.Properties["x-corralation-Id"] =
> "modified-value";
> logger.Info($"thread {i}.");
> });
> {code}
> this is the result
> {code:title=badresult.txt|borderStyle=solid}
> {"timestamp":"2017-04-05T12:31:41.117Z", "level":"INFO", "x-corralation-Id" :
> "original-value", "logger":"logger", "message":"thread 1.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.132Z", "level":"INFO", "x-corralation-Id" :
> "modified-value", "logger":"logger", "message":"thread 3.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.273Z", "level":"INFO", "x-corralation-Id" :
> "modified-value", "logger":"logger", "message":"thread 4.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.273Z", "level":"INFO", "x-corralation-Id" :
> "modified-value", "logger":"logger", "message":"thread 6.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.274Z", "level":"INFO", "x-corralation-Id" :
> "modified-value", "logger":"logger", "message":"thread 8.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.274Z", "level":"INFO", "x-corralation-Id" :
> "modified-value", "logger":"logger", "message":"thread 0.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.219Z", "level":"INFO", "x-corralation-Id" :
> "original-value", "logger":"logger", "message":"thread 7.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.179Z", "level":"INFO", "x-corralation-Id" :
> "original-value", "logger":"logger", "message":"thread 5.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.273Z", "level":"INFO", "x-corralation-Id" :
> "original-value", "logger":"logger", "message":"thread 2.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.234Z", "level":"INFO", "x-corralation-Id" :
> "original-value", "logger":"logger", "message":"thread 9.", "data":(null)}
> {code}
> This is what I was expecting:
> {code:title=goodresult.txt|borderStyle=solid}
> {"timestamp":"2017-04-05T12:31:41.117Z", "level":"INFO", "x-corralation-Id" :
> "original-value", "logger":"logger", "message":"thread 1.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.132Z", "level":"INFO", "x-corralation-Id" :
> "modified-value", "logger":"logger", "message":"thread 3.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.273Z", "level":"INFO", "x-corralation-Id" :
> "original-value", "logger":"logger", "message":"thread 4.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.273Z", "level":"INFO", "x-corralation-Id" :
> "original-value", "logger":"logger", "message":"thread 6.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.274Z", "level":"INFO", "x-corralation-Id" :
> "original-value", "logger":"logger", "message":"thread 8.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.274Z", "level":"INFO", "x-corralation-Id" :
> "original-value", "logger":"logger", "message":"thread 0.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.219Z", "level":"INFO", "x-corralation-Id" :
> "original-value", "logger":"logger", "message":"thread 7.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.179Z", "level":"INFO", "x-corralation-Id" :
> "original-value", "logger":"logger", "message":"thread 5.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.273Z", "level":"INFO", "x-corralation-Id" :
> "original-value", "logger":"logger", "message":"thread 2.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.234Z", "level":"INFO", "x-corralation-Id" :
> "original-value", "logger":"logger", "message":"thread 9.", "data":(null)}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (LOG4NET-562) LogicalThreadContext is not per Thread
[
https://issues.apache.org/jira/browse/LOG4NET-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15958776#comment-15958776
]
Dominik Psenner commented on LOG4NET-562:
-
To me this works as designed. The LogicalThreadContext is not intended to be
unique for each thread. It is a "logical thread context", which may travel from
one thread to another.
> LogicalThreadContext is not per Thread
> --
>
> Key: LOG4NET-562
> URL: https://issues.apache.org/jira/browse/LOG4NET-562
> Project: Log4net
> Issue Type: Bug
> Components: Other
>Affects Versions: 2.0.8
> Environment: Windows 10, Visual Studio 17, .NET Framework 4.5.2
>Reporter: Husain Alshehhi
>
> LogicalThreadContext values are spread to many threads when they shouldn't.
> This is an example:
> {code:title=console.cs|borderStyle=solid}
> LogicalThreadContext.Properties["x-corralation-Id"] =
> "original-value";
> var list = new List {1, 2, 3, 4, 5, 6, 7, 8, 9, 0};
> Parallel.ForEach(list, (i) =>
> {
> if (i == 3)
> LogicalThreadContext.Properties["x-corralation-Id"] =
> "modified-value";
> logger.Info($"thread {i}.");
> });
> {code}
> this is the result
> {code:title=badresult.txt|borderStyle=solid}
> {"timestamp":"2017-04-05T12:31:41.117Z", "level":"INFO", "x-corralation-Id" :
> "original-value", "logger":"logger", "message":"thread 1.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.132Z", "level":"INFO", "x-corralation-Id" :
> "modified-value", "logger":"logger", "message":"thread 3.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.273Z", "level":"INFO", "x-corralation-Id" :
> "modified-value", "logger":"logger", "message":"thread 4.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.273Z", "level":"INFO", "x-corralation-Id" :
> "modified-value", "logger":"logger", "message":"thread 6.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.274Z", "level":"INFO", "x-corralation-Id" :
> "modified-value", "logger":"logger", "message":"thread 8.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.274Z", "level":"INFO", "x-corralation-Id" :
> "modified-value", "logger":"logger", "message":"thread 0.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.219Z", "level":"INFO", "x-corralation-Id" :
> "original-value", "logger":"logger", "message":"thread 7.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.179Z", "level":"INFO", "x-corralation-Id" :
> "original-value", "logger":"logger", "message":"thread 5.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.273Z", "level":"INFO", "x-corralation-Id" :
> "original-value", "logger":"logger", "message":"thread 2.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.234Z", "level":"INFO", "x-corralation-Id" :
> "original-value", "logger":"logger", "message":"thread 9.", "data":(null)}
> {code}
> This is what I was expecting:
> {code:title=goodresult.txt|borderStyle=solid}
> {"timestamp":"2017-04-05T12:31:41.117Z", "level":"INFO", "x-corralation-Id" :
> "original-value", "logger":"logger", "message":"thread 1.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.132Z", "level":"INFO", "x-corralation-Id" :
> "modified-value", "logger":"logger", "message":"thread 3.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.273Z", "level":"INFO", "x-corralation-Id" :
> "original-value", "logger":"logger", "message":"thread 4.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.273Z", "level":"INFO", "x-corralation-Id" :
> "original-value", "logger":"logger", "message":"thread 6.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.274Z", "level":"INFO", "x-corralation-Id" :
> "original-value", "logger":"logger", "message":"thread 8.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.274Z", "level":"INFO", "x-corralation-Id" :
> "original-value", "logger":"logger", "message":"thread 0.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.219Z", "level":"INFO", "x-corralation-Id" :
> "original-value", "logger":"logger", "message":"thread 7.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.179Z", "level":"INFO", "x-corralation-Id" :
> "original-value", "logger":"logger", "message":"thread 5.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.273Z", "level":"INFO", "x-corralation-Id" :
> "original-value", "logger":"logger", "message":"thread 2.", "data":(null)}
> {"timestamp":"2017-04-05T12:31:41.234Z", "level":"INFO", "x-corralation-Id" :
> "original-value", "logger":"logger", "message":"thread 9.", "data":(null)}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (LOG4NET-555) RollingFileAppenderTests fail when run on Linux
[ https://issues.apache.org/jira/browse/LOG4NET-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15958370#comment-15958370 ] Dominik Psenner commented on LOG4NET-555: - This may be among the reasons: http://stackoverflow.com/questions/21266949/mono-alternative-for-named-mutex > RollingFileAppenderTests fail when run on Linux > --- > > Key: LOG4NET-555 > URL: https://issues.apache.org/jira/browse/LOG4NET-555 > Project: Log4net > Issue Type: Bug >Affects Versions: 2.0.6, 2.0.7 > Environment: CentOS 7 >Reporter: Thomas Clegg > Labels: netstandard > > While testing the fix for LOG4NET-554 I ran all tests on both Windows and > CentOS, all tests passed on Windows however some RollingFileAppender tests > failed when tested on Linux: TestExclusiveLockLocks, > TestInterProcessLockFails (all others passed). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (LOG4NET-552) Incorrect behavior of RollingFileAppender while rolling files, if multiple processes appending into same file
[ https://issues.apache.org/jira/browse/LOG4NET-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15947044#comment-15947044 ] Dominik Psenner edited comment on LOG4NET-552 at 3/29/17 12:48 PM: --- 1. This sounds like LOG4NET-487 which is an improvement of LOG4NET-485. 2. Please open a pull request to allow code reviews. Without that we are unable to answer this question. 3. Great news, note that it is very unlikely that your patch is going to be applied if it fixes rolling by date but breaks rolling by size. was (Author: nachbarslumpi): 1. I couldn't find the log4net issue, but this sounds like LOG4NET-487 which is an improvement of LOG4NET-485. 2. Please open a pull request to allow code reviews. Without that we are unable to answer this question. 3. Great news, note that it is very unlikely that your patch is going to be applied if it fixes rolling by date but breaks rolling by size. > Incorrect behavior of RollingFileAppender while rolling files, if multiple > processes appending into same file > - > > Key: LOG4NET-552 > URL: https://issues.apache.org/jira/browse/LOG4NET-552 > Project: Log4net > Issue Type: Bug > Components: Appenders >Affects Versions: 1.2.15 > Environment: Windows Server 2008 R2 Enterprise >Reporter: Sachin Abaso Patil >Priority: Blocker > Attachments: Modification in AdjustFileBeforeAppend.png > > > Hi Team, > This issue has become blocker for us, as on our production environment, > multiple processes are appending log into single log file which has no issue, > but while rolling it overwrites files and thus missing log entries. > Based on link below, it looks like log file rolling mechanism of log4net is > not process safe even after using FileAppender.InterProcessLock. > Link: https://issues.apache.org/jira/browse/LOG4NET-485 > Also, in FAQ (https://logging.apache.org/log4net/release/faq.html) under > section “How do I get multiple process to log to the same file?”, it has been > clearly mentioned that, rolling files is simply not compatible with multiple > process scenario. > My questions, > 1.We are using version “1.2.15”. Are you planning to fix above mentioned > rolling issue in upcoming release? If yes then please provide tentative > release date. > 2.We had incorporated log4net in our project in year 2009, had FAQ > mentioned this limitation (rolling file not compatible with multi process) in > year 2009? Because we while studying log4net during year 2009 we do not > remember seeing this note in FAQ? > Requesting you to please respond as soon as possible with your comments. > Below is how we have configured appender for all processes, > type="log4net.Appender.RollingFileAppender"> > > > type="log4net.Appender.FileAppender+MinimalLock" /> > > > > > > > > > > > > > > Thanks, > Sachin Patil -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (LOG4NET-552) Incorrect behavior of RollingFileAppender while rolling files, if multiple processes appending into same file
[ https://issues.apache.org/jira/browse/LOG4NET-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15947044#comment-15947044 ] Dominik Psenner commented on LOG4NET-552: - 1. I couldn't find the log4net issue, but this sounds like LOG4NET-487 which is an improvement of LOG4NET-485. 2. Please open a pull request to allow code reviews. Without that we are unable to answer this question. 3. Great news, note that it is very unlikely that your patch is going to be applied if it fixes rolling by date but breaks rolling by size. > Incorrect behavior of RollingFileAppender while rolling files, if multiple > processes appending into same file > - > > Key: LOG4NET-552 > URL: https://issues.apache.org/jira/browse/LOG4NET-552 > Project: Log4net > Issue Type: Bug > Components: Appenders >Affects Versions: 1.2.15 > Environment: Windows Server 2008 R2 Enterprise >Reporter: Sachin Abaso Patil >Priority: Blocker > Attachments: Modification in AdjustFileBeforeAppend.png > > > Hi Team, > This issue has become blocker for us, as on our production environment, > multiple processes are appending log into single log file which has no issue, > but while rolling it overwrites files and thus missing log entries. > Based on link below, it looks like log file rolling mechanism of log4net is > not process safe even after using FileAppender.InterProcessLock. > Link: https://issues.apache.org/jira/browse/LOG4NET-485 > Also, in FAQ (https://logging.apache.org/log4net/release/faq.html) under > section “How do I get multiple process to log to the same file?”, it has been > clearly mentioned that, rolling files is simply not compatible with multiple > process scenario. > My questions, > 1.We are using version “1.2.15”. Are you planning to fix above mentioned > rolling issue in upcoming release? If yes then please provide tentative > release date. > 2.We had incorporated log4net in our project in year 2009, had FAQ > mentioned this limitation (rolling file not compatible with multi process) in > year 2009? Because we while studying log4net during year 2009 we do not > remember seeing this note in FAQ? > Requesting you to please respond as soon as possible with your comments. > Below is how we have configured appender for all processes, > type="log4net.Appender.RollingFileAppender"> > > > type="log4net.Appender.FileAppender+MinimalLock" /> > > > > > > > > > > > > > > Thanks, > Sachin Patil -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (LOG4NET-552) Incorrect behavior of RollingFileAppender while rolling files, if multiple processes appending into same file
[ https://issues.apache.org/jira/browse/LOG4NET-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15944804#comment-15944804 ] Dominik Psenner commented on LOG4NET-552: - 1. This changes the current behavior and therefore is probably a breaking change. 2. This hits anyone even when a mutex is not required. I don't know what side effects or collateral damage can be caused by your patch and therefore I again advice you to rethink your logging configuration. > Incorrect behavior of RollingFileAppender while rolling files, if multiple > processes appending into same file > - > > Key: LOG4NET-552 > URL: https://issues.apache.org/jira/browse/LOG4NET-552 > Project: Log4net > Issue Type: Bug > Components: Appenders >Affects Versions: 1.2.15 > Environment: Windows Server 2008 R2 Enterprise >Reporter: Sachin Abaso Patil >Priority: Blocker > Attachments: Modification in AdjustFileBeforeAppend.png > > > Hi Team, > This issue has become blocker for us, as on our production environment, > multiple processes are appending log into single log file which has no issue, > but while rolling it overwrites files and thus missing log entries. > Based on link below, it looks like log file rolling mechanism of log4net is > not process safe even after using FileAppender.InterProcessLock. > Link: https://issues.apache.org/jira/browse/LOG4NET-485 > Also, in FAQ (https://logging.apache.org/log4net/release/faq.html) under > section “How do I get multiple process to log to the same file?”, it has been > clearly mentioned that, rolling files is simply not compatible with multiple > process scenario. > My questions, > 1.We are using version “1.2.15”. Are you planning to fix above mentioned > rolling issue in upcoming release? If yes then please provide tentative > release date. > 2.We had incorporated log4net in our project in year 2009, had FAQ > mentioned this limitation (rolling file not compatible with multi process) in > year 2009? Because we while studying log4net during year 2009 we do not > remember seeing this note in FAQ? > Requesting you to please respond as soon as possible with your comments. > Below is how we have configured appender for all processes, > type="log4net.Appender.RollingFileAppender"> > > > type="log4net.Appender.FileAppender+MinimalLock" /> > > > > > > > > > > > > > > Thanks, > Sachin Patil -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (LOG4NET-552) Incorrect behavior of RollingFileAppender while rolling files, if multiple processes appending into same file
[ https://issues.apache.org/jira/browse/LOG4NET-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15927616#comment-15927616 ] Dominik Psenner commented on LOG4NET-552: - I'm unsure whether we can just remove the overwriting of files. Have you tried to do your modifications and ran the tests? If I had the time to rewrite the rolling file appender, I would not implement mechanisms that overwrite files but rather find a better filename for the rolling destination. For instance consider this situation: There are the following logfiles: * Some.log [size=3MB] * Some.2017-03-16.log [size=45MB] and the time is 2017-03-16 08:30 and therefore the rolling logic would like to roll over "Some.log" again. Then I would expect this outcome: * Some.log [size=0MB] * Some.2017-03-16.log [size=45MB] * Some.2017-03-16.1.log [size=3MB] This behavior however totally breaks the mechanisms that try to limit the number of rolled files. Unfortunately modifications to the rolling file appender can have many side effects that break existing usecases and therefore we avoid patching it. As for your usecase, I again advise you to rethink your logging configuration. You should avoid having several processes that write into the same logfiles! If you want a combined log event for all the processes you have, use a remote appender / adonet appender /... > Incorrect behavior of RollingFileAppender while rolling files, if multiple > processes appending into same file > - > > Key: LOG4NET-552 > URL: https://issues.apache.org/jira/browse/LOG4NET-552 > Project: Log4net > Issue Type: Bug > Components: Appenders >Affects Versions: 1.2.15 > Environment: Windows Server 2008 R2 Enterprise >Reporter: Sachin Abaso Patil >Priority: Blocker > > Hi Team, > This issue has become blocker for us, as on our production environment, > multiple processes are appending log into single log file which has no issue, > but while rolling it overwrites files and thus missing log entries. > Based on link below, it looks like log file rolling mechanism of log4net is > not process safe even after using FileAppender.InterProcessLock. > Link: https://issues.apache.org/jira/browse/LOG4NET-485 > Also, in FAQ (https://logging.apache.org/log4net/release/faq.html) under > section “How do I get multiple process to log to the same file?”, it has been > clearly mentioned that, rolling files is simply not compatible with multiple > process scenario. > My questions, > 1.We are using version “1.2.15”. Are you planning to fix above mentioned > rolling issue in upcoming release? If yes then please provide tentative > release date. > 2.We had incorporated log4net in our project in year 2009, had FAQ > mentioned this limitation (rolling file not compatible with multi process) in > year 2009? Because we while studying log4net during year 2009 we do not > remember seeing this note in FAQ? > Requesting you to please respond as soon as possible with your comments. > Below is how we have configured appender for all processes, > type="log4net.Appender.RollingFileAppender"> > > > type="log4net.Appender.FileAppender+MinimalLock" /> > > > > > > > > > > > > > > Thanks, > Sachin Patil -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (LOG4NET-559) Custom Appender throws exception to user when I use %type in ConversionPattern
[
https://issues.apache.org/jira/browse/LOG4NET-559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15925680#comment-15925680
]
Dominik Psenner commented on LOG4NET-559:
-
Looks like the TypeNamePatternConverter missed a few safety checks. I added a
safety net of checks that should avoid null reference exceptions as of svn
revision 1786989. Would you please test if this fixes your usecase?
> Custom Appender throws exception to user when I use %type in ConversionPattern
> --
>
> Key: LOG4NET-559
> URL: https://issues.apache.org/jira/browse/LOG4NET-559
> Project: Log4net
> Issue Type: Bug
>Affects Versions: 2.0.7
>Reporter: Denis Abramov
>Assignee: Dominik Psenner
>Priority: Blocker
>
> When I setup my custom appender, I use the following ConversionPattern:
>
>
>
> In my custom appender's "Append()" method, the "RenderLoggingEvent" is
> throwing the exception below
> Here's how I am calling the RenderLoggingEvent method:
> protected override void Append(LoggingEvent loggingEvent) {
>...
> var text = RenderLoggingEvent(loggingEvent);
>...
> }
>
> Here is the exception I am getting:
> System.NullReferenceException was unhandled by user code
> HResult=-2147467261
> Message=Object reference not set to an instance of an object.
> Source=log4net
> StackTrace:
>at
> log4net.Layout.Pattern.TypeNamePatternConverter.GetFullyQualifiedName(LoggingEvent
> loggingEvent) in
> c:\log4net\tags\2.0.7RC1\src\Layout\Pattern\TypeNamePatternConverter.cs:line
> 51
>at log4net.Layout.Pattern.NamedPatternConverter.Convert(TextWriter
> writer, LoggingEvent loggingEvent) in
> c:\log4net\tags\2.0.7RC1\src\Layout\Pattern\NamedPatternConverter.cs:line 125
>at log4net.Util.PatternConverter.Format(TextWriter writer, Object
> state) in c:\log4net\tags\2.0.7RC1\src\Util\PatternConverter.cs:line 173
>at log4net.Layout.PatternLayout.Format(TextWriter writer, LoggingEvent
> loggingEvent) in c:\log4net\tags\2.0.7RC1\src\Layout\PatternLayout.cs:line
> 1117
>at log4net.Appender.AppenderSkeleton.RenderLoggingEvent(LoggingEvent
> loggingEvent) in
> c:\log4net\tags\2.0.7RC1\src\Appender\AppenderSkeleton.cs:line 705
>at MyAppender.MyAppender.Append(LoggingEvent loggingEvent) in
> E:\svn\trunk\MyAppender\MyAppender.cs:line 67
>at log4net.Appender.AppenderSkeleton.DoAppend(LoggingEvent
> loggingEvent) in
> c:\log4net\tags\2.0.7RC1\src\Appender\AppenderSkeleton.cs:line 317
> InnerException:
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (LOG4NET-552) Incorrect behavior of RollingFileAppender while rolling files, if multiple processes appending into same file
[ https://issues.apache.org/jira/browse/LOG4NET-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15925675#comment-15925675 ] Dominik Psenner commented on LOG4NET-552: - Rolling by date with multiple processes logging and rolling the same files is never going tobwork without implementing a communication channel in between the processes to share the rolling state information. I advise you to rethink your logging configuration. > Incorrect behavior of RollingFileAppender while rolling files, if multiple > processes appending into same file > - > > Key: LOG4NET-552 > URL: https://issues.apache.org/jira/browse/LOG4NET-552 > Project: Log4net > Issue Type: Bug > Components: Appenders >Affects Versions: 1.2.15 > Environment: Windows Server 2008 R2 Enterprise >Reporter: Sachin Abaso Patil >Priority: Blocker > > Hi Team, > This issue has become blocker for us, as on our production environment, > multiple processes are appending log into single log file which has no issue, > but while rolling it overwrites files and thus missing log entries. > Based on link below, it looks like log file rolling mechanism of log4net is > not process safe even after using FileAppender.InterProcessLock. > Link: https://issues.apache.org/jira/browse/LOG4NET-485 > Also, in FAQ (https://logging.apache.org/log4net/release/faq.html) under > section “How do I get multiple process to log to the same file?”, it has been > clearly mentioned that, rolling files is simply not compatible with multiple > process scenario. > My questions, > 1.We are using version “1.2.15”. Are you planning to fix above mentioned > rolling issue in upcoming release? If yes then please provide tentative > release date. > 2.We had incorporated log4net in our project in year 2009, had FAQ > mentioned this limitation (rolling file not compatible with multi process) in > year 2009? Because we while studying log4net during year 2009 we do not > remember seeing this note in FAQ? > Requesting you to please respond as soon as possible with your comments. > Below is how we have configured appender for all processes, > type="log4net.Appender.RollingFileAppender"> > > > type="log4net.Appender.FileAppender+MinimalLock" /> > > > > > > > > > > > > > > Thanks, > Sachin Patil -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (LOG4NET-552) Incorrect behavior of RollingFileAppender while rolling files, if multiple processes appending into same file
[ https://issues.apache.org/jira/browse/LOG4NET-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15925675#comment-15925675 ] Dominik Psenner edited comment on LOG4NET-552 at 3/15/17 7:32 AM: -- Rolling by date with multiple processes logging and rolling the same files is never going to work without implementing a communication channel in between the processes to share the rolling state information. I advise you to rethink your logging configuration. was (Author: nachbarslumpi): Rolling by date with multiple processes logging and rolling the same files is never going tobwork without implementing a communication channel in between the processes to share the rolling state information. I advise you to rethink your logging configuration. > Incorrect behavior of RollingFileAppender while rolling files, if multiple > processes appending into same file > - > > Key: LOG4NET-552 > URL: https://issues.apache.org/jira/browse/LOG4NET-552 > Project: Log4net > Issue Type: Bug > Components: Appenders >Affects Versions: 1.2.15 > Environment: Windows Server 2008 R2 Enterprise >Reporter: Sachin Abaso Patil >Priority: Blocker > > Hi Team, > This issue has become blocker for us, as on our production environment, > multiple processes are appending log into single log file which has no issue, > but while rolling it overwrites files and thus missing log entries. > Based on link below, it looks like log file rolling mechanism of log4net is > not process safe even after using FileAppender.InterProcessLock. > Link: https://issues.apache.org/jira/browse/LOG4NET-485 > Also, in FAQ (https://logging.apache.org/log4net/release/faq.html) under > section “How do I get multiple process to log to the same file?”, it has been > clearly mentioned that, rolling files is simply not compatible with multiple > process scenario. > My questions, > 1.We are using version “1.2.15”. Are you planning to fix above mentioned > rolling issue in upcoming release? If yes then please provide tentative > release date. > 2.We had incorporated log4net in our project in year 2009, had FAQ > mentioned this limitation (rolling file not compatible with multi process) in > year 2009? Because we while studying log4net during year 2009 we do not > remember seeing this note in FAQ? > Requesting you to please respond as soon as possible with your comments. > Below is how we have configured appender for all processes, > type="log4net.Appender.RollingFileAppender"> > > > type="log4net.Appender.FileAppender+MinimalLock" /> > > > > > > > > > > > > > > Thanks, > Sachin Patil -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (LOG4NET-557) Create a Replacement/Alternative to RollingFileAppender that works
[
https://issues.apache.org/jira/browse/LOG4NET-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15901686#comment-15901686
]
Dominik Psenner commented on LOG4NET-557:
-
Is this not a duplicate of LOG4NET-367?
> Create a Replacement/Alternative to RollingFileAppender that works
> --
>
> Key: LOG4NET-557
> URL: https://issues.apache.org/jira/browse/LOG4NET-557
> Project: Log4net
> Issue Type: New Feature
> Components: Appenders
>Reporter: Stefan Bodewig
> Labels: RollingFileAppender
>
> The number of bugs raised against {{RollingFileAppender}} is pretty huge and
> it is full of bad assumptions. I (Stefan) am convinced that it is impossible
> to fix the code as it is, we need a new one.
> ANY HELP IS VERY MUCH APPRECIATED.
> It doesn't have to mimic the current appender, quite the opposite. Maybe we
> should look over to log4j to see how they have structured things, maybe
> something completely different is needed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (LOG4NET-554) LogicalThreadContext was removed in .NETStandard
[ https://issues.apache.org/jira/browse/LOG4NET-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15872182#comment-15872182 ] Dominik Psenner commented on LOG4NET-554: - Interesting, I look forward seeing a patch! > LogicalThreadContext was removed in .NETStandard > > > Key: LOG4NET-554 > URL: https://issues.apache.org/jira/browse/LOG4NET-554 > Project: Log4net > Issue Type: Bug > Components: Builds >Affects Versions: 2.0.6, 2.0.7 > Environment: .NETStandard1.3 >Reporter: Thomas Clegg > Original Estimate: 504h > Remaining Estimate: 504h > > LogicalThreadContext was excluded from dotnetcore version due to > System.Runtime.Remoting.Messaging no longer being available going forward. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (LOG4NET-553) DebugAppender configuration should give the possibility to disable outputting loggerName as category
[
https://issues.apache.org/jira/browse/LOG4NET-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15862874#comment-15862874
]
Dominik Psenner commented on LOG4NET-553:
-
Finally had the time to read through your last patch. From reading it, it looks
fine. I'm currently on the move and got only my phone with me, therefore I'm
unable to apply the patch and do a thorough testing. I'll try to do that within
the next 72 hours. Thanks for your patience and efforts! Would you like to get
involved further? Log4net needs a man of your skills.
> DebugAppender configuration should give the possibility to disable outputting
> loggerName as category
>
>
> Key: LOG4NET-553
> URL: https://issues.apache.org/jira/browse/LOG4NET-553
> Project: Log4net
> Issue Type: New Feature
> Components: Appenders
>Affects Versions: 2.0.7
>Reporter: Jean-Francois Beaulac
> Attachments: log4net-DebugAppenderCategory2.patch,
> log4net-DebugAppenderCategory3.patch, log4net-DebugAppenderCategory.patch,
> OutputCategoryParam-DebugAppender.cs.patch
>
>
> The DebugAppender always uses the
> {{System.Diagnostics.Debug.Write(string,string)}} overload passing in the
> loggername as the category parameter.
> It should be possible to omit the category parameter if having the loggername
> as category is not desired.
> Attached is a patch implementing the desired new feature, which would be
> activated by configuration:
> {code:xml}
>
>
>
>
>
>
> {code}
> In my patch, the outputCategory parameter defaults to true, so the behavior
> doesnt change unless the new configuration is used.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (LOG4NET-553) DebugAppender configuration should give the possibility to disable outputting loggerName as category
[
https://issues.apache.org/jira/browse/LOG4NET-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15861461#comment-15861461
]
Dominik Psenner edited comment on LOG4NET-553 at 2/10/17 4:07 PM:
--
Largely agreed, I would further handle the special case of empty category:
{code}
if m_category == null
call Debug.Write(string)
else
category = m_category.Format(loggingEvent)
if string.Empty.Equals(category)
call Debug.Write(string)
else
call Debug.Write(string, category)
{code}
Sorry for the additional roundtrip and thanks for your time! ;-)
was (Author: nachbarslumpi):
Largely agreed, I would further handle the special case of empty category
specially:
{code}
if m_category == null
call Debug.Write(string)
else
category = m_category.Format(loggingEvent)
if string.Empty.Equals(category)
call Debug.Write(string)
else
call Debug.Write(string, category)
{code}
Sorry for the additional roundtrip and thanks for your time! ;-)
> DebugAppender configuration should give the possibility to disable outputting
> loggerName as category
>
>
> Key: LOG4NET-553
> URL: https://issues.apache.org/jira/browse/LOG4NET-553
> Project: Log4net
> Issue Type: New Feature
> Components: Appenders
>Affects Versions: 2.0.7
>Reporter: Jean-Francois Beaulac
> Attachments: log4net-DebugAppenderCategory2.patch,
> log4net-DebugAppenderCategory.patch,
> OutputCategoryParam-DebugAppender.cs.patch
>
>
> The DebugAppender always uses the
> {{System.Diagnostics.Debug.Write(string,string)}} overload passing in the
> loggername as the category parameter.
> It should be possible to omit the category parameter if having the loggername
> as category is not desired.
> Attached is a patch implementing the desired new feature, which would be
> activated by configuration:
> {code:xml}
>
>
>
>
>
>
> {code}
> In my patch, the outputCategory parameter defaults to true, so the behavior
> doesnt change unless the new configuration is used.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (LOG4NET-553) DebugAppender configuration should give the possibility to disable outputting loggerName as category
[
https://issues.apache.org/jira/browse/LOG4NET-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15861461#comment-15861461
]
Dominik Psenner commented on LOG4NET-553:
-
Largely agreed, I would further handle the special case of empty category
specially:
{code}
if m_category == null
call Debug.Write(string)
else
category = m_category.Format(loggingEvent)
if string.Empty.Equals(category)
call Debug.Write(string)
else
call Debug.Write(string, category)
{code}
Sorry for the additional roundtrip and thanks for your time! ;-)
> DebugAppender configuration should give the possibility to disable outputting
> loggerName as category
>
>
> Key: LOG4NET-553
> URL: https://issues.apache.org/jira/browse/LOG4NET-553
> Project: Log4net
> Issue Type: New Feature
> Components: Appenders
>Affects Versions: 2.0.7
>Reporter: Jean-Francois Beaulac
> Attachments: log4net-DebugAppenderCategory2.patch,
> log4net-DebugAppenderCategory.patch,
> OutputCategoryParam-DebugAppender.cs.patch
>
>
> The DebugAppender always uses the
> {{System.Diagnostics.Debug.Write(string,string)}} overload passing in the
> loggername as the category parameter.
> It should be possible to omit the category parameter if having the loggername
> as category is not desired.
> Attached is a patch implementing the desired new feature, which would be
> activated by configuration:
> {code:xml}
>
>
>
>
>
>
> {code}
> In my patch, the outputCategory parameter defaults to true, so the behavior
> doesnt change unless the new configuration is used.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (LOG4NET-553) DebugAppender configuration should give the possibility to disable outputting loggerName as category
[
https://issues.apache.org/jira/browse/LOG4NET-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15859322#comment-15859322
]
Dominik Psenner commented on LOG4NET-553:
-
I just reviewed your patch and it looks good! All these tests give me a good
feeling about your patch. However, there are things that need to be discussed
before we can continue:
1. Are the modifications in the TraceAppender required? The issue is unrelated
to that appender and therefore this patch should not modify it.
2. In the class DebugAppender you have added the line:
System.Diagnostics.Debug.Write(RenderLoggingEvent(loggingEvent),
m_category.Format(loggingEvent));
Should we pipe null into Debug.Write() if m_category happens to be null?
> DebugAppender configuration should give the possibility to disable outputting
> loggerName as category
>
>
> Key: LOG4NET-553
> URL: https://issues.apache.org/jira/browse/LOG4NET-553
> Project: Log4net
> Issue Type: New Feature
> Components: Appenders
>Affects Versions: 2.0.7
>Reporter: Jean-Francois Beaulac
> Attachments: log4net-DebugAppenderCategory.patch,
> OutputCategoryParam-DebugAppender.cs.patch
>
>
> The DebugAppender always uses the
> {{System.Diagnostics.Debug.Write(string,string)}} overload passing in the
> loggername as the category parameter.
> It should be possible to omit the category parameter if having the loggername
> as category is not desired.
> Attached is a patch implementing the desired new feature, which would be
> activated by configuration:
> {code:xml}
>
>
>
>
>
>
> {code}
> In my patch, the outputCategory parameter defaults to true, so the behavior
> doesnt change unless the new configuration is used.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (LOG4NET-553) DebugAppender configuration should give the possibility to disable outputting loggerName as category
[
https://issues.apache.org/jira/browse/LOG4NET-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15858031#comment-15858031
]
Dominik Psenner commented on LOG4NET-553:
-
Would you like to write a patch that implements the outlined proposal?
> DebugAppender configuration should give the possibility to disable outputting
> loggerName as category
>
>
> Key: LOG4NET-553
> URL: https://issues.apache.org/jira/browse/LOG4NET-553
> Project: Log4net
> Issue Type: New Feature
> Components: Appenders
>Affects Versions: 2.0.7
>Reporter: Jean-Francois Beaulac
> Attachments: OutputCategoryParam-DebugAppender.cs.patch
>
>
> The DebugAppender always uses the
> {{System.Diagnostics.Debug.Write(string,string)}} overload passing in the
> loggername as the category parameter.
> It should be possible to omit the category parameter if having the loggername
> as category is not desired.
> Attached is a patch implementing the desired new feature, which would be
> activated by configuration:
> {code:xml}
>
>
>
>
>
>
> {code}
> In my patch, the outputCategory parameter defaults to true, so the behavior
> doesnt change unless the new configuration is used.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (LOG4NET-553) DebugAppender configuration should give the possibility to disable outputting loggerName as category
[
https://issues.apache.org/jira/browse/LOG4NET-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15857585#comment-15857585
]
Dominik Psenner commented on LOG4NET-553:
-
Hi!
Thanks for the patch. While I can see the usecase for the feature, a more
generic approach is in my opinion to be preferred. For instance, a second
layout (i.e. CategoryLayout) property could be introduced in the DebugAppender
that is then used to format the category parameter. Once that API is
introduced, your usecase can then be implemented by specifying a
SecondaryLayout that always returns null. Further, the default CategoryLayout
would return the LoggerName in order to preserve the current behavior. What do
you think?
Cheers
> DebugAppender configuration should give the possibility to disable outputting
> loggerName as category
>
>
> Key: LOG4NET-553
> URL: https://issues.apache.org/jira/browse/LOG4NET-553
> Project: Log4net
> Issue Type: New Feature
> Components: Appenders
>Affects Versions: 2.0.7
>Reporter: Jean-Francois Beaulac
> Attachments: OutputCategoryParam-DebugAppender.cs.patch
>
>
> The DebugAppender always uses the
> {{System.Diagnostics.Debug.Write(string,string)}} overload passing in the
> loggername as the category parameter.
> It should be possible to omit the category parameter if having the loggername
> as category is not desired.
> Attached is a patch implementing the desired new feature, which would be
> activated by configuration:
> {code:xml}
>
>
>
>
>
>
> {code}
> In my patch, the outputCategory parameter defaults to true, so the behavior
> doesnt change unless the new configuration is used.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (LOG4NET-543) ConsoleAppender hangs at WriteFileNative
[ https://issues.apache.org/jira/browse/LOG4NET-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominik Psenner closed LOG4NET-543. --- Resolution: Not A Bug Assignee: Dominik Psenner Thanks for reporting this issue, however there is nothing that the logging framework can do if the underlying implementation of the ConsoleStream misbehaves. Closing therefore as "Not A Bug". Please reopen the issue if you find something that the logging framework can do to resolve this situation. > ConsoleAppender hangs at WriteFileNative > > > Key: LOG4NET-543 > URL: https://issues.apache.org/jira/browse/LOG4NET-543 > Project: Log4net > Issue Type: Bug >Affects Versions: 1.2.13 >Reporter: Yury Skindersky >Assignee: Dominik Psenner > > Not Flagged 291611 Worker Thread Worker Thread > log4net.dll!log4net.Appender.ConsoleAppender.Append Normal > [Managed to Native Transition] > > mscorlib.dll!System.IO.__ConsoleStream.WriteFileNative(Microsoft.Win32.SafeHandles.SafeFileHandle > hFile, byte[] bytes, int offset, int count, bool useFileAPIs) > mscorlib.dll!System.IO.__ConsoleStream.Write(byte[] > buffer, int offset, int count) > mscorlib.dll!System.IO.StreamWriter.Flush(bool > flushStream, bool flushEncoder) > mscorlib.dll!System.IO.StreamWriter.Write(string > value) > > mscorlib.dll!System.IO.TextWriter.SyncTextWriter.Write(string value) > mscorlib.dll!System.Console.Write(string value) > > log4net.dll!log4net.Appender.ConsoleAppender.Append(log4net.Core.LoggingEvent > loggingEvent) > > log4net.dll!log4net.Appender.AppenderSkeleton.DoAppend(log4net.Core.LoggingEvent > loggingEvent) > > log4net.dll!log4net.Util.AppenderAttachedImpl.AppendLoopOnAppenders(log4net.Core.LoggingEvent > loggingEvent) > > log4net.dll!log4net.Repository.Hierarchy.Logger.CallAppenders(log4net.Core.LoggingEvent > loggingEvent) > > log4net.dll!log4net.Repository.Hierarchy.Logger.Log(System.Type > callerStackBoundaryDeclaringType, log4net.Core.Level level, object message, > System.Exception exception) > log4net.dll!log4net.Core.LogImpl.Debug(object > message) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (LOG4NET-411) Release 1.2.13.0 is no longer compatible with .Net 2.0
[ https://issues.apache.org/jira/browse/LOG4NET-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominik Psenner closed LOG4NET-411. --- Resolution: Invalid Assignee: Dominik Psenner Thanks for bringing up this issue, I'm closing it as invalid. As for your question, you'll have to evaluate for yourself if log4net works for your usecase. To find that out, more investigation has to be done than finding an answer for the question "is .net framework 2.0 supported?". > Release 1.2.13.0 is no longer compatible with .Net 2.0 > -- > > Key: LOG4NET-411 > URL: https://issues.apache.org/jira/browse/LOG4NET-411 > Project: Log4net > Issue Type: Bug > Components: Builds >Affects Versions: 1.2.13 >Reporter: Jørn Frode Jensen >Assignee: Dominik Psenner > Labels: build > > According to Reflector output for the 3.5 client profile version of log4net, > there is a reference from log4net.dll to System.Core version 3.5. > Version 1.2.12.0 worked with .Net 2.0, but failed on dynamic methods > ([LOG4NET-393]). This was fixed in 1.2.13.0, but this version now fails with > .Net 2.0. > Is this as designed? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LOG4NET-538) AdoNetAppender to PostgreSQL
[
https://issues.apache.org/jira/browse/LOG4NET-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15754100#comment-15754100
]
Dominik Psenner commented on LOG4NET-538:
-
Has this issue been resolved? It looks like log4net works fine to others using
both a newer and the same version of postgresql. This means that most probably
there's nothing we can do to fix the issue. Therefore I am going to close this
issue after, but not before 7 days from today with resolution "Not
reproducable".
> AdoNetAppender to PostgreSQL
>
>
> Key: LOG4NET-538
> URL: https://issues.apache.org/jira/browse/LOG4NET-538
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 1.2.15
> Environment: C#
>Reporter: Cristian Margescu
> Labels: patch
>
> I am using the AdoNetAppender to log audits to the database. I was using
> until some time the 1.2.13 version with a configuration for MSSQL or
> PostgreSQL which inserted practically data as json strings that will later be
> interpreted by another tool using the following appender configuration.
> EX:
>
>
>
>
>
>value="Npgsql.NpgsqlConnection, Npgsql" />
>value="Server={myServer};Port=5432;Database={database};User
> Id={myuser};Password={mypassword}" />
>
>
>
>
>
>
>
>
>
>
>
> It worked great until I have updated to 1.2.15 and then we have noticed that
> the PosgreSQL appender did not worked any more. After doing some research and
> testing I have narrowed it down to the AdoNetAppender
> that probably has a problem with the parameters because it shows a PG error
> 47203 as column "message" not found.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LOG4NET-538) AdoNetAppender to PostgreSQL
[
https://issues.apache.org/jira/browse/LOG4NET-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15742315#comment-15742315
]
Dominik Psenner commented on LOG4NET-538:
-
Would you kindly investigate if your configuration works with postgresql 9.4.5?
> AdoNetAppender to PostgreSQL
>
>
> Key: LOG4NET-538
> URL: https://issues.apache.org/jira/browse/LOG4NET-538
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 1.2.15
> Environment: C#
>Reporter: Cristian Margescu
> Labels: patch
>
> I am using the AdoNetAppender to log audits to the database. I was using
> until some time the 1.2.13 version with a configuration for MSSQL or
> PostgreSQL which inserted practically data as json strings that will later be
> interpreted by another tool using the following appender configuration.
> EX:
>
>
>
>
>
>value="Npgsql.NpgsqlConnection, Npgsql" />
>value="Server={myServer};Port=5432;Database={database};User
> Id={myuser};Password={mypassword}" />
>
>
>
>
>
>
>
>
>
>
>
> It worked great until I have updated to 1.2.15 and then we have noticed that
> the PosgreSQL appender did not worked any more. After doing some research and
> testing I have narrowed it down to the AdoNetAppender
> that probably has a problem with the parameters because it shows a PG error
> 47203 as column "message" not found.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LOG4NET-538) AdoNetAppender to PostgreSQL
[
https://issues.apache.org/jira/browse/LOG4NET-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15741846#comment-15741846
]
Dominik Psenner commented on LOG4NET-538:
-
> All you need to do is create a database on postgres using the create script
> provided earlier. Define the configuration with the ado net adapter as
> provided and trigger it under root config.
This is a little more work than one might think at first sight. For instance,
we do not have virtual machines ready for every kind of database supported by
Ado.Net. It would be great to have them, all along with specialized tests for
all kinds of databases.
> I have my own adapter so far, so no worries but I am glad to provide all
> needed information if someone wants to test and find the problem
Would you like to write a patch for the AdoNetAppender?
> AdoNetAppender to PostgreSQL
>
>
> Key: LOG4NET-538
> URL: https://issues.apache.org/jira/browse/LOG4NET-538
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 1.2.15
> Environment: C#
>Reporter: Cristian Margescu
> Labels: patch
>
> I am using the AdoNetAppender to log audits to the database. I was using
> until some time the 1.2.13 version with a configuration for MSSQL or
> PostgreSQL which inserted practically data as json strings that will later be
> interpreted by another tool using the following appender configuration.
> EX:
>
>
>
>
>
>value="Npgsql.NpgsqlConnection, Npgsql" />
>value="Server={myServer};Port=5432;Database={database};User
> Id={myuser};Password={mypassword}" />
>
>
>
>
>
>
>
>
>
>
>
> It worked great until I have updated to 1.2.15 and then we have noticed that
> the PosgreSQL appender did not worked any more. After doing some research and
> testing I have narrowed it down to the AdoNetAppender
> that probably has a problem with the parameters because it shows a PG error
> 47203 as column "message" not found.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LOG4NET-538) AdoNetAppender to PostgreSQL
[
https://issues.apache.org/jira/browse/LOG4NET-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15741228#comment-15741228
]
Dominik Psenner commented on LOG4NET-538:
-
I've tried to work out the root cause of the issue. To me it looks like a
configuration/permission/.. issue on the server side of postgres or maybe a
postgres driver issue, shadowed behind adonet. At the moment I have no idea
what we could change in log4net to fix your issue. With the provided
information I am unable to reproduce the issue. You'll have to figure this out
on your own. log4net's internal logging may be of help. Let us know about your
findings.
> AdoNetAppender to PostgreSQL
>
>
> Key: LOG4NET-538
> URL: https://issues.apache.org/jira/browse/LOG4NET-538
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 1.2.15
> Environment: C#
>Reporter: Cristian Margescu
> Labels: patch
>
> I am using the AdoNetAppender to log audits to the database. I was using
> until some time the 1.2.13 version with a configuration for MSSQL or
> PostgreSQL which inserted practically data as json strings that will later be
> interpreted by another tool using the following appender configuration.
> EX:
>
>
>
>
>
>value="Npgsql.NpgsqlConnection, Npgsql" />
>value="Server={myServer};Port=5432;Database={database};User
> Id={myuser};Password={mypassword}" />
>
>
>
>
>
>
>
>
>
>
>
> It worked great until I have updated to 1.2.15 and then we have noticed that
> the PosgreSQL appender did not worked any more. After doing some research and
> testing I have narrowed it down to the AdoNetAppender
> that probably has a problem with the parameters because it shows a PG error
> 47203 as column "message" not found.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LOG4NET-538) AdoNetAppender to PostgreSQL
[
https://issues.apache.org/jira/browse/LOG4NET-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15735238#comment-15735238
]
Dominik Psenner commented on LOG4NET-538:
-
Another thing that I just noticed is that the table name "public.audit"
mentioned in the create script and the table "audit" in the insert statement do
not match.
> AdoNetAppender to PostgreSQL
>
>
> Key: LOG4NET-538
> URL: https://issues.apache.org/jira/browse/LOG4NET-538
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 1.2.15
> Environment: C#
>Reporter: Cristian Margescu
> Labels: patch
>
> I am using the AdoNetAppender to log audits to the database. I was using
> until some time the 1.2.13 version with a configuration for MSSQL or
> PostgreSQL which inserted practically data as json strings that will later be
> interpreted by another tool using the following appender configuration.
> EX:
>
>
>
>
>
>value="Npgsql.NpgsqlConnection, Npgsql" />
>value="Server={myServer};Port=5432;Database={database};User
> Id={myuser};Password={mypassword}" />
>
>
>
>
>
>
>
>
>
>
>
> It worked great until I have updated to 1.2.15 and then we have noticed that
> the PosgreSQL appender did not worked any more. After doing some research and
> testing I have narrowed it down to the AdoNetAppender
> that probably has a problem with the parameters because it shows a PG error
> 47203 as column "message" not found.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LOG4NET-538) AdoNetAppender to PostgreSQL
[
https://issues.apache.org/jira/browse/LOG4NET-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15735054#comment-15735054
]
Dominik Psenner commented on LOG4NET-538:
-
-Does your implementation call AddParameter() for the message parameter in your
ActivateOptions() overload?-
Forget it, this does not make sense. The configuration does not look like the
documentation states:
should probably read as:
and it could be that you need to specify the size of the string column:
> AdoNetAppender to PostgreSQL
>
>
> Key: LOG4NET-538
> URL: https://issues.apache.org/jira/browse/LOG4NET-538
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 1.2.15
> Environment: C#
>Reporter: Cristian Margescu
> Labels: patch
>
> I am using the AdoNetAppender to log audits to the database. I was using
> until some time the 1.2.13 version with a configuration for MSSQL or
> PostgreSQL which inserted practically data as json strings that will later be
> interpreted by another tool using the following appender configuration.
> EX:
>
>
>
>
>
>value="Npgsql.NpgsqlConnection, Npgsql" />
>value="Server={myServer};Port=5432;Database={database};User
> Id={myuser};Password={mypassword}" />
>
>
>
>
>
>
>
>
>
>
>
> It worked great until I have updated to 1.2.15 and then we have noticed that
> the PosgreSQL appender did not worked any more. After doing some research and
> testing I have narrowed it down to the AdoNetAppender
> that probably has a problem with the parameters because it shows a PG error
> 47203 as column "message" not found.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LOG4NET-538) AdoNetAppender to PostgreSQL
[
https://issues.apache.org/jira/browse/LOG4NET-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15735036#comment-15735036
]
Dominik Psenner commented on LOG4NET-538:
-
Does your implementation call AddParameter() for the message parameter in your
ActivateOptions() overload?
> AdoNetAppender to PostgreSQL
>
>
> Key: LOG4NET-538
> URL: https://issues.apache.org/jira/browse/LOG4NET-538
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 1.2.15
> Environment: C#
>Reporter: Cristian Margescu
> Labels: patch
>
> I am using the AdoNetAppender to log audits to the database. I was using
> until some time the 1.2.13 version with a configuration for MSSQL or
> PostgreSQL which inserted practically data as json strings that will later be
> interpreted by another tool using the following appender configuration.
> EX:
>
>
>
>
>
>value="Npgsql.NpgsqlConnection, Npgsql" />
>value="Server={myServer};Port=5432;Database={database};User
> Id={myuser};Password={mypassword}" />
>
>
>
>
>
>
>
>
>
>
>
> It worked great until I have updated to 1.2.15 and then we have noticed that
> the PosgreSQL appender did not worked any more. After doing some research and
> testing I have narrowed it down to the AdoNetAppender
> that probably has a problem with the parameters because it shows a PG error
> 47203 as column "message" not found.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LOG4NET-538) AdoNetAppender to PostgreSQL
[
https://issues.apache.org/jira/browse/LOG4NET-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15734964#comment-15734964
]
Dominik Psenner commented on LOG4NET-538:
-
A quick google search gave me this too:
http://stackoverflow.com/questions/17104837/pgsql-error-code-42703-column-does-not-exist
> AdoNetAppender to PostgreSQL
>
>
> Key: LOG4NET-538
> URL: https://issues.apache.org/jira/browse/LOG4NET-538
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 1.2.15
> Environment: C#
>Reporter: Cristian Margescu
> Labels: patch
>
> I am using the AdoNetAppender to log audits to the database. I was using
> until some time the 1.2.13 version with a configuration for MSSQL or
> PostgreSQL which inserted practically data as json strings that will later be
> interpreted by another tool using the following appender configuration.
> EX:
>
>
>
>
>
>value="Npgsql.NpgsqlConnection, Npgsql" />
>value="Server={myServer};Port=5432;Database={database};User
> Id={myuser};Password={mypassword}" />
>
>
>
>
>
>
>
>
>
>
>
> It worked great until I have updated to 1.2.15 and then we have noticed that
> the PosgreSQL appender did not worked any more. After doing some research and
> testing I have narrowed it down to the AdoNetAppender
> that probably has a problem with the parameters because it shows a PG error
> 47203 as column "message" not found.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LOG4NET-538) AdoNetAppender to PostgreSQL
[
https://issues.apache.org/jira/browse/LOG4NET-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15734959#comment-15734959
]
Dominik Psenner commented on LOG4NET-538:
-
What happens if you write it as follows?
> AdoNetAppender to PostgreSQL
>
>
> Key: LOG4NET-538
> URL: https://issues.apache.org/jira/browse/LOG4NET-538
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 1.2.15
> Environment: C#
>Reporter: Cristian Margescu
> Labels: patch
>
> I am using the AdoNetAppender to log audits to the database. I was using
> until some time the 1.2.13 version with a configuration for MSSQL or
> PostgreSQL which inserted practically data as json strings that will later be
> interpreted by another tool using the following appender configuration.
> EX:
>
>
>
>
>
>value="Npgsql.NpgsqlConnection, Npgsql" />
>value="Server={myServer};Port=5432;Database={database};User
> Id={myuser};Password={mypassword}" />
>
>
>
>
>
>
>
>
>
>
>
> It worked great until I have updated to 1.2.15 and then we have noticed that
> the PosgreSQL appender did not worked any more. After doing some research and
> testing I have narrowed it down to the AdoNetAppender
> that probably has a problem with the parameters because it shows a PG error
> 47203 as column "message" not found.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LOG4NET-538) AdoNetAppender to PostgreSQL
[
https://issues.apache.org/jira/browse/LOG4NET-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15734877#comment-15734877
]
Dominik Psenner commented on LOG4NET-538:
-
I cannot find PG error 47203 mentioned in
https://www.postgresql.org/docs/9.4/static/errcodes-appendix.html , however you
are saying the error message is "column 'message' not found" which indicates
that the table audit has no column message. Would you please verify that?
> AdoNetAppender to PostgreSQL
>
>
> Key: LOG4NET-538
> URL: https://issues.apache.org/jira/browse/LOG4NET-538
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 1.2.15
> Environment: C#
>Reporter: Cristian Margescu
> Labels: patch
>
> I am using the AdoNetAppender to log audits to the database. I was using
> until some time the 1.2.13 version with a configuration for MSSQL or
> PostgreSQL which inserted practically data as json strings that will later be
> interpreted by another tool using the following appender configuration.
> EX:
>
>
>
>
>
>value="Npgsql.NpgsqlConnection, Npgsql" />
>value="Server={myServer};Port=5432;Database={database};User
> Id={myuser};Password={mypassword}" />
>
>
>
>
>
>
>
>
>
>
>
> It worked great until I have updated to 1.2.15 and then we have noticed that
> the PosgreSQL appender did not worked any more. After doing some research and
> testing I have narrowed it down to the AdoNetAppender
> that probably has a problem with the parameters because it shows a PG error
> 47203 as column "message" not found.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LOG4NET-537) Crash on log during AssemblyLoad event
[
https://issues.apache.org/jira/browse/LOG4NET-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15708599#comment-15708599
]
Dominik Psenner commented on LOG4NET-537:
-
Looks like System.Exception.ToString() crashes. The clr is not fully
initialized when you try to log. If thats the case you should be able to
reproduce the issue with a plain invocation to the method above.
I am afraid there is nothing we can do for you.
> Crash on log during AssemblyLoad event
> --
>
> Key: LOG4NET-537
> URL: https://issues.apache.org/jira/browse/LOG4NET-537
> Project: Log4net
> Issue Type: Bug
>Affects Versions: 1.2.15
> Environment: Visual Studio 2013,C#, Dot.Net 4.61
> nuget :
>Reporter: Guillaume Favre
>
> Hello,
> the following code cause the program to crash.
> class Program
> {
> private static readonly ILog Log =
> LogManager.GetLogger(MethodBase.GetCurrentMethod().DeclaringType);
> static void Main(string[] args)
> {
> try
> {
> AppDomain.CurrentDomain.AssemblyLoad +=
> CurrentDomainAssemblyLoad;
> log4net.Config.BasicConfigurator.Configure();
> Exception e = new Exception("Toto");
> throw e;
> }
> catch (Exception e)
> {
> Log.Error("Error ", e);
> }
> }
> private static void CurrentDomainAssemblyLoad(object sender,
> AssemblyLoadEventArgs args)
> {
> Log.Debug("COUCOU");
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (LOG4NET-534) rollingfileappender: INTERNAL ERROR. Append is False but OutputFile already exists
[
https://issues.apache.org/jira/browse/LOG4NET-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominik Psenner closed LOG4NET-534.
---
Resolution: Invalid
Assignee: Dominik Psenner
Closing as invalid. The logging framework cant work around permission issues.
Feel free to reopen the issue if there is something in the logging framework
that could be improved. That can be code changes, documentation, faq additions
or others.
With respect to your issue, I am unable to help you. You could raise this
question on the mailing lists to reach out to a larger audience, hoping that
there is somebody who can help you.
> rollingfileappender: INTERNAL ERROR. Append is False but OutputFile already
> exists
> --
>
> Key: LOG4NET-534
> URL: https://issues.apache.org/jira/browse/LOG4NET-534
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 1.2.15
> Environment: Windows 10
>Reporter: Jay McCormick
>Assignee: Dominik Psenner
> Labels: newbie
>
> Have read about [LOG4NET-118] and [LOG4NET-485] but it looks like neither has
> a resolution. Existing log file is not being rolled, it is being overwritten
> instead.
> Same code and config running on Windows 7, produces the error message in the
> summary. Not sure if UAC is a cause. Log file is written into users
> %LOCALAPPDATA%\TEMP directory. I have read about some "internal" log4net
> logging, but do not know how to activate that.
> The config:
>
>
>
>
> type="log4net.Config.Log4NetConfigurationSectionHandler, log4net"/>
>
>
>
> type="log4net.Appender.RollingFileAppender">
> value="%property{LogFileName}"/>
>
>
>
>
>
> value="%date{ISO8601}%property{messageId}%-5level%message%newline"/>
>
>
>
>
>
>
> type="AsyncForwardingAppenderHotSwap">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> The AsyncBufferingAppender-HotSwap is borrowed from here:
> * Copied from .NET low latency logging. Part 5 - Asynchronous log4net
> solutions
> *
> http://deep-depth.blogspot.com/2014/02/net-low-latency-logging-part-5.html
> (I also tried without the Asynchronous Appender as well)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LOG4NET-535) Add support for macOS unified logging
[ https://issues.apache.org/jira/browse/LOG4NET-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominik Psenner updated LOG4NET-535: Description: LocalSyslogAppender doesn’t work on macOS Sierra 10.12 anymore because it was deprecated by unified logging since iOS 10.0 and replaced macOS Sierra 10.12 New logging in macOS Sierra osx 10.12, unified logging: "Unified logging is available in iOS 10.0 and later, macOS 10.12 and later, tvOS 10.0 and later, and watchOS 3.0 and later, and supersedes ASL (Apple System Logger) and the Syslog APIs. Historically, log messages were written to specific locations on disk, such as /etc/system.log. The unified logging system stores messages in memory and in a data store, rather than writing to text-based log files." https://developer.apple.com/reference/os/1891852-logging was: LocalSyslogAppender doesn’t work on macOS Sierra 10.12 New logging in macOS Sierra osx 10.12, unified logging: "Unified logging is available in iOS 10.0 and later, macOS 10.12 and later, tvOS 10.0 and later, and watchOS 3.0 and later, and supersedes ASL (Apple System Logger) and the Syslog APIs. Historically, log messages were written to specific locations on disk, such as /etc/system.log. The unified logging system stores messages in memory and in a data store, rather than writing to text-based log files." https://developer.apple.com/reference/os/1891852-logging > Add support for macOS unified logging > - > > Key: LOG4NET-535 > URL: https://issues.apache.org/jira/browse/LOG4NET-535 > Project: Log4net > Issue Type: New Feature > Components: Appenders >Affects Versions: 1.2.15, 2.0.6 > Environment: macOS Sierra osx 10.12 and 10.12.1 > HEAD detached at origin/trunk > HEAD is now at db6839f... update release notes for 2.0.6 >Reporter: Mattias Lasu > > LocalSyslogAppender doesn’t work on macOS Sierra 10.12 anymore because it was > deprecated by unified logging since iOS 10.0 and replaced macOS Sierra 10.12 > New logging in macOS Sierra osx 10.12, unified logging: > "Unified logging is available in iOS 10.0 and later, macOS 10.12 and later, > tvOS 10.0 and later, and watchOS 3.0 and later, and supersedes ASL (Apple > System Logger) and the Syslog APIs. Historically, log messages were written > to specific locations on disk, such as /etc/system.log. The unified logging > system stores messages in memory and in a data store, rather than writing to > text-based log files." > https://developer.apple.com/reference/os/1891852-logging -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (LOG4NET-535) Add support for macOS unified logging
[ https://issues.apache.org/jira/browse/LOG4NET-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominik Psenner updated LOG4NET-535: Issue Type: New Feature (was: Bug) > Add support for macOS unified logging > - > > Key: LOG4NET-535 > URL: https://issues.apache.org/jira/browse/LOG4NET-535 > Project: Log4net > Issue Type: New Feature > Components: Appenders >Affects Versions: 1.2.15, 2.0.6 > Environment: macOS Sierra osx 10.12 and 10.12.1 > HEAD detached at origin/trunk > HEAD is now at db6839f... update release notes for 2.0.6 >Reporter: Mattias Lasu > > LocalSyslogAppender doesn’t work on macOS Sierra 10.12 > New logging in macOS Sierra osx 10.12, unified logging: > "Unified logging is available in iOS 10.0 and later, macOS 10.12 and later, > tvOS 10.0 and later, and watchOS 3.0 and later, and supersedes ASL (Apple > System Logger) and the Syslog APIs. Historically, log messages were written > to specific locations on disk, such as /etc/system.log. The unified logging > system stores messages in memory and in a data store, rather than writing to > text-based log files." > https://developer.apple.com/reference/os/1891852-logging -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (LOG4NET-535) Add support for macOS unified logging
[ https://issues.apache.org/jira/browse/LOG4NET-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominik Psenner updated LOG4NET-535: Summary: Add support for macOS unified logging (was: LocalSyslogAppender doesn’t work on macOS Sierra 10.12) > Add support for macOS unified logging > - > > Key: LOG4NET-535 > URL: https://issues.apache.org/jira/browse/LOG4NET-535 > Project: Log4net > Issue Type: Bug > Components: Appenders >Affects Versions: 1.2.15, 2.0.6 > Environment: macOS Sierra osx 10.12 and 10.12.1 > HEAD detached at origin/trunk > HEAD is now at db6839f... update release notes for 2.0.6 >Reporter: Mattias Lasu > > LocalSyslogAppender doesn’t work on macOS Sierra 10.12 > New logging in macOS Sierra osx 10.12, unified logging: > "Unified logging is available in iOS 10.0 and later, macOS 10.12 and later, > tvOS 10.0 and later, and watchOS 3.0 and later, and supersedes ASL (Apple > System Logger) and the Syslog APIs. Historically, log messages were written > to specific locations on disk, such as /etc/system.log. The unified logging > system stores messages in memory and in a data store, rather than writing to > text-based log files." > https://developer.apple.com/reference/os/1891852-logging -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LOG4NET-535) LocalSyslogAppender doesn’t work on macOS Sierra 10.12
[ https://issues.apache.org/jira/browse/LOG4NET-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15692962#comment-15692962 ] Dominik Psenner commented on LOG4NET-535: - So it seems that macOS Sierra 10.12 broke compatibility to all applications that log to syslog and the applications will have to find another way to log. I'm changing this to a feature request. > LocalSyslogAppender doesn’t work on macOS Sierra 10.12 > -- > > Key: LOG4NET-535 > URL: https://issues.apache.org/jira/browse/LOG4NET-535 > Project: Log4net > Issue Type: Bug > Components: Appenders >Affects Versions: 1.2.15, 2.0.6 > Environment: macOS Sierra osx 10.12 and 10.12.1 > HEAD detached at origin/trunk > HEAD is now at db6839f... update release notes for 2.0.6 >Reporter: Mattias Lasu > > LocalSyslogAppender doesn’t work on macOS Sierra 10.12 > New logging in macOS Sierra osx 10.12, unified logging: > "Unified logging is available in iOS 10.0 and later, macOS 10.12 and later, > tvOS 10.0 and later, and watchOS 3.0 and later, and supersedes ASL (Apple > System Logger) and the Syslog APIs. Historically, log messages were written > to specific locations on disk, such as /etc/system.log. The unified logging > system stores messages in memory and in a data store, rather than writing to > text-based log files." > https://developer.apple.com/reference/os/1891852-logging -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LOG4NET-534) rollingfileappender: INTERNAL ERROR. Append is False but OutputFile already exists
[
https://issues.apache.org/jira/browse/LOG4NET-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15692787#comment-15692787
]
Dominik Psenner commented on LOG4NET-534:
-
https://logging.apache.org/log4net/release/faq.html#internalDebug
LOG4NET-118 has a patch attached that was never tested in a scenario where the
issue appears, but it could solve your issue and identify this issue as a
duplicate of LOG4NET-118.
> rollingfileappender: INTERNAL ERROR. Append is False but OutputFile already
> exists
> --
>
> Key: LOG4NET-534
> URL: https://issues.apache.org/jira/browse/LOG4NET-534
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 1.2.15
> Environment: Windows 10
>Reporter: Jay McCormick
> Labels: newbie
>
> Have read about [LOG4NET-118] and [LOG4NET-485] but it looks like neither has
> a resolution. Existing log file is not being rolled, it is being overwritten
> instead.
> Same code and config running on Windows 7, produces the error message in the
> summary. Not sure if UAC is a cause. Log file is written into users
> %LOCALAPPDATA%\TEMP directory. I have read about some "internal" log4net
> logging, but do not know how to activate that.
> The config:
>
>
>
>
> type="log4net.Config.Log4NetConfigurationSectionHandler, log4net"/>
>
>
>
> type="log4net.Appender.RollingFileAppender">
> value="%property{LogFileName}"/>
>
>
>
>
>
> value="%date{ISO8601}%property{messageId}%-5level%message%newline"/>
>
>
>
>
>
>
> type="AsyncForwardingAppenderHotSwap">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> The AsyncBufferingAppender-HotSwap is borrowed from here:
> * Copied from .NET low latency logging. Part 5 - Asynchronous log4net
> solutions
> *
> http://deep-depth.blogspot.com/2014/02/net-low-latency-logging-part-5.html
> (I also tried without the Asynchronous Appender as well)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LOG4NET-535) LocalSyslogAppender doesn’t work on macOS Sierra 10.12
[ https://issues.apache.org/jira/browse/LOG4NET-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15692561#comment-15692561 ] Dominik Psenner commented on LOG4NET-535: - What does it mean "LocalSyslogAppender doesn't work"? What do you expect to happen under which preconditions? Please note that log4net at the moment has two active developers and at least 50% of it do not have a macOS at hand. Therefore it is about to impossible to test/fix anything without access to the mac ecosystem. I'm afraid you're on your own with this. However, patches are greatly welcome! > LocalSyslogAppender doesn’t work on macOS Sierra 10.12 > -- > > Key: LOG4NET-535 > URL: https://issues.apache.org/jira/browse/LOG4NET-535 > Project: Log4net > Issue Type: Bug > Components: Appenders >Affects Versions: 1.2.15, 2.0.6 > Environment: macOS Sierra osx 10.12 and 10.12.1 > HEAD detached at origin/trunk > HEAD is now at db6839f... update release notes for 2.0.6 >Reporter: Mattias Lasu > > LocalSyslogAppender doesn’t work on macOS Sierra 10.12 > New logging in macOS Sierra osx 10.12, unified logging: > "Unified logging is available in iOS 10.0 and later, macOS 10.12 and later, > tvOS 10.0 and later, and watchOS 3.0 and later, and supersedes ASL (Apple > System Logger) and the Syslog APIs. Historically, log messages were written > to specific locations on disk, such as /etc/system.log. The unified logging > system stores messages in memory and in a data store, rather than writing to > text-based log files." > https://developer.apple.com/reference/os/1891852-logging -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LOG4NET-533) Log4Net version 1.2.15.0 uses much more CPU than 1.2.11.0
[
https://issues.apache.org/jira/browse/LOG4NET-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15690236#comment-15690236
]
Dominik Psenner commented on LOG4NET-533:
-
I just noticed that there is a patch attached to LOG4NET-429. You could try
that patch and see if it improves the performance for your usecase.
> Log4Net version 1.2.15.0 uses much more CPU than 1.2.11.0
> -
>
> Key: LOG4NET-533
> URL: https://issues.apache.org/jira/browse/LOG4NET-533
> Project: Log4net
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.2.15
>Reporter: Ronald Putz
>Assignee: Dominik Psenner
>Priority: Blocker
> Fix For: 1.2 Maintenance Release
>
> Attachments: Release_1_2_15.zip
>
>
> We switched to the version 1.2.15 in our production system and figured out a
> general increase. After a long analysis we have figured out that log4net uses
> more cpu compared to the version 1.2.11.0
> config:
>
> type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
>
>
>
>
>
>
>
> type="log4net.Appender.RollingFileAppender">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> C# code:
> static void Main(string[] args)
> {
> log4net.Config.XmlConfigurator.Configure();
> for (int i = 0; i < 10; i++)
> {
> Thread worker = new Thread(() =>
> {
> while (true)
> {
> Log.Debug(" This is the
> debug message!");
> Log.Error(" This is the
> error message!");
> Log.Info(" This is the
> info message!");
> Log.Fatal(" This is the
> fatal message!");
> Log.Warn(" This is the
> warning message!");
> Thread.Sleep(1000);
> }
> });
> worker.IsBackground = true;
> worker.Start();
> }
> for (int i = 0; i < 60; i++)
> {
> Thread.Sleep(1000);
> }
> return;
> We had to return to the old version of the log4net dll.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LOG4NET-533) Log4Net version 1.2.15.0 uses much more CPU than 1.2.11.0
[
https://issues.apache.org/jira/browse/LOG4NET-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15690230#comment-15690230
]
Dominik Psenner commented on LOG4NET-533:
-
Thanks, I have run your sample applications with my performance profiler. At
first glance log4net 1.2.15 consumes more cpu cycles when rendering log events,
yielding a speedup of 0.45. That means that 1.2.11 was able to render about 2.2
times as many log events as 1.2.15 is able to in the same amount of time.
Looking at the call tree there is a significant change to be observed. With
1.2.11 the MethodLocationPatternConverter used to consume the most cpu cycles
whereas 1.2.15 shows the PropertyPatternConverter as top cpu consumer. The
PropertyPatternConsumer itself spends most of the time with
LoggingEvent.CreateCompositeProperties() which in turn looks up the UserName by
calling WindowsIdentity.get_Name(). With this information I was able to bisect
it to svn revision 1511303 which is linked to LOG4NET-205, which again is
linked as a breaker for LOG4NET-429.
This all boils down to the fact that this issue is a duplicate of LOG4NET-429.
As a workaround, you could remove property{context} from the patternlayout.
> Log4Net version 1.2.15.0 uses much more CPU than 1.2.11.0
> -
>
> Key: LOG4NET-533
> URL: https://issues.apache.org/jira/browse/LOG4NET-533
> Project: Log4net
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.2.15
>Reporter: Ronald Putz
>Priority: Blocker
> Fix For: 1.2 Maintenance Release
>
> Attachments: Release_1_2_15.zip
>
>
> We switched to the version 1.2.15 in our production system and figured out a
> general increase. After a long analysis we have figured out that log4net uses
> more cpu compared to the version 1.2.11.0
> config:
>
> type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
>
>
>
>
>
>
>
> type="log4net.Appender.RollingFileAppender">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> C# code:
> static void Main(string[] args)
> {
> log4net.Config.XmlConfigurator.Configure();
> for (int i = 0; i < 10; i++)
> {
> Thread worker = new Thread(() =>
> {
> while (true)
> {
> Log.Debug(" This is the
> debug message!");
> Log.Error(" This is the
> error message!");
> Log.Info(" This is the
> info message!");
> Log.Fatal(" This is the
> fatal message!");
> Log.Warn(" This is the
> warning message!");
> Thread.Sleep(1000);
> }
> });
> worker.IsBackground = true;
> worker.Start();
> }
> for (int i = 0; i < 60; i++)
> {
> Thread.Sleep(1000);
> }
> return;
> We had to return to the old version of the log4net dll.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (LOG4NET-533) Log4Net version 1.2.15.0 uses much more CPU than 1.2.11.0
[
https://issues.apache.org/jira/browse/LOG4NET-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominik Psenner closed LOG4NET-533.
---
Resolution: Duplicate
Assignee: Dominik Psenner
Marked as duplicate and closing issue.
> Log4Net version 1.2.15.0 uses much more CPU than 1.2.11.0
> -
>
> Key: LOG4NET-533
> URL: https://issues.apache.org/jira/browse/LOG4NET-533
> Project: Log4net
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.2.15
>Reporter: Ronald Putz
>Assignee: Dominik Psenner
>Priority: Blocker
> Fix For: 1.2 Maintenance Release
>
> Attachments: Release_1_2_15.zip
>
>
> We switched to the version 1.2.15 in our production system and figured out a
> general increase. After a long analysis we have figured out that log4net uses
> more cpu compared to the version 1.2.11.0
> config:
>
> type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
>
>
>
>
>
>
>
> type="log4net.Appender.RollingFileAppender">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> C# code:
> static void Main(string[] args)
> {
> log4net.Config.XmlConfigurator.Configure();
> for (int i = 0; i < 10; i++)
> {
> Thread worker = new Thread(() =>
> {
> while (true)
> {
> Log.Debug(" This is the
> debug message!");
> Log.Error(" This is the
> error message!");
> Log.Info(" This is the
> info message!");
> Log.Fatal(" This is the
> fatal message!");
> Log.Warn(" This is the
> warning message!");
> Thread.Sleep(1000);
> }
> });
> worker.IsBackground = true;
> worker.Start();
> }
> for (int i = 0; i < 60; i++)
> {
> Thread.Sleep(1000);
> }
> return;
> We had to return to the old version of the log4net dll.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LOG4NET-533) Log4Net version 1.2.15.0 uses much more CPU than 1.2.11.0
[
https://issues.apache.org/jira/browse/LOG4NET-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15687194#comment-15687194
]
Dominik Psenner commented on LOG4NET-533:
-
You should be able to attach files to this issue. Would you mind to create a
solution with two console applications that do the same but only differ in the
log4net assembly?
> Log4Net version 1.2.15.0 uses much more CPU than 1.2.11.0
> -
>
> Key: LOG4NET-533
> URL: https://issues.apache.org/jira/browse/LOG4NET-533
> Project: Log4net
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.2.15
>Reporter: Ronald Putz
>Priority: Blocker
> Fix For: 1.2 Maintenance Release
>
>
> We switched to the version 1.2.15 in our production system and figured out a
> general increase. After a long analysis we have figured out that log4net uses
> more cpu compared to the version 1.2.11.0
> config:
>
> type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
>
>
>
>
>
>
>
> type="log4net.Appender.RollingFileAppender">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> C# code:
> static void Main(string[] args)
> {
> log4net.Config.XmlConfigurator.Configure();
> for (int i = 0; i < 10; i++)
> {
> Thread worker = new Thread(() =>
> {
> while (true)
> {
> Log.Debug(" This is the
> debug message!");
> Log.Error(" This is the
> error message!");
> Log.Info(" This is the
> info message!");
> Log.Fatal(" This is the
> fatal message!");
> Log.Warn(" This is the
> warning message!");
> Thread.Sleep(1000);
> }
> });
> worker.IsBackground = true;
> worker.Start();
> }
> for (int i = 0; i < 60; i++)
> {
> Thread.Sleep(1000);
> }
> return;
> We had to return to the old version of the log4net dll.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (LOG4NET-531) AdoNetAppender crashes application if BeginDbTransaction failed
[
https://issues.apache.org/jira/browse/LOG4NET-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominik Psenner closed LOG4NET-531.
---
Resolution: Invalid
Closed for good.
> AdoNetAppender crashes application if BeginDbTransaction failed
> ---
>
> Key: LOG4NET-531
> URL: https://issues.apache.org/jira/browse/LOG4NET-531
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 1.2.15
> Environment: Windows Server 2012 R2 Datacenter, SQL Azure, Windows
> Service
>Reporter: Vladimir Vedeneev
>Assignee: Dominik Psenner
>Priority: Critical
>
> AdoNetAppender crashed the process due to failed BeginDbTransaction:
> {noformat}
> Framework Version: v4.0.30319
> Description: The process was terminated due to an unhandled exception.
> Exception Info: System.Data.SqlClient.SqlException
>at
> System.Data.SqlClient.SqlConnection.OnError(System.Data.SqlClient.SqlException,
> Boolean, System.Action`1)
>at
> System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(System.Data.SqlClient.TdsParserStateObject,
> Boolean, Boolean)
>at
> System.Data.SqlClient.TdsParserStateObject.SNIWritePacket(System.Data.SqlClient.SNIHandle,
> System.Data.SqlClient.SNIPacket, UInt32 ByRef, Boolean, Boolean)
>at System.Data.SqlClient.TdsParserStateObject.WriteSni(Boolean)
>at System.Data.SqlClient.TdsParserStateObject.WritePacket(Byte, Boolean)
>at
> System.Data.SqlClient.TdsParser.TdsExecuteTransactionManagerRequest(Byte[],
> TransactionManagerRequestType, System.String,
> TransactionManagerIsolationLevel, Int32,
> System.Data.SqlClient.SqlInternalTransaction,
> System.Data.SqlClient.TdsParserStateObject, Boolean)
>at
> System.Data.SqlClient.SqlInternalConnectionTds.ExecuteTransactionYukon(TransactionRequest,
> System.String, System.Data.IsolationLevel,
> System.Data.SqlClient.SqlInternalTransaction, Boolean)
>at
> System.Data.SqlClient.SqlInternalConnection.BeginSqlTransaction(System.Data.IsolationLevel,
> System.String, Boolean)
>at
> System.Data.SqlClient.SqlConnection.BeginTransaction(System.Data.IsolationLevel,
> System.String)
>at
> System.Data.SqlClient.SqlConnection.BeginDbTransaction(System.Data.IsolationLevel)
>at log4net.Appender.AdoNetAppender.SendBuffer(log4net.Core.LoggingEvent[])
>at
> log4net.Appender.BufferingAppenderSkeleton.Append(log4net.Core.LoggingEvent)
>at
>at
> System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext,
> System.Threading.ContextCallback, System.Object, Boolean)
>at
> System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext,
> System.Threading.ContextCallback, System.Object, Boolean)
>at
> System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext,
> System.Threading.ContextCallback, System.Object)
>at System.Threading.ThreadHelper.ThreadStart()
> {noformat}
> I believe AdoNetAppender will crash in the same way, but we use it a bit
> customized.
> We have custom appender inherited from AdoNetAppender, which runs in separate
> thread and uses Queue to accumulate log events, so that database logging
> works asynchronously. It uses "base.Append(..)" to log events from queue. We
> use SQL Azure as database, which as cloud solution is not 100% available.
> In rare cases appender crashes the app domain on "BeginDbTransaction" line,
> as it is not covered with try / catch block.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (LOG4NET-531) AdoNetAppender crashes application if BeginDbTransaction failed
[
https://issues.apache.org/jira/browse/LOG4NET-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominik Psenner reopened LOG4NET-531:
-
Gotta fix a typo in my comment, sorry for the noise.
> AdoNetAppender crashes application if BeginDbTransaction failed
> ---
>
> Key: LOG4NET-531
> URL: https://issues.apache.org/jira/browse/LOG4NET-531
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 1.2.15
> Environment: Windows Server 2012 R2 Datacenter, SQL Azure, Windows
> Service
>Reporter: Vladimir Vedeneev
>Assignee: Dominik Psenner
>Priority: Critical
>
> AdoNetAppender crashed the process due to failed BeginDbTransaction:
> {noformat}
> Framework Version: v4.0.30319
> Description: The process was terminated due to an unhandled exception.
> Exception Info: System.Data.SqlClient.SqlException
>at
> System.Data.SqlClient.SqlConnection.OnError(System.Data.SqlClient.SqlException,
> Boolean, System.Action`1)
>at
> System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(System.Data.SqlClient.TdsParserStateObject,
> Boolean, Boolean)
>at
> System.Data.SqlClient.TdsParserStateObject.SNIWritePacket(System.Data.SqlClient.SNIHandle,
> System.Data.SqlClient.SNIPacket, UInt32 ByRef, Boolean, Boolean)
>at System.Data.SqlClient.TdsParserStateObject.WriteSni(Boolean)
>at System.Data.SqlClient.TdsParserStateObject.WritePacket(Byte, Boolean)
>at
> System.Data.SqlClient.TdsParser.TdsExecuteTransactionManagerRequest(Byte[],
> TransactionManagerRequestType, System.String,
> TransactionManagerIsolationLevel, Int32,
> System.Data.SqlClient.SqlInternalTransaction,
> System.Data.SqlClient.TdsParserStateObject, Boolean)
>at
> System.Data.SqlClient.SqlInternalConnectionTds.ExecuteTransactionYukon(TransactionRequest,
> System.String, System.Data.IsolationLevel,
> System.Data.SqlClient.SqlInternalTransaction, Boolean)
>at
> System.Data.SqlClient.SqlInternalConnection.BeginSqlTransaction(System.Data.IsolationLevel,
> System.String, Boolean)
>at
> System.Data.SqlClient.SqlConnection.BeginTransaction(System.Data.IsolationLevel,
> System.String)
>at
> System.Data.SqlClient.SqlConnection.BeginDbTransaction(System.Data.IsolationLevel)
>at log4net.Appender.AdoNetAppender.SendBuffer(log4net.Core.LoggingEvent[])
>at
> log4net.Appender.BufferingAppenderSkeleton.Append(log4net.Core.LoggingEvent)
>at
>at
> System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext,
> System.Threading.ContextCallback, System.Object, Boolean)
>at
> System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext,
> System.Threading.ContextCallback, System.Object, Boolean)
>at
> System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext,
> System.Threading.ContextCallback, System.Object)
>at System.Threading.ThreadHelper.ThreadStart()
> {noformat}
> I believe AdoNetAppender will crash in the same way, but we use it a bit
> customized.
> We have custom appender inherited from AdoNetAppender, which runs in separate
> thread and uses Queue to accumulate log events, so that database logging
> works asynchronously. It uses "base.Append(..)" to log events from queue. We
> use SQL Azure as database, which as cloud solution is not 100% available.
> In rare cases appender crashes the app domain on "BeginDbTransaction" line,
> as it is not covered with try / catch block.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (LOG4NET-531) AdoNetAppender crashes application if BeginDbTransaction failed
[
https://issues.apache.org/jira/browse/LOG4NET-531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15650843#comment-15650843
]
Dominik Psenner edited comment on LOG4NET-531 at 11/9/16 2:43 PM:
--
Happy to help and closing as invalid.
Custom appender implementations have to handle exceptions if they are
implemented in such a way that they cannot leak exceptions to the calling
application. Feel free to join the dev list, it is the better place to discuss
similar issues.
was (Author: nachbarslumpi):
Happy to help and closing as invalid.
Custom appender implementations have to handle exceptions if they are
implemented in such a way that they can leak exceptions to the calling
application. Feel free to join the dev list, it is the better place to discuss
similar issues.
> AdoNetAppender crashes application if BeginDbTransaction failed
> ---
>
> Key: LOG4NET-531
> URL: https://issues.apache.org/jira/browse/LOG4NET-531
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 1.2.15
> Environment: Windows Server 2012 R2 Datacenter, SQL Azure, Windows
> Service
>Reporter: Vladimir Vedeneev
>Assignee: Dominik Psenner
>Priority: Critical
>
> AdoNetAppender crashed the process due to failed BeginDbTransaction:
> {noformat}
> Framework Version: v4.0.30319
> Description: The process was terminated due to an unhandled exception.
> Exception Info: System.Data.SqlClient.SqlException
>at
> System.Data.SqlClient.SqlConnection.OnError(System.Data.SqlClient.SqlException,
> Boolean, System.Action`1)
>at
> System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(System.Data.SqlClient.TdsParserStateObject,
> Boolean, Boolean)
>at
> System.Data.SqlClient.TdsParserStateObject.SNIWritePacket(System.Data.SqlClient.SNIHandle,
> System.Data.SqlClient.SNIPacket, UInt32 ByRef, Boolean, Boolean)
>at System.Data.SqlClient.TdsParserStateObject.WriteSni(Boolean)
>at System.Data.SqlClient.TdsParserStateObject.WritePacket(Byte, Boolean)
>at
> System.Data.SqlClient.TdsParser.TdsExecuteTransactionManagerRequest(Byte[],
> TransactionManagerRequestType, System.String,
> TransactionManagerIsolationLevel, Int32,
> System.Data.SqlClient.SqlInternalTransaction,
> System.Data.SqlClient.TdsParserStateObject, Boolean)
>at
> System.Data.SqlClient.SqlInternalConnectionTds.ExecuteTransactionYukon(TransactionRequest,
> System.String, System.Data.IsolationLevel,
> System.Data.SqlClient.SqlInternalTransaction, Boolean)
>at
> System.Data.SqlClient.SqlInternalConnection.BeginSqlTransaction(System.Data.IsolationLevel,
> System.String, Boolean)
>at
> System.Data.SqlClient.SqlConnection.BeginTransaction(System.Data.IsolationLevel,
> System.String)
>at
> System.Data.SqlClient.SqlConnection.BeginDbTransaction(System.Data.IsolationLevel)
>at log4net.Appender.AdoNetAppender.SendBuffer(log4net.Core.LoggingEvent[])
>at
> log4net.Appender.BufferingAppenderSkeleton.Append(log4net.Core.LoggingEvent)
>at
>at
> System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext,
> System.Threading.ContextCallback, System.Object, Boolean)
>at
> System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext,
> System.Threading.ContextCallback, System.Object, Boolean)
>at
> System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext,
> System.Threading.ContextCallback, System.Object)
>at System.Threading.ThreadHelper.ThreadStart()
> {noformat}
> I believe AdoNetAppender will crash in the same way, but we use it a bit
> customized.
> We have custom appender inherited from AdoNetAppender, which runs in separate
> thread and uses Queue to accumulate log events, so that database logging
> works asynchronously. It uses "base.Append(..)" to log events from queue. We
> use SQL Azure as database, which as cloud solution is not 100% available.
> In rare cases appender crashes the app domain on "BeginDbTransaction" line,
> as it is not covered with try / catch block.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (LOG4NET-531) AdoNetAppender crashes application if BeginDbTransaction failed
[
https://issues.apache.org/jira/browse/LOG4NET-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominik Psenner closed LOG4NET-531.
---
Resolution: Invalid
Assignee: Dominik Psenner
Happy to help and closing as invalid.
Custom appender implementations have to handle exceptions if they are
implemented in such a way that they can leak exceptions to the calling
application. Feel free to join the dev list, it is the better place to discuss
similar issues.
> AdoNetAppender crashes application if BeginDbTransaction failed
> ---
>
> Key: LOG4NET-531
> URL: https://issues.apache.org/jira/browse/LOG4NET-531
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 1.2.15
> Environment: Windows Server 2012 R2 Datacenter, SQL Azure, Windows
> Service
>Reporter: Vladimir Vedeneev
>Assignee: Dominik Psenner
>Priority: Critical
>
> AdoNetAppender crashed the process due to failed BeginDbTransaction:
> {noformat}
> Framework Version: v4.0.30319
> Description: The process was terminated due to an unhandled exception.
> Exception Info: System.Data.SqlClient.SqlException
>at
> System.Data.SqlClient.SqlConnection.OnError(System.Data.SqlClient.SqlException,
> Boolean, System.Action`1)
>at
> System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(System.Data.SqlClient.TdsParserStateObject,
> Boolean, Boolean)
>at
> System.Data.SqlClient.TdsParserStateObject.SNIWritePacket(System.Data.SqlClient.SNIHandle,
> System.Data.SqlClient.SNIPacket, UInt32 ByRef, Boolean, Boolean)
>at System.Data.SqlClient.TdsParserStateObject.WriteSni(Boolean)
>at System.Data.SqlClient.TdsParserStateObject.WritePacket(Byte, Boolean)
>at
> System.Data.SqlClient.TdsParser.TdsExecuteTransactionManagerRequest(Byte[],
> TransactionManagerRequestType, System.String,
> TransactionManagerIsolationLevel, Int32,
> System.Data.SqlClient.SqlInternalTransaction,
> System.Data.SqlClient.TdsParserStateObject, Boolean)
>at
> System.Data.SqlClient.SqlInternalConnectionTds.ExecuteTransactionYukon(TransactionRequest,
> System.String, System.Data.IsolationLevel,
> System.Data.SqlClient.SqlInternalTransaction, Boolean)
>at
> System.Data.SqlClient.SqlInternalConnection.BeginSqlTransaction(System.Data.IsolationLevel,
> System.String, Boolean)
>at
> System.Data.SqlClient.SqlConnection.BeginTransaction(System.Data.IsolationLevel,
> System.String)
>at
> System.Data.SqlClient.SqlConnection.BeginDbTransaction(System.Data.IsolationLevel)
>at log4net.Appender.AdoNetAppender.SendBuffer(log4net.Core.LoggingEvent[])
>at
> log4net.Appender.BufferingAppenderSkeleton.Append(log4net.Core.LoggingEvent)
>at
>at
> System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext,
> System.Threading.ContextCallback, System.Object, Boolean)
>at
> System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext,
> System.Threading.ContextCallback, System.Object, Boolean)
>at
> System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext,
> System.Threading.ContextCallback, System.Object)
>at System.Threading.ThreadHelper.ThreadStart()
> {noformat}
> I believe AdoNetAppender will crash in the same way, but we use it a bit
> customized.
> We have custom appender inherited from AdoNetAppender, which runs in separate
> thread and uses Queue to accumulate log events, so that database logging
> works asynchronously. It uses "base.Append(..)" to log events from queue. We
> use SQL Azure as database, which as cloud solution is not 100% available.
> In rare cases appender crashes the app domain on "BeginDbTransaction" line,
> as it is not covered with try / catch block.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (LOG4NET-531) AdoNetAppender crashes application if BeginDbTransaction failed
[
https://issues.apache.org/jira/browse/LOG4NET-531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15650800#comment-15650800
]
Dominik Psenner edited comment on LOG4NET-531 at 11/9/16 12:41 PM:
---
The base AppenderSkeleton class implements the DoAppend(LoggingEvent) method by
calling abstract Append() methods and catching exceptions thrown by inherited
implementations. Since you directly invoke Append() and not DoAppend() you
receive exceptions in your custom appender and have to handle them in your
custom appender implementation unless you invoke DoAppend() instead of
Append(). Calling DoAppend() may be completely wrong in your case, though
because it would make your appender fully recursive. So the actual issue arises
from your custom appender implementation that starts a non-daemon thread.
Non-daemon threads have the property to crash the application if they fail.
Thus the only thing you can do is to handle exceptions in your custom appender
implementation and prevent exceptions from reaching the thread boundary.
was (Author: nachbarslumpi):
The base AppenderSkeleton class implements the DoAppend(LoggingEvent) method by
calling abstract Append() methods and catching exceptions thrown by inherited
implementations. Since you directly invoke Append() and not DoAppend() you
receive exceptions in your custom appender and have to handle them in your
custom appender implementation unless you invoke DoAppend() instead of Append().
> AdoNetAppender crashes application if BeginDbTransaction failed
> ---
>
> Key: LOG4NET-531
> URL: https://issues.apache.org/jira/browse/LOG4NET-531
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 1.2.15
> Environment: Windows Server 2012 R2 Datacenter, SQL Azure, Windows
> Service
>Reporter: Vladimir Vedeneev
>Priority: Critical
>
> AdoNetAppender crashed the process due to failed BeginDbTransaction:
> {noformat}
> Framework Version: v4.0.30319
> Description: The process was terminated due to an unhandled exception.
> Exception Info: System.Data.SqlClient.SqlException
>at
> System.Data.SqlClient.SqlConnection.OnError(System.Data.SqlClient.SqlException,
> Boolean, System.Action`1)
>at
> System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(System.Data.SqlClient.TdsParserStateObject,
> Boolean, Boolean)
>at
> System.Data.SqlClient.TdsParserStateObject.SNIWritePacket(System.Data.SqlClient.SNIHandle,
> System.Data.SqlClient.SNIPacket, UInt32 ByRef, Boolean, Boolean)
>at System.Data.SqlClient.TdsParserStateObject.WriteSni(Boolean)
>at System.Data.SqlClient.TdsParserStateObject.WritePacket(Byte, Boolean)
>at
> System.Data.SqlClient.TdsParser.TdsExecuteTransactionManagerRequest(Byte[],
> TransactionManagerRequestType, System.String,
> TransactionManagerIsolationLevel, Int32,
> System.Data.SqlClient.SqlInternalTransaction,
> System.Data.SqlClient.TdsParserStateObject, Boolean)
>at
> System.Data.SqlClient.SqlInternalConnectionTds.ExecuteTransactionYukon(TransactionRequest,
> System.String, System.Data.IsolationLevel,
> System.Data.SqlClient.SqlInternalTransaction, Boolean)
>at
> System.Data.SqlClient.SqlInternalConnection.BeginSqlTransaction(System.Data.IsolationLevel,
> System.String, Boolean)
>at
> System.Data.SqlClient.SqlConnection.BeginTransaction(System.Data.IsolationLevel,
> System.String)
>at
> System.Data.SqlClient.SqlConnection.BeginDbTransaction(System.Data.IsolationLevel)
>at log4net.Appender.AdoNetAppender.SendBuffer(log4net.Core.LoggingEvent[])
>at
> log4net.Appender.BufferingAppenderSkeleton.Append(log4net.Core.LoggingEvent)
>at
>at
> System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext,
> System.Threading.ContextCallback, System.Object, Boolean)
>at
> System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext,
> System.Threading.ContextCallback, System.Object, Boolean)
>at
> System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext,
> System.Threading.ContextCallback, System.Object)
>at System.Threading.ThreadHelper.ThreadStart()
> {noformat}
> I believe AdoNetAppender will crash in the same way, but we use it a bit
> customized.
> We have custom appender inherited from AdoNetAppender, which runs in separate
> thread and uses Queue to accumulate log events, so that database logging
> works asynchronously. It uses "base.Append(..)" to log events from queue. We
> use SQL Azure as database, which as cloud solution is not 100% available.
> In rare cases appender crashes the app domain on "BeginDbTransaction" line,
> as it is not covered with try / catch block.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LOG4NET-531) AdoNetAppender crashes application if BeginDbTransaction failed
[
https://issues.apache.org/jira/browse/LOG4NET-531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15650800#comment-15650800
]
Dominik Psenner commented on LOG4NET-531:
-
The base AppenderSkeleton class implements the DoAppend(LoggingEvent) method by
calling abstract Append() methods and catching exceptions thrown by inherited
implementations. Since you directly invoke Append() and not DoAppend() you
receive exceptions in your custom appender and have to handle them in your
custom appender implementation unless you invoke DoAppend() instead of Append().
> AdoNetAppender crashes application if BeginDbTransaction failed
> ---
>
> Key: LOG4NET-531
> URL: https://issues.apache.org/jira/browse/LOG4NET-531
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 1.2.15
> Environment: Windows Server 2012 R2 Datacenter, SQL Azure, Windows
> Service
>Reporter: Vladimir Vedeneev
>Priority: Critical
>
> AdoNetAppender crashed the process due to failed BeginDbTransaction:
> {noformat}
> Framework Version: v4.0.30319
> Description: The process was terminated due to an unhandled exception.
> Exception Info: System.Data.SqlClient.SqlException
>at
> System.Data.SqlClient.SqlConnection.OnError(System.Data.SqlClient.SqlException,
> Boolean, System.Action`1)
>at
> System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(System.Data.SqlClient.TdsParserStateObject,
> Boolean, Boolean)
>at
> System.Data.SqlClient.TdsParserStateObject.SNIWritePacket(System.Data.SqlClient.SNIHandle,
> System.Data.SqlClient.SNIPacket, UInt32 ByRef, Boolean, Boolean)
>at System.Data.SqlClient.TdsParserStateObject.WriteSni(Boolean)
>at System.Data.SqlClient.TdsParserStateObject.WritePacket(Byte, Boolean)
>at
> System.Data.SqlClient.TdsParser.TdsExecuteTransactionManagerRequest(Byte[],
> TransactionManagerRequestType, System.String,
> TransactionManagerIsolationLevel, Int32,
> System.Data.SqlClient.SqlInternalTransaction,
> System.Data.SqlClient.TdsParserStateObject, Boolean)
>at
> System.Data.SqlClient.SqlInternalConnectionTds.ExecuteTransactionYukon(TransactionRequest,
> System.String, System.Data.IsolationLevel,
> System.Data.SqlClient.SqlInternalTransaction, Boolean)
>at
> System.Data.SqlClient.SqlInternalConnection.BeginSqlTransaction(System.Data.IsolationLevel,
> System.String, Boolean)
>at
> System.Data.SqlClient.SqlConnection.BeginTransaction(System.Data.IsolationLevel,
> System.String)
>at
> System.Data.SqlClient.SqlConnection.BeginDbTransaction(System.Data.IsolationLevel)
>at log4net.Appender.AdoNetAppender.SendBuffer(log4net.Core.LoggingEvent[])
>at
> log4net.Appender.BufferingAppenderSkeleton.Append(log4net.Core.LoggingEvent)
>at
>at
> System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext,
> System.Threading.ContextCallback, System.Object, Boolean)
>at
> System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext,
> System.Threading.ContextCallback, System.Object, Boolean)
>at
> System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext,
> System.Threading.ContextCallback, System.Object)
>at System.Threading.ThreadHelper.ThreadStart()
> {noformat}
> I believe AdoNetAppender will crash in the same way, but we use it a bit
> customized.
> We have custom appender inherited from AdoNetAppender, which runs in separate
> thread and uses Queue to accumulate log events, so that database logging
> works asynchronously. It uses "base.Append(..)" to log events from queue. We
> use SQL Azure as database, which as cloud solution is not 100% available.
> In rare cases appender crashes the app domain on "BeginDbTransaction" line,
> as it is not covered with try / catch block.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (LOG4NET-264) Unexpected/Invalid(?) System.PlatformNotSupportedException
[ https://issues.apache.org/jira/browse/LOG4NET-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominik Psenner closed LOG4NET-264. --- Resolution: Cannot Reproduce Assignee: Dominik Psenner Closing because we can't reproduce this issue. > Unexpected/Invalid(?) System.PlatformNotSupportedException > -- > > Key: LOG4NET-264 > URL: https://issues.apache.org/jira/browse/LOG4NET-264 > Project: Log4net > Issue Type: Bug > Components: Core >Affects Versions: 1.2.10 > Environment: Windows XP SP3; .NET Framework 3.5 SP1 >Reporter: Troy Walker >Assignee: Dominik Psenner > Fix For: 1.2 Maintenance Release > > > A user of my software that utilizes log4net is getting the following > exception upon initializing log4net 1.2.10 despite the fact that the user is > running Windows XP SP3 with the .NET Framework 3.5 SP1. > System.TypeInitializationException: The type initializer for > 'log4net.GlobalContext' threw an exception. ---> > System.PlatformNotSupportedException: This operation is only supported on > Windows 2000 SP3 or later operating systems. >at System.Security.Principal.SecurityIdentifier..ctor(WellKnownSidType > sidType, SecurityIdentifier domainSid) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LOG4NET-264) Unexpected/Invalid(?) System.PlatformNotSupportedException
[ https://issues.apache.org/jira/browse/LOG4NET-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15640492#comment-15640492 ] Dominik Psenner commented on LOG4NET-264: - Bumping WinXP related issues, dev list please discuss if we can close this issue as won't fix because WinXP reached end of life. > Unexpected/Invalid(?) System.PlatformNotSupportedException > -- > > Key: LOG4NET-264 > URL: https://issues.apache.org/jira/browse/LOG4NET-264 > Project: Log4net > Issue Type: Bug > Components: Core >Affects Versions: 1.2.10 > Environment: Windows XP SP3; .NET Framework 3.5 SP1 >Reporter: Troy Walker > Fix For: 1.2 Maintenance Release > > > A user of my software that utilizes log4net is getting the following > exception upon initializing log4net 1.2.10 despite the fact that the user is > running Windows XP SP3 with the .NET Framework 3.5 SP1. > System.TypeInitializationException: The type initializer for > 'log4net.GlobalContext' threw an exception. ---> > System.PlatformNotSupportedException: This operation is only supported on > Windows 2000 SP3 or later operating systems. >at System.Security.Principal.SecurityIdentifier..ctor(WellKnownSidType > sidType, SecurityIdentifier domainSid) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (LOG4NET-272) Problems in dynamic file naming with multiple appenders
[
https://issues.apache.org/jira/browse/LOG4NET-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominik Psenner closed LOG4NET-272.
---
Resolution: Won't Fix
Assignee: Dominik Psenner
The month became a year, closing as won't fix now.
> Problems in dynamic file naming with multiple appenders
> ---
>
> Key: LOG4NET-272
> URL: https://issues.apache.org/jira/browse/LOG4NET-272
> Project: Log4net
> Issue Type: Task
> Components: Appenders
>Affects Versions: 1.2.10
> Environment: OS: Windows XP
> Programming Environment: VB.NET
> .NET Framework 3.5
> Appender Type: RollingFileAppender
>Reporter: Ranjith Nair
>Assignee: Dominik Psenner
>Priority: Minor
> Fix For: 1.2 Maintenance Release
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> I have 3 appenders in my config file for creating 3 different types of logs.
> I am using dynamic naming of file in each of the 3 appenders by setting the
> global context properties. In some cases, i need to set the log file name
> dynamically for just 1 appender. When i set the file name for just 1
> appender, it creates another file named "null" with no data in addition to
> the actual logfile whose name has been set dynamically.
> type="log4net.Appender.RollingFileAppender">
>
> .
> .
> .
> type="log4net.Appender.RollingFileAppender">
>
> .
> .
>
>
>
>
>
>
>
>
> In the VB.NET code i set the filename as :
> log4net.GlobalContext.Properties("applog") = "file1.log"
> Dim logobj as log4net.Ilog = LogManager.GetLogger("Logger1")
> logobj.debug("test")
> In this case it creates "file1.log" and also another empty file with name as
> "null". This happens only when i am setting either of the appenders filename
> at runtime.
> Could you please check and let me know the issue behind this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LOG4NET-211) Log4net with MS Access 2007 for asp.net 3.5 website
[
https://issues.apache.org/jira/browse/LOG4NET-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15640493#comment-15640493
]
Dominik Psenner commented on LOG4NET-211:
-
Bumping WinXP related issues, dev list please discuss if we can close this
issue as won't fix because WinXP reached end of life.
> Log4net with MS Access 2007 for asp.net 3.5 website
> ---
>
> Key: LOG4NET-211
> URL: https://issues.apache.org/jira/browse/LOG4NET-211
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 1.2.10
> Environment: Windows XP, VS 2008, MS Access 2007
>Reporter: sundeep
> Fix For: 1.2 Maintenance Release
>
> Original Estimate: 840h
> Remaining Estimate: 840h
>
> Hello,
> I am using log4net for asp.net 3.5 website for logging exceptions into the MS
> Access 2007 (*accdb ). I had done following settings:
> 1. Created log4net config file
>
>
>type="log4net.Appender.AdoNetAppender">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 2. In app.config file:
> void Application_Start(object sender, EventArgs e)
> {
>string logFile = HttpContext.Current.Request.PhysicalApplicationPath +
> "log4net.config";
> if (System.IO.File.Exists(logFile))
> {
> log4net.Config.XmlConfigurator.ConfigureAndWatch(new
> System.IO.FileInfo(logFile));
> }
>}
> 3. In aspx page
> private static readonly ILog log = LogManager.GetLogger("File");
> log.Error("This is an error message");
> log.Debug("This is a debug message");
> Now what happens is when I browse the aspx page, it is logging exceptions
> after 10-15 min in the logs MS Access table. During my investigation, when I
> opened app_data folder I am able to see Logs.laccdb database getting created
> and after 10-15min this file is getting deleted and rows are added into the
> table. I think log4net is locking the database for such time and performing
> the insert statements.
> Could you please guide me if I am doing anything wrong.
> Thanks,
> Sundeep.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LOG4NET-183) Appender: RemoteSyslogAppender, semicolon persist if identity value is an empty string
[
https://issues.apache.org/jira/browse/LOG4NET-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15640489#comment-15640489
]
Dominik Psenner commented on LOG4NET-183:
-
Bumping WinXP related issues, dev list please discuss if we can close this
issue as won't fix because WinXP reached end of life.
> Appender: RemoteSyslogAppender, semicolon persist if identity value is an
> empty string
> --
>
> Key: LOG4NET-183
> URL: https://issues.apache.org/jira/browse/LOG4NET-183
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 1.2.10
> Environment: Windows XP, .Net 2.0
>Reporter: Victor Munoz
>Priority: Minor
> Fix For: 1.2 Maintenance Release
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Filename: RemolteSyslogAppender.cs
> ---
> // Identity
> if (m_identity != null)
> {
> m_identity.Format(writer, loggingEvent);
> }
> Else
> {
> writer.Write(loggingEvent.Domain);
> }
> writer.Write(": "); <--- ALWAYS include
> semicolon, even if identity is an empty string.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LOG4NET-256) log4net With MDC is not exactly threadsafe?
[ https://issues.apache.org/jira/browse/LOG4NET-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15640490#comment-15640490 ] Dominik Psenner commented on LOG4NET-256: - Bumping WinXP related issues, dev list please discuss if we can close this issue as won't fix because WinXP reached end of life. > log4net With MDC is not exactly threadsafe? > --- > > Key: LOG4NET-256 > URL: https://issues.apache.org/jira/browse/LOG4NET-256 > Project: Log4net > Issue Type: Bug > Components: Core >Affects Versions: 1.2.10 > Environment: Windows Server 2003, Windows XP >Reporter: MK Pandey > Fix For: 1.2 Maintenance Release > > Attachments: bug detals mail.jpg > > > Hi All, > Our situation is that we are using MDC values (ex, transID) to set additional > values which is used across multiple classes to identify the transaction. > We have one LogHelper class which creates private static instance of the as > below: > log4net.ILog fileLogger = LogManager.GetLogger(GetType()); > When second thread starts and modifies the values, the subsequent logs from > other threads start using the same values. > Any suggestions? > When using web.config file for appender defintion, is this not thread safe? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (LOG4NET-255) Problem with getting path to appdata with windows service in Windows XP
[
https://issues.apache.org/jira/browse/LOG4NET-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominik Psenner closed LOG4NET-255.
---
Resolution: Won't Fix
Assignee: Dominik Psenner
WinXP has reached end of life and we are not going to implement a hack for it.
Closing as won't fix. Whoever hits this issue is better off by finding a
workaround.
> Problem with getting path to appdata with windows service in Windows XP
> ---
>
> Key: LOG4NET-255
> URL: https://issues.apache.org/jira/browse/LOG4NET-255
> Project: Log4net
> Issue Type: Bug
>Affects Versions: 1.2.10
> Environment: Windows XP, C# , Windows Service
>Reporter: Martin B.
>Assignee: Dominik Psenner
> Fix For: 1.2 Maintenance Release
>
>
> I've got windows service in C# which using RollingFilleAppender that logs to
> appdata folder. Everything works fine in Vista, W7 or 2008 server, ${APPDATA}
> is correctly replaced by corresponding path to app data folder. But when i
> run my service in Windows XP I get following error through internal
> debugger.
> log4net:ERROR [RollingFileAppender] Unable to acquire lock on file
> \\MyTestApp\LOG\LOG.TXT. Could not find a part of the path '\\MyTestApp\LOG'.
>
> Logger path setting from config file is below:
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (LOG4NET-281) Insufficient Granularity on Log methods in ILog
[
https://issues.apache.org/jira/browse/LOG4NET-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominik Psenner closed LOG4NET-281.
---
Resolution: Won't Fix
Assignee: Dominik Psenner
Extension methods are the road to be taken here. Everything else makes the API
awkward. Anyway I'm closing this issue because extension classes with custom
log levels / method names should be implemented by whoever needs them and they
do not have to be part of the core logging framework. The logging framework
cannot assume what priorities log levels that "Alert", "Emergency" should have
and even if we could, it would start a never ending story.
> Insufficient Granularity on Log methods in ILog
> ---
>
> Key: LOG4NET-281
> URL: https://issues.apache.org/jira/browse/LOG4NET-281
> Project: Log4net
> Issue Type: New Feature
> Components: Core
>Affects Versions: 1.2.10
> Environment: All Environments
>Reporter: Zev
>Assignee: Dominik Psenner
> Fix For: 1.3.0
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> The driver for this change is that we are unable to log certain event types
> from the ILog object. While we can use the Logger object, it is easier to
> have them here.
> updated code:
> ILog.cs
> //start new
> void Emergency(object message);
> void Emergency(object message, Exception e);
> void Alert(object message);
> void Alert(object message, Exception e);
> void Critical(object message);
> void Critical(object message, Exception e);
> void Notice(object message);
> void Notice(object message, Exception e);
> //end new
> LogImpl.cs (in ReloadLevels)
> //start new
> m_levelEmergency = levelMap.LookupWithDefault(Level.Emergency);
> m_levelAlert = levelMap.LookupWithDefault(Level.Alert);
> m_levelCritical = levelMap.LookupWithDefault(Level.Critical);
> m_levelNotice = levelMap.LookupWithDefault(Level.Notice);
> //end new
> methods:
> //start new
> virtual public void Emergency(object message)
> {
> Logger.Log(ThisDeclaringType, m_levelEmergency, message, null);
> }
> virtual public void Emergency(object message, Exception exception)
> {
> Logger.Log(ThisDeclaringType, m_levelEmergency, message,
> exception);
> }
> virtual public void Alert(object message)
> {
> Logger.Log(ThisDeclaringType, m_levelAlert, message, null);
> }
> virtual public void Alert(object message, Exception exception)
> {
> Logger.Log(ThisDeclaringType, m_levelAlert, message, exception);
> }
> virtual public void Critical(object message)
> {
> Logger.Log(ThisDeclaringType, m_levelCritical, message, null);
> }
> virtual public void Critical(object message, Exception exception)
> {
> Logger.Log(ThisDeclaringType, m_levelCritical, message,
> exception);
> }
> virtual public void Notice(object message)
> {
> Logger.Log(ThisDeclaringType, m_levelNotice, message, null);
> }
> virtual public void Notice(object message, Exception exception)
> {
> Logger.Log(ThisDeclaringType, m_levelNotice, message, exception);
> }
> //end new
> private fields:
> //start new
> private Level m_levelEmergency;
> private Level m_levelAlert;
> private Level m_levelCritical;
> private Level m_levelNotice;
> //end new
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LOG4NET-528) AdoNetAppender giving .net lock
[ https://issues.apache.org/jira/browse/LOG4NET-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15609569#comment-15609569 ] Dominik Psenner commented on LOG4NET-528: - There is not enough information in this issue to allow more than just wild guesses. Please provide more information like stacktraces etc. Further, this sounds like a topic for one of the mailing lists. > AdoNetAppender giving .net lock > --- > > Key: LOG4NET-528 > URL: https://issues.apache.org/jira/browse/LOG4NET-528 > Project: Log4net > Issue Type: Bug > Components: Appenders >Affects Versions: 1.2.15 > Environment: Windows Server 2008 R2, WCF Web Http Service, Dot Net 4.0 >Reporter: VENKATA NAGA RADHAKRISHNA SEGU >Priority: Critical > Fix For: 1.2.15 > > > Dear Sir, > I am using log4net adonetappender and logging web service info and error > messages. I am getting Dot Net Lock issue when there are more concurrent > users (approx 300). Please advice me what to do in this case. > Regards, > Venkata -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (LOG4NET-527) broken link on config-examples.html
[ https://issues.apache.org/jira/browse/LOG4NET-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominik Psenner resolved LOG4NET-527. - Resolution: Fixed Fix Version/s: 2.0.6 > broken link on config-examples.html > --- > > Key: LOG4NET-527 > URL: https://issues.apache.org/jira/browse/LOG4NET-527 > Project: Log4net > Issue Type: Bug > Components: Examples >Reporter: raymond sanhcez >Assignee: Dominik Psenner >Priority: Minor > Fix For: 2.0.6 > > Attachments: config-examples.xml.patch > > > I needed more information on AdoNetAppender but encounter a broken link. > If you go to https://logging.apache.org/log4net/release/config-examples.html > and click on the link under AdoNetAppender, you will get not found error. > I'm attaching a patch so we can fix this minor issue. > Thanks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (LOG4NET-527) broken link on config-examples.html
[ https://issues.apache.org/jira/browse/LOG4NET-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605471#comment-15605471 ] Dominik Psenner edited comment on LOG4NET-527 at 10/25/16 2:34 PM: --- Fixed with revision 1766540 Several other links were broken too and I did my best to fix them. Please note that the links will be fixed with the next release. was (Author: nachbarslumpi): Fixed with revision 1766540 Several other links were broken too and I did my best to fix them. > broken link on config-examples.html > --- > > Key: LOG4NET-527 > URL: https://issues.apache.org/jira/browse/LOG4NET-527 > Project: Log4net > Issue Type: Bug > Components: Examples >Reporter: raymond sanhcez >Assignee: Dominik Psenner >Priority: Minor > Fix For: 2.0.6 > > Attachments: config-examples.xml.patch > > > I needed more information on AdoNetAppender but encounter a broken link. > If you go to https://logging.apache.org/log4net/release/config-examples.html > and click on the link under AdoNetAppender, you will get not found error. > I'm attaching a patch so we can fix this minor issue. > Thanks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LOG4NET-527) broken link on config-examples.html
[ https://issues.apache.org/jira/browse/LOG4NET-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605471#comment-15605471 ] Dominik Psenner commented on LOG4NET-527: - Fixed with revision 1766540 Several other links were broken too and I did my best to fix them. > broken link on config-examples.html > --- > > Key: LOG4NET-527 > URL: https://issues.apache.org/jira/browse/LOG4NET-527 > Project: Log4net > Issue Type: Bug > Components: Examples >Reporter: raymond sanhcez >Assignee: Dominik Psenner >Priority: Minor > Attachments: config-examples.xml.patch > > > I needed more information on AdoNetAppender but encounter a broken link. > If you go to https://logging.apache.org/log4net/release/config-examples.html > and click on the link under AdoNetAppender, you will get not found error. > I'm attaching a patch so we can fix this minor issue. > Thanks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (LOG4NET-527) broken link on config-examples.html
[ https://issues.apache.org/jira/browse/LOG4NET-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominik Psenner reassigned LOG4NET-527: --- Assignee: Dominik Psenner > broken link on config-examples.html > --- > > Key: LOG4NET-527 > URL: https://issues.apache.org/jira/browse/LOG4NET-527 > Project: Log4net > Issue Type: Bug > Components: Examples >Reporter: raymond sanhcez >Assignee: Dominik Psenner >Priority: Minor > Attachments: config-examples.xml.patch > > > I needed more information on AdoNetAppender but encounter a broken link. > If you go to https://logging.apache.org/log4net/release/config-examples.html > and click on the link under AdoNetAppender, you will get not found error. > I'm attaching a patch so we can fix this minor issue. > Thanks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LOG4NET-527) broken link on config-examples.html
[ https://issues.apache.org/jira/browse/LOG4NET-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15604531#comment-15604531 ] Dominik Psenner commented on LOG4NET-527: - Thanks for the report. The link should probably read as follows: /log4net/release/sdk/html/AllMembers_T_log4net_Appender_AdoNetAppender.htm Going to change it right away. > broken link on config-examples.html > --- > > Key: LOG4NET-527 > URL: https://issues.apache.org/jira/browse/LOG4NET-527 > Project: Log4net > Issue Type: Bug > Components: Examples >Reporter: raymond sanhcez >Priority: Minor > Attachments: config-examples.xml.patch > > > I needed more information on AdoNetAppender but encounter a broken link. > If you go to https://logging.apache.org/log4net/release/config-examples.html > and click on the link under AdoNetAppender, you will get not found error. > I'm attaching a patch so we can fix this minor issue. > Thanks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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=15540806#comment-15540806 ] Dominik Psenner commented on LOG4NET-418: - According to https://github.com/cjbhaines/Log4Net.Async/issues/30 the exception stacktrace looks like: "log4net:ERROR Subscriber task was aborted. System.Threading.ThreadAbortException: Thread was being aborted. at System.Threading.Monitor.ObjWait(Boolean exitContext, Int32 millisecondsTimeout, Object obj) at System.Threading.SemaphoreSlim.WaitUntilCountOrTimeout(Int32 millisecondsTimeout, UInt32 startTime, CancellationToken cancellationToken) at System.Threading.SemaphoreSlim.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken) at System.Collections.Concurrent.BlockingCollection1.TryTakeWithNoTimeValidation(T& item, Int32 millisecondsTimeout, CancellationToken cancellationToken, CancellationTokenSource combinedTokenSource) at System.Collections.Concurrent.BlockingCollection1.d__68.MoveNext() at Log4Net.Async.ParallelForwardingAppender.SubscriberLoop() log4net:ERROR Exception while logging System.Threading.LockRecursionException: Recursive read lock acquisitions not allowed in this mode. at System.Threading.ReaderWriterLockSlim.TryEnterReadLockCore(TimeoutTracker timeout) at System.Threading.ReaderWriterLockSlim.TryEnterReadLock(TimeoutTracker timeout) at log4net.Repository.Hierarchy.Logger.CallAppenders(LoggingEvent loggingEvent) at log4net.Repository.Hierarchy.Logger.Log(Type callerStackBoundaryDeclaringType, Level level, Object message, Exception exception)" and a System.Threading.ThreadAbortException indicates another issue that at first sight looks unrelated. ThreadAbortException is generally thrown when a thread should be aborted (i.e. terminated) and that can indeed happen with when an async log request is being processed but the thread that it runs on gets terminated before it can complete its task. We will need more information to shed more light on this but this information should point you into a direction that should help you understand the root cause of the issue. > 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.3.4#6332)
[jira] [Commented] (LOG4NET-465) Rolling log files get overwritten when IIS is restarted
[
https://issues.apache.org/jira/browse/LOG4NET-465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15504495#comment-15504495
]
Dominik Psenner commented on LOG4NET-465:
-
Sorry, time flies. I had no chance to evaluate your input yet and obviously
nobody else picked up the issue. We are currently seeking out for help. See:
http://mail-archives.apache.org/mod_mbox/logging-log4net-dev/201609.mbox/%3C871t0x1xb0.fsf%40v45346.1blu.de%3E
It would be great to see you on the dev mailing list!
> Rolling log files get overwritten when IIS is restarted
> ---
>
> Key: LOG4NET-465
> URL: https://issues.apache.org/jira/browse/LOG4NET-465
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 1.2.13
> Environment: asp.net 4.0
>Reporter: Michel Emond
> Attachments: RollingFileAppender.diff, config.xml
>
>
> This is the issue described in LOG4NET-378
> h2. Reproduction steps
> # Setup a web application using the settings from the attached config.xml file
> # Notice the rolling style set to Composite
> # Start and use the application
> # The log files pile up in the folder
> # Restart IIS
> # Keep using the application
> Expected result
> - The rolling continues on or after the last file
> Actual result
> - The rolling restarts at index 1 and overwrites the existing files
> h2. Solution
> See the attached files:
> - config.xml
> - patch with a fix proposal
> The original bug fix addresses the issue in the InitializeFromOneFile()
> method.
> However, the GetWildcardPatternForFile() method also needs the baseFileName
> to be adjusted with the datePattern so the proper files are searched.
> I placed a file path fix in the DetermineCurSizeRollBackups() method, so it's
> then passed down to the two other methods and everyone gets happy.
> Here's a calling stack sample:
> {code}
> DetermineCurSizeRollBackups()
> |
> +--GetExistingFiles()
> | +--GetWildcardPatternForFile()
> |
> +--InitializeRollBackups()
>+--InitializeFromOneFile()
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LOG4NET-505) AdoNetAppender with Npgsql data provider
[ https://issues.apache.org/jira/browse/LOG4NET-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15504476#comment-15504476 ] Dominik Psenner commented on LOG4NET-505: - Thats great and we are happy to read such news! You should probably start here: https://logging.apache.org/log4net/mail-lists.html https://logging.apache.org/log4net/source-repository.html https://logging.apache.org/log4net/release/building.html Feed the mailing list if you have any questions. > AdoNetAppender with Npgsql data provider > > > Key: LOG4NET-505 > URL: https://issues.apache.org/jira/browse/LOG4NET-505 > Project: Log4net > Issue Type: Bug > Components: Appenders >Affects Versions: 1.2.15 >Reporter: Vadim Ivanou > > I'm trying to use AdoNetAppender with postgresql database and Npgsql data > provider 3.0.x. Unfortunately it throws an exception in SendBuffer method > while executing dbCmd.Prepare(). I believe the reason for that is that Npgsql > requires all Parameters to be present in a command before calling Prepare > method. I created my own adapter that overrides SendBuffer method and > populates sql command parameters before Prepare and it worked fine. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LOG4NET-525) RollingFileAppender initialization throws UnauthorizedAccessException while creating a mutex
[
https://issues.apache.org/jira/browse/LOG4NET-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15476074#comment-15476074
]
Dominik Psenner commented on LOG4NET-525:
-
Since 1.2.14 log4net uses a mutex to make sure that rolling is done by one
process only such that there is no possibility of race conditions when multiple
applications append and roll on the same files. It would be nice if you could
troubleshoot this issue on your side. Once we are able to reproduce the issue,
we can write a test for it and fix it for good.
> RollingFileAppender initialization throws UnauthorizedAccessException while
> creating a mutex
>
>
> Key: LOG4NET-525
> URL: https://issues.apache.org/jira/browse/LOG4NET-525
> Project: Log4net
> Issue Type: Bug
>Affects Versions: 1.2.15
>Reporter: Brandon Johnson
>
> Hello,
> My team upgraded our ASP.NET web application from log4net 1.2.13 to 1.2.15
> and lost logging functionality in one of our QA environments. log4net's
> internal logging reports:
> {code}
> log4net:ERROR Could not create Appender [RollingLogFileAppenderServerQual] of
> type [log4net.Appender.RollingFileAppender]. Reported error follows.
> System.UnauthorizedAccessException: Access to the path
> 'D__AppLogs_AMS_AMSLogQual.log' is denied.
>at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
>at System.Threading.Mutex.MutexTryCodeHelper.MutexTryCode(Object userData)
>at
> System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode
> code, CleanupCode backoutCode, Object userData)
>at System.Threading.Mutex.CreateMutexWithGuaranteedCleanup(Boolean
> initiallyOwned, String name, Boolean& createdNew, SECURITY_ATTRIBUTES
> secAttrs)
>at System.Threading.Mutex..ctor(Boolean initiallyOwned, String name,
> Boolean& createdNew, MutexSecurity mutexSecurity)
>at System.Threading.Mutex..ctor(Boolean initiallyOwned, String name)
>at log4net.Appender.RollingFileAppender.ActivateOptions()
>at
> log4net.Repository.Hierarchy.XmlHierarchyConfigurator.ParseAppender(XmlElement
> appenderElement)
> {code}
> After some confusion on our end I confirmed that downgrading log4net back to
> 1.2.13 avoids the problem. I am seeing similar bug reports from other users,
> often under different circumstances. E.g. LOG4NET-506 is about the parent
> folder of the log file being locked, but in our case it's the log file.
> Is remaining on 1.2.13 my only option? Or is there something I can change
> with my appender configuration?
> {code}
> type="log4net.Appender.RollingFileAppender">
>
>
>
>
>
>
>
>
>
>
>
> {code}
> Let me know, thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LOG4NET-454) Intermittent severe slowdown with RollingFileAppender+MinimalLock
[
https://issues.apache.org/jira/browse/LOG4NET-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15443831#comment-15443831
]
Dominik Psenner commented on LOG4NET-454:
-
The configuration you have posted does not limit the file size, it rolls by
date and not by file size. Therefore I do not understand how that would limit
the file size and hence all the argumentation should not have any effect.
That apart, can you investigate on this issue with a performance profiler? More
information on the environment would also be interesting and help pinpointing
this issue to a common denominator:
- operating system
- .net framework version
- cpu information
- hard drive information
- is the application run from a network share?
- ...
> Intermittent severe slowdown with RollingFileAppender+MinimalLock
> -
>
> Key: LOG4NET-454
> URL: https://issues.apache.org/jira/browse/LOG4NET-454
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 1.2.13
> Environment: ASP.NET MVC 5.2.2 Application, Windows 7 Professional
>Reporter: Chuck Felish
>
> Using RollingFileAppender with MinimalLock we found an extreme slowdown in
> the processing of our application requests (from 300ms to up to 15s in some
> cases) which was resolved when we deleted our log files. We also found that
> changing the lock to Exclusive resolved the issue.
> Interestingly file content seemed to be related, but not file size. When I
> took the contents of a colleague's log file and pasted them into my own log
> file the slowness issue appeared again. I then tried deleting about half the
> contents and then causing the file to grow to larger than the original size
> but the issue did not return. Pasting the original contents back into the
> file caused the performance issue to return.
> While Exclusive lock has resolved our issue for now, it's quite unexpected
> that file contents would affect performance at all, and that the issue is
> does not consistently reproduce even though configuration is unchanged.
> I'm happy to demonstrate and/or share our problematic log files with you to
> facilitate the resolution of this issue.
> Our configuration is as follows:
>
> value="Logs\%property{ExecutableName}_%env{COMPUTERNAME}.log" />
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LOG4NET-524) OnlyOnceErrorHandler might cause StackOverflowError
[
https://issues.apache.org/jira/browse/LOG4NET-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15435303#comment-15435303
]
Dominik Psenner commented on LOG4NET-524:
-
Please subscribe to the log4j mailing list to track notifications and get
involved. I do not actively hack on log4j and will most likely loose track of
this.
> OnlyOnceErrorHandler might cause StackOverflowError
> ---
>
> Key: LOG4NET-524
> URL: https://issues.apache.org/jira/browse/LOG4NET-524
> Project: Log4net
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.2.15
>Reporter: Marc Theisen
>Assignee: Dominik Psenner
>
> I am referring to the solution in
> https://bz.apache.org/bugzilla/show_bug.cgi?id=42151.
> I am suggesting another approach instead of placing a bad hack into
> com.{{csfb.fao.carat.util.file.LoggingOutputStream}}.
> Why not change the {{error}} method of class {{OnlyOnceErrorHandler}} from
> {code}
> public void error(String message, Exception e, int errorCode, LoggingEvent
> event)
> {
> if (e instanceof InterruptedIOException || e instanceof
> InterruptedException)
> {
> Thread.currentThread().interrupt();
> }
> if(firstTime)
> {
> LogLog.error(message, e);
> firstTime = false; // yikes, too late if stdout/stderr has been
> } // redirected
> }
> {code}
> to
> {code}
> public void error(String message, Exception e, int errorCode, LoggingEvent
> event)
> {
> if (e instanceof InterruptedIOException || e instanceof
> InterruptedException)
> {
> Thread.currentThread().interrupt();
> }
> if(firstTime)
> {
> firstTime = false;
> LogLog.error(message, e);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (LOG4NET-524) OnlyOnceErrorHandler might cause StackOverflowError
[
https://issues.apache.org/jira/browse/LOG4NET-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominik Psenner closed LOG4NET-524.
---
Resolution: Invalid
This is log4net, the bugzilla report is about log4j. Redirected bug report to
log4j mailing list.
> OnlyOnceErrorHandler might cause StackOverflowError
> ---
>
> Key: LOG4NET-524
> URL: https://issues.apache.org/jira/browse/LOG4NET-524
> Project: Log4net
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.2.15
>Reporter: Marc Theisen
>Assignee: Dominik Psenner
>
> I am referring to the solution in
> https://bz.apache.org/bugzilla/show_bug.cgi?id=42151.
> I am suggesting another approach instead of placing a bad hack into
> com.{{csfb.fao.carat.util.file.LoggingOutputStream}}.
> Why not change the {{error}} method of class {{OnlyOnceErrorHandler}} from
> {code}
> public void error(String message, Exception e, int errorCode, LoggingEvent
> event)
> {
> if (e instanceof InterruptedIOException || e instanceof
> InterruptedException)
> {
> Thread.currentThread().interrupt();
> }
> if(firstTime)
> {
> LogLog.error(message, e);
> firstTime = false; // yikes, too late if stdout/stderr has been
> } // redirected
> }
> {code}
> to
> {code}
> public void error(String message, Exception e, int errorCode, LoggingEvent
> event)
> {
> if (e instanceof InterruptedIOException || e instanceof
> InterruptedException)
> {
> Thread.currentThread().interrupt();
> }
> if(firstTime)
> {
> firstTime = false;
> LogLog.error(message, e);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (LOG4NET-524) OnlyOnceErrorHandler might cause StackOverflowError
[
https://issues.apache.org/jira/browse/LOG4NET-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominik Psenner reassigned LOG4NET-524:
---
Assignee: Dominik Psenner
> OnlyOnceErrorHandler might cause StackOverflowError
> ---
>
> Key: LOG4NET-524
> URL: https://issues.apache.org/jira/browse/LOG4NET-524
> Project: Log4net
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.2.15
>Reporter: Marc Theisen
>Assignee: Dominik Psenner
>
> I am referring to the solution in
> https://bz.apache.org/bugzilla/show_bug.cgi?id=42151.
> I am suggesting another approach instead of placing a bad hack into
> com.{{csfb.fao.carat.util.file.LoggingOutputStream}}.
> Why not change the {{error}} method of class {{OnlyOnceErrorHandler}} from
> {code}
> public void error(String message, Exception e, int errorCode, LoggingEvent
> event)
> {
> if (e instanceof InterruptedIOException || e instanceof
> InterruptedException)
> {
> Thread.currentThread().interrupt();
> }
> if(firstTime)
> {
> LogLog.error(message, e);
> firstTime = false; // yikes, too late if stdout/stderr has been
> } // redirected
> }
> {code}
> to
> {code}
> public void error(String message, Exception e, int errorCode, LoggingEvent
> event)
> {
> if (e instanceof InterruptedIOException || e instanceof
> InterruptedException)
> {
> Thread.currentThread().interrupt();
> }
> if(firstTime)
> {
> firstTime = false;
> LogLog.error(message, e);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[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=15360444#comment-15360444 ] Dominik Psenner commented on LOG4NET-418: - The hint to solve this issue is to not cause recursive locks. This can be done by fixing the customized code. > 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.3.4#6332)
[jira] [Commented] (LOG4NET-518) Filters don't work when use multiple.
[
https://issues.apache.org/jira/browse/LOG4NET-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15342201#comment-15342201
]
Dominik Psenner commented on LOG4NET-518:
-
I just reviewed your patch and from what i have understood it makes filters
more restrictive than they have been until now. Until your patch, a filter
would filter log events if all requirements are met, now events are filtered if
some requirements are met. Given that it breaks current functionality, your
patch wont make it into trunk. Please feed back if my review was wrong.
> Filters don't work when use multiple.
> -
>
> Key: LOG4NET-518
> URL: https://issues.apache.org/jira/browse/LOG4NET-518
> Project: Log4net
> Issue Type: Bug
> Components: Other
>Affects Versions: 1.2.15
>Reporter: huiqiang yan
>
> I have an application managed multiple AppDomains, and my master application
> can get messages from all appDomain, then log them separately.
> I create appenders from each appDomains and use the 'domain name’ and 'log
> level' to discriminate。
> RollingFileAppender appender = new RollingFileAppender();
> appender.AddFilter(new LevelRangeFilter
> {
> LevelMin = Level.Info,
> LevelMax = Level.Info,
> AcceptOnMatch = false,
> Next = new LoggerMatchFilter
> {
> LoggerToMatch = name,
> AcceptOnMatch = true
> }
> });
> when name doesn't match, the If statement in filter LoggerMatchFilter file at
> line 140 ,I think it means match or doesn't match, it should be deny in else
> statement.
> AcceptOnMatch only use when the match is passed ,it means if should return
> Accept when matched,and when it is false then return Neutral.
> Not only LoggerMatchFilter has this problem, others too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LOG4NET-506) RollingFileAppender locking log folder in some cases
[
https://issues.apache.org/jira/browse/LOG4NET-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15198070#comment-15198070
]
Dominik Psenner commented on LOG4NET-506:
-
Of course, this issue must be resolved in such a way that it does not introduce
new issues and it should not under the precondition that all possibly offending
characters that a date pattern could contain are properly escaped. In the
example .MM.dd'-App1.log' the single quotes (') would have to be removed or
replaced by a safe character.
> RollingFileAppender locking log folder in some cases
>
>
> Key: LOG4NET-506
> URL: https://issues.apache.org/jira/browse/LOG4NET-506
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 1.2.15
> Environment: Windows Server 2008 R2, Windows Server 2012 R2
>Reporter: Frédéric Delaporte
>Assignee: Dominik Psenner
>Priority: Minor
> Labels: triaged
> Attachments: AppAlone_log4net.txt, AppConcurrently_log4net.txt
>
>
> *Abstract:*
> In some configuration cases, the rolling file appender may issue a mutex lock
> on the folder name. If more than one processes try to do that with different
> executing identity, only one will be able to log to its specific logs file.
> The others will no more be able to do it.
> *Repro:*
> Many applications run on the same server.
> All run under different windows identity.
> All do log through {{RollingFileAppender}} to D:\Logs\ (value of {{file}}
> configuration node) to their own file log (filename specific to each
> application through {{datePattern}} configuration node, like
> {{.MM.dd'-App1.log'}}, {{.MM.dd'-App2.log'}}, ...).
> They log through {{AdoNetAppender}} too.
> Since having upgraded Log4Net from 1.2.13 to 1.2.15 on some applications,
> they cease being able to all log to D:\Logs\. Only one of them still do log,
> depending on which have started first. SQL logs still work. Non upgraded
> applications are still able to log to D:\Logs\, whatever their start order
> have been.
> *Diagnosis info:*
> Activating log4net debug trace on an application, and comparing failure cases
> to working cases, yields following diff:
> {code:title=failing case debug trace}
> log4net:ERROR Could not create Appender [RollingLogFileAppender] of type
> [log4net.Appender.RollingFileAppender]. Reported error follows.
> System.UnauthorizedAccessException: Access to path 'D__Logs_' denied.
> (Translated from french)
>à System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
>à System.Threading.Mutex.MutexTryCodeHelper.MutexTryCode(Object userData)
>à
> System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode
> code, CleanupCode backoutCode, Object userData)
>à System.Threading.Mutex.CreateMutexWithGuaranteedCleanup(Boolean
> initiallyOwned, String name, Boolean& createdNew, SECURITY_ATTRIBUTES
> secAttrs)
>à System.Threading.Mutex..ctor(Boolean initiallyOwned, String name,
> Boolean& createdNew, MutexSecurity mutexSecurity)
>à System.Threading.Mutex..ctor(Boolean initiallyOwned, String name,
> Boolean& createdNew)
>à log4net.Appender.RollingFileAppender.ActivateOptions()
>à
> log4net.Repository.Hierarchy.XmlHierarchyConfigurator.ParseAppender(XmlElement
> appenderElement)
> log4net:ERROR Appender named [RollingLogFileAppender] not found.
> {code}
> {code:title=working case corresponding trace}
> log4net: Searched for existing files in [D:\Logs]
> log4net: curSizeRollBackups starts at [0]
> log4net: Opening file for writing [D:\Logs\2016.02.26-App1.log] append [True]
> log4net: Created Appender [RollingLogFileAppender]
> log4net: Adding appender named [RollingLogFileAppender] to logger [root].
> {code}
> (All other trace lines are identical)
> {code:xml|title=Application appender configuration}
>type="log4net.Appender.RollingFileAppender">
>
>
>
>
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LOG4NET-506) RollingFileAppender locking log folder in some cases
[
https://issues.apache.org/jira/browse/LOG4NET-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominik Psenner updated LOG4NET-506:
Labels: triaged (was: )
> RollingFileAppender locking log folder in some cases
>
>
> Key: LOG4NET-506
> URL: https://issues.apache.org/jira/browse/LOG4NET-506
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 1.2.15
> Environment: Windows Server 2008 R2, Windows Server 2012 R2
>Reporter: Frédéric Delaporte
>Assignee: Dominik Psenner
>Priority: Minor
> Labels: triaged
> Attachments: AppAlone_log4net.txt, AppConcurrently_log4net.txt
>
>
> *Abstract:*
> In some configuration cases, the rolling file appender may issue a mutex lock
> on the folder name. If more than one processes try to do that with different
> executing identity, only one will be able to log to its specific logs file.
> The others will no more be able to do it.
> *Repro:*
> Many applications run on the same server.
> All run under different windows identity.
> All do log through {{RollingFileAppender}} to D:\Logs\ (value of {{file}}
> configuration node) to their own file log (filename specific to each
> application through {{datePattern}} configuration node, like
> {{.MM.dd'-App1.log'}}, {{.MM.dd'-App2.log'}}, ...).
> They log through {{AdoNetAppender}} too.
> Since having upgraded Log4Net from 1.2.13 to 1.2.15 on some applications,
> they cease being able to all log to D:\Logs\. Only one of them still do log,
> depending on which have started first. SQL logs still work. Non upgraded
> applications are still able to log to D:\Logs\, whatever their start order
> have been.
> *Diagnosis info:*
> Activating log4net debug trace on an application, and comparing failure cases
> to working cases, yields following diff:
> {code:title=failing case debug trace}
> log4net:ERROR Could not create Appender [RollingLogFileAppender] of type
> [log4net.Appender.RollingFileAppender]. Reported error follows.
> System.UnauthorizedAccessException: Access to path 'D__Logs_' denied.
> (Translated from french)
>à System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
>à System.Threading.Mutex.MutexTryCodeHelper.MutexTryCode(Object userData)
>à
> System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode
> code, CleanupCode backoutCode, Object userData)
>à System.Threading.Mutex.CreateMutexWithGuaranteedCleanup(Boolean
> initiallyOwned, String name, Boolean& createdNew, SECURITY_ATTRIBUTES
> secAttrs)
>à System.Threading.Mutex..ctor(Boolean initiallyOwned, String name,
> Boolean& createdNew, MutexSecurity mutexSecurity)
>à System.Threading.Mutex..ctor(Boolean initiallyOwned, String name,
> Boolean& createdNew)
>à log4net.Appender.RollingFileAppender.ActivateOptions()
>à
> log4net.Repository.Hierarchy.XmlHierarchyConfigurator.ParseAppender(XmlElement
> appenderElement)
> log4net:ERROR Appender named [RollingLogFileAppender] not found.
> {code}
> {code:title=working case corresponding trace}
> log4net: Searched for existing files in [D:\Logs]
> log4net: curSizeRollBackups starts at [0]
> log4net: Opening file for writing [D:\Logs\2016.02.26-App1.log] append [True]
> log4net: Created Appender [RollingLogFileAppender]
> log4net: Adding appender named [RollingLogFileAppender] to logger [root].
> {code}
> (All other trace lines are identical)
> {code:xml|title=Application appender configuration}
>type="log4net.Appender.RollingFileAppender">
>
>
>
>
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LOG4NET-506) RollingFileAppender locking log folder in some cases
[
https://issues.apache.org/jira/browse/LOG4NET-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15194867#comment-15194867
]
Dominik Psenner commented on LOG4NET-506:
-
Possibly repeating myselve, the mutex name generator has to be fixed such that
it considers the datePattern property if rollingStyle is composite or time
based.
> RollingFileAppender locking log folder in some cases
>
>
> Key: LOG4NET-506
> URL: https://issues.apache.org/jira/browse/LOG4NET-506
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 1.2.15
> Environment: Windows Server 2008 R2, Windows Server 2012 R2
>Reporter: Frédéric Delaporte
>Priority: Minor
> Attachments: AppAlone_log4net.txt, AppConcurrently_log4net.txt
>
>
> *Abstract:*
> In some configuration cases, the rolling file appender may issue a mutex lock
> on the folder name. If more than one processes try to do that with different
> executing identity, only one will be able to log to its specific logs file.
> The others will no more be able to do it.
> *Repro:*
> Many applications run on the same server.
> All run under different windows identity.
> All do log through {{RollingFileAppender}} to D:\Logs\ (value of {{file}}
> configuration node) to their own file log (filename specific to each
> application through {{datePattern}} configuration node, like
> {{.MM.dd'-App1.log'}}, {{.MM.dd'-App2.log'}}, ...).
> They log through {{AdoNetAppender}} too.
> Since having upgraded Log4Net from 1.2.13 to 1.2.15 on some applications,
> they cease being able to all log to D:\Logs\. Only one of them still do log,
> depending on which have started first. SQL logs still work. Non upgraded
> applications are still able to log to D:\Logs\, whatever their start order
> have been.
> *Diagnosis info:*
> Activating log4net debug trace on an application, and comparing failure cases
> to working cases, yields following diff:
> {code:title=failing case debug trace}
> log4net:ERROR Could not create Appender [RollingLogFileAppender] of type
> [log4net.Appender.RollingFileAppender]. Reported error follows.
> System.UnauthorizedAccessException: Access to path 'D__Logs_' denied.
> (Translated from french)
>à System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
>à System.Threading.Mutex.MutexTryCodeHelper.MutexTryCode(Object userData)
>à
> System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode
> code, CleanupCode backoutCode, Object userData)
>à System.Threading.Mutex.CreateMutexWithGuaranteedCleanup(Boolean
> initiallyOwned, String name, Boolean& createdNew, SECURITY_ATTRIBUTES
> secAttrs)
>à System.Threading.Mutex..ctor(Boolean initiallyOwned, String name,
> Boolean& createdNew, MutexSecurity mutexSecurity)
>à System.Threading.Mutex..ctor(Boolean initiallyOwned, String name,
> Boolean& createdNew)
>à log4net.Appender.RollingFileAppender.ActivateOptions()
>à
> log4net.Repository.Hierarchy.XmlHierarchyConfigurator.ParseAppender(XmlElement
> appenderElement)
> log4net:ERROR Appender named [RollingLogFileAppender] not found.
> {code}
> {code:title=working case corresponding trace}
> log4net: Searched for existing files in [D:\Logs]
> log4net: curSizeRollBackups starts at [0]
> log4net: Opening file for writing [D:\Logs\2016.02.26-App1.log] append [True]
> log4net: Created Appender [RollingLogFileAppender]
> log4net: Adding appender named [RollingLogFileAppender] to logger [root].
> {code}
> (All other trace lines are identical)
> {code:xml|title=Application appender configuration}
>type="log4net.Appender.RollingFileAppender">
>
>
>
>
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (LOG4NET-506) RollingFileAppender locking log folder in some cases
[
https://issues.apache.org/jira/browse/LOG4NET-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominik Psenner reassigned LOG4NET-506:
---
Assignee: Dominik Psenner
> RollingFileAppender locking log folder in some cases
>
>
> Key: LOG4NET-506
> URL: https://issues.apache.org/jira/browse/LOG4NET-506
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 1.2.15
> Environment: Windows Server 2008 R2, Windows Server 2012 R2
>Reporter: Frédéric Delaporte
>Assignee: Dominik Psenner
>Priority: Minor
> Attachments: AppAlone_log4net.txt, AppConcurrently_log4net.txt
>
>
> *Abstract:*
> In some configuration cases, the rolling file appender may issue a mutex lock
> on the folder name. If more than one processes try to do that with different
> executing identity, only one will be able to log to its specific logs file.
> The others will no more be able to do it.
> *Repro:*
> Many applications run on the same server.
> All run under different windows identity.
> All do log through {{RollingFileAppender}} to D:\Logs\ (value of {{file}}
> configuration node) to their own file log (filename specific to each
> application through {{datePattern}} configuration node, like
> {{.MM.dd'-App1.log'}}, {{.MM.dd'-App2.log'}}, ...).
> They log through {{AdoNetAppender}} too.
> Since having upgraded Log4Net from 1.2.13 to 1.2.15 on some applications,
> they cease being able to all log to D:\Logs\. Only one of them still do log,
> depending on which have started first. SQL logs still work. Non upgraded
> applications are still able to log to D:\Logs\, whatever their start order
> have been.
> *Diagnosis info:*
> Activating log4net debug trace on an application, and comparing failure cases
> to working cases, yields following diff:
> {code:title=failing case debug trace}
> log4net:ERROR Could not create Appender [RollingLogFileAppender] of type
> [log4net.Appender.RollingFileAppender]. Reported error follows.
> System.UnauthorizedAccessException: Access to path 'D__Logs_' denied.
> (Translated from french)
>à System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
>à System.Threading.Mutex.MutexTryCodeHelper.MutexTryCode(Object userData)
>à
> System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode
> code, CleanupCode backoutCode, Object userData)
>à System.Threading.Mutex.CreateMutexWithGuaranteedCleanup(Boolean
> initiallyOwned, String name, Boolean& createdNew, SECURITY_ATTRIBUTES
> secAttrs)
>à System.Threading.Mutex..ctor(Boolean initiallyOwned, String name,
> Boolean& createdNew, MutexSecurity mutexSecurity)
>à System.Threading.Mutex..ctor(Boolean initiallyOwned, String name,
> Boolean& createdNew)
>à log4net.Appender.RollingFileAppender.ActivateOptions()
>à
> log4net.Repository.Hierarchy.XmlHierarchyConfigurator.ParseAppender(XmlElement
> appenderElement)
> log4net:ERROR Appender named [RollingLogFileAppender] not found.
> {code}
> {code:title=working case corresponding trace}
> log4net: Searched for existing files in [D:\Logs]
> log4net: curSizeRollBackups starts at [0]
> log4net: Opening file for writing [D:\Logs\2016.02.26-App1.log] append [True]
> log4net: Created Appender [RollingLogFileAppender]
> log4net: Adding appender named [RollingLogFileAppender] to logger [root].
> {code}
> (All other trace lines are identical)
> {code:xml|title=Application appender configuration}
>type="log4net.Appender.RollingFileAppender">
>
>
>
>
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LOG4NET-506) RollingFileAppender locking log folder in some cases
[
https://issues.apache.org/jira/browse/LOG4NET-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15194865#comment-15194865
]
Dominik Psenner commented on LOG4NET-506:
-
Long story short, LOG4NET-487 would not solve this issue but could provide yet
another workaround that would work in your case because you have "AppXXX" in
your datePatterns. The mutex name generator has to consider the datePattern
property if rollingStyle is composite or time based.
> RollingFileAppender locking log folder in some cases
>
>
> Key: LOG4NET-506
> URL: https://issues.apache.org/jira/browse/LOG4NET-506
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 1.2.15
> Environment: Windows Server 2008 R2, Windows Server 2012 R2
>Reporter: Frédéric Delaporte
>Priority: Minor
> Attachments: AppAlone_log4net.txt, AppConcurrently_log4net.txt
>
>
> *Abstract:*
> In some configuration cases, the rolling file appender may issue a mutex lock
> on the folder name. If more than one processes try to do that with different
> executing identity, only one will be able to log to its specific logs file.
> The others will no more be able to do it.
> *Repro:*
> Many applications run on the same server.
> All run under different windows identity.
> All do log through {{RollingFileAppender}} to D:\Logs\ (value of {{file}}
> configuration node) to their own file log (filename specific to each
> application through {{datePattern}} configuration node, like
> {{.MM.dd'-App1.log'}}, {{.MM.dd'-App2.log'}}, ...).
> They log through {{AdoNetAppender}} too.
> Since having upgraded Log4Net from 1.2.13 to 1.2.15 on some applications,
> they cease being able to all log to D:\Logs\. Only one of them still do log,
> depending on which have started first. SQL logs still work. Non upgraded
> applications are still able to log to D:\Logs\, whatever their start order
> have been.
> *Diagnosis info:*
> Activating log4net debug trace on an application, and comparing failure cases
> to working cases, yields following diff:
> {code:title=failing case debug trace}
> log4net:ERROR Could not create Appender [RollingLogFileAppender] of type
> [log4net.Appender.RollingFileAppender]. Reported error follows.
> System.UnauthorizedAccessException: Access to path 'D__Logs_' denied.
> (Translated from french)
>à System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
>à System.Threading.Mutex.MutexTryCodeHelper.MutexTryCode(Object userData)
>à
> System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode
> code, CleanupCode backoutCode, Object userData)
>à System.Threading.Mutex.CreateMutexWithGuaranteedCleanup(Boolean
> initiallyOwned, String name, Boolean& createdNew, SECURITY_ATTRIBUTES
> secAttrs)
>à System.Threading.Mutex..ctor(Boolean initiallyOwned, String name,
> Boolean& createdNew, MutexSecurity mutexSecurity)
>à System.Threading.Mutex..ctor(Boolean initiallyOwned, String name,
> Boolean& createdNew)
>à log4net.Appender.RollingFileAppender.ActivateOptions()
>à
> log4net.Repository.Hierarchy.XmlHierarchyConfigurator.ParseAppender(XmlElement
> appenderElement)
> log4net:ERROR Appender named [RollingLogFileAppender] not found.
> {code}
> {code:title=working case corresponding trace}
> log4net: Searched for existing files in [D:\Logs]
> log4net: curSizeRollBackups starts at [0]
> log4net: Opening file for writing [D:\Logs\2016.02.26-App1.log] append [True]
> log4net: Created Appender [RollingLogFileAppender]
> log4net: Adding appender named [RollingLogFileAppender] to logger [root].
> {code}
> (All other trace lines are identical)
> {code:xml|title=Application appender configuration}
>type="log4net.Appender.RollingFileAppender">
>
>
>
>
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LOG4NET-506) RollingFileAppender locking log folder in some cases
[
https://issues.apache.org/jira/browse/LOG4NET-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15194859#comment-15194859
]
Dominik Psenner commented on LOG4NET-506:
-
Thanks Frederic for reporting this issue. This actually makes sense. There is a
lock that should prevent race conditions and this actually creates a named
mutex based on the filename. There is a logic that generates a safe name for
that mutex based on the file pattern configured in the rolling file appender
and it would seem that this generator is not smart enough to deal with this
case.
> RollingFileAppender locking log folder in some cases
>
>
> Key: LOG4NET-506
> URL: https://issues.apache.org/jira/browse/LOG4NET-506
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 1.2.15
> Environment: Windows Server 2008 R2, Windows Server 2012 R2
>Reporter: Frédéric Delaporte
>Priority: Minor
> Attachments: AppAlone_log4net.txt, AppConcurrently_log4net.txt
>
>
> *Abstract:*
> In some configuration cases, the rolling file appender may issue a mutex lock
> on the folder name. If more than one processes try to do that with different
> executing identity, only one will be able to log to its specific logs file.
> The others will no more be able to do it.
> *Repro:*
> Many applications run on the same server.
> All run under different windows identity.
> All do log through {{RollingFileAppender}} to D:\Logs\ (value of {{file}}
> configuration node) to their own file log (filename specific to each
> application through {{datePattern}} configuration node, like
> {{.MM.dd'-App1.log'}}, {{.MM.dd'-App2.log'}}, ...).
> They log through {{AdoNetAppender}} too.
> Since having upgraded Log4Net from 1.2.13 to 1.2.15 on some applications,
> they cease being able to all log to D:\Logs\. Only one of them still do log,
> depending on which have started first. SQL logs still work. Non upgraded
> applications are still able to log to D:\Logs\, whatever their start order
> have been.
> *Diagnosis info:*
> Activating log4net debug trace on an application, and comparing failure cases
> to working cases, yields following diff:
> {code:title=failing case debug trace}
> log4net:ERROR Could not create Appender [RollingLogFileAppender] of type
> [log4net.Appender.RollingFileAppender]. Reported error follows.
> System.UnauthorizedAccessException: Access to path 'D__Logs_' denied.
> (Translated from french)
>à System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
>à System.Threading.Mutex.MutexTryCodeHelper.MutexTryCode(Object userData)
>à
> System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode
> code, CleanupCode backoutCode, Object userData)
>à System.Threading.Mutex.CreateMutexWithGuaranteedCleanup(Boolean
> initiallyOwned, String name, Boolean& createdNew, SECURITY_ATTRIBUTES
> secAttrs)
>à System.Threading.Mutex..ctor(Boolean initiallyOwned, String name,
> Boolean& createdNew, MutexSecurity mutexSecurity)
>à System.Threading.Mutex..ctor(Boolean initiallyOwned, String name,
> Boolean& createdNew)
>à log4net.Appender.RollingFileAppender.ActivateOptions()
>à
> log4net.Repository.Hierarchy.XmlHierarchyConfigurator.ParseAppender(XmlElement
> appenderElement)
> log4net:ERROR Appender named [RollingLogFileAppender] not found.
> {code}
> {code:title=working case corresponding trace}
> log4net: Searched for existing files in [D:\Logs]
> log4net: curSizeRollBackups starts at [0]
> log4net: Opening file for writing [D:\Logs\2016.02.26-App1.log] append [True]
> log4net: Created Appender [RollingLogFileAppender]
> log4net: Adding appender named [RollingLogFileAppender] to logger [root].
> {code}
> (All other trace lines are identical)
> {code:xml|title=Application appender configuration}
>type="log4net.Appender.RollingFileAppender">
>
>
>
>
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (LOG4NET-504) Exception mode during configuration
[
https://issues.apache.org/jira/browse/LOG4NET-504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominik Psenner closed LOG4NET-504.
---
Resolution: Won't Fix
Assignee: Dominik Psenner
This issue is documented here:
https://logging.apache.org/log4net/release/faq.html#trouble-file-perm
The logging framework should under no circumstance throw exceptions that could
crash the applications. Such exceptions are treated as serious bugs:
https://logging.apache.org/log4net/release/faq.html#reliability
Because of the afore mentioned reasons I'm closing the issue as won't fix.
> Exception mode during configuration
> ---
>
> Key: LOG4NET-504
> URL: https://issues.apache.org/jira/browse/LOG4NET-504
> Project: Log4net
> Issue Type: Wish
> Components: Other
>Reporter: Gregory Zak
>Assignee: Dominik Psenner
>Priority: Minor
>
> When getting started with log4net configuration for the first time, it would
> be extremely helpful to have a mode where a call to one of the various
> {{.Configure()}} methods would throw exceptions as they were encountered,
> rather than silently sailing past them / aborting.
> I'm currently absolutely stuck with [this
> issue|http://stackoverflow.com/questions/35103249/log4net-not-writing-to-log-file]
> on stackoverflow, and I've already tried all the expected suggestions
> (enable trace debugging, check for config errors explicitly, etc etc), but
> I'm still staring at a silent failure (the most frustrating kind of failure)
> unable to make any progress.
> Don't make me switch to NLog guys!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LOG4NET-505) AdoNetAppender with Npgsql data provider
[ https://issues.apache.org/jira/browse/LOG4NET-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15145328#comment-15145328 ] Dominik Psenner commented on LOG4NET-505: - It would be great if you could write a patch that fixes the issue or a test that reproduces the issue. > AdoNetAppender with Npgsql data provider > > > Key: LOG4NET-505 > URL: https://issues.apache.org/jira/browse/LOG4NET-505 > Project: Log4net > Issue Type: Bug > Components: Appenders >Affects Versions: 1.2.15 >Reporter: Vadim Ivanou > > I'm trying to use AdoNetAppender with postgresql database and Npgsql data > provider 3.0.x. Unfortunately it throws an exception in SendBuffer method > while executing dbCmd.Prepare(). I believe the reason for that is that Npgsql > requires all Parameters to be present in a command before calling Prepare > method. I created my own adapter that overrides SendBuffer method and > populates sql command parameters before Prepare and it worked fine. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LOG4NET-504) Exception mode during configuration
[
https://issues.apache.org/jira/browse/LOG4NET-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15130107#comment-15130107
]
Dominik Psenner commented on LOG4NET-504:
-
You can enable log4net's internal logging (see faq). Doesn't that help you
figure out why things do not work as expected? Further I've reduced the
priority of this issue.
> Exception mode during configuration
> ---
>
> Key: LOG4NET-504
> URL: https://issues.apache.org/jira/browse/LOG4NET-504
> Project: Log4net
> Issue Type: Wish
> Components: Other
>Reporter: Gregory Zak
>Priority: Minor
>
> When getting started with log4net configuration for the first time, it would
> be extremely helpful to have a mode where a call to one of the various
> {{.Configure()}} methods would throw exceptions as they were encountered,
> rather than silently sailing past them / aborting.
> I'm currently absolutely stuck with [this
> issue|http://stackoverflow.com/questions/35103249/log4net-not-writing-to-log-file]
> on stackoverflow, and I've already tried all the expected suggestions
> (enable trace debugging, check for config errors explicitly, etc etc), but
> I'm still staring at a silent failure (the most frustrating kind of failure)
> unable to make any progress.
> Don't make me switch to NLog guys!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (LOG4NET-502) Windows 2012 compatibility
[ https://issues.apache.org/jira/browse/LOG4NET-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominik Psenner closed LOG4NET-502. --- Resolution: Invalid Assignee: Dominik Psenner Hi Sanjay, there are many more factors and you should try your migration before doing it. Cheers > Windows 2012 compatibility > -- > > Key: LOG4NET-502 > URL: https://issues.apache.org/jira/browse/LOG4NET-502 > Project: Log4net > Issue Type: New Feature > Components: Builds >Affects Versions: 1.2.10 > Environment: Windows 2012 >Reporter: sanjay pulapotta >Assignee: Dominik Psenner >Priority: Minor > > Hi Team, > We are using 'Log4Net-1.2.10' currently for our production environment which > is on a Windows 2008 (64 bit) box. > We plan to upgrade our servers to Windows 2012 (64 bit) with IIS 8.0. > Kindly let me know whether 'Log4Net-1.2.10' is compatible with Windows 2012 > (64 bit) servers. > Thanks in Advance > Sanjay -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LOG4NET-500) 1.2.15 RollingFileAppender is 60% slower than 1.2.11
[
https://issues.apache.org/jira/browse/LOG4NET-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15105024#comment-15105024
]
Dominik Psenner commented on LOG4NET-500:
-
Apologies for not getting back to you earlier, I have been busy.
This is well understandable. LOG4NET-487 is exactly about that and that story
should improve rolling by making the rolling lock strategy configurable. In the
case where only one process rolls one could get better performance by
configuring the rolling file appender to not lock the process of rolling. At
the moment rolling is always locked to prevent race conditions. If you happen
to need this anytime soon, patches receive a warm welcome! :-)
> 1.2.15 RollingFileAppender is 60% slower than 1.2.11
>
>
> Key: LOG4NET-500
> URL: https://issues.apache.org/jira/browse/LOG4NET-500
> Project: Log4net
> Issue Type: Improvement
> Components: Appenders
>Affects Versions: 1.2.15
> Environment: 4.5.2 .NET Framework
>Reporter: Larry Aucoin
>Assignee: Dominik Psenner
>Priority: Minor
>
> 1.2.15 RollingFileAppender is 60% slower than 1.2.11. I am using the
> following code and app.config file to test the 2 versions.
> APP.CONFIG
>
>
>
>
> type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
>
>
>
>
>
>
> type="log4net.Appender.RollingFileAppender, log4net">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> CODE:
>
> using System;
> using System.Collections.Generic;
> using System.ComponentModel;
> using System.Data;
> using System.Drawing;
> using System.Linq;
> using System.Text;
> using System.Threading.Tasks;
> using System.Windows.Forms;
> using System.Diagnostics;
> using log4net.Core;
> namespace TraceLoggingTest
> {
> public partial class Form1 : Form
> {
> public log4net.ILog Logger;
> public Form1()
> {
> InitializeComponent();
> Logger = log4net.LogManager.GetLogger("Form1");
> log4net.Config.XmlConfigurator.Configure();
> }
> private void btnTest_Click(object sender, EventArgs e)
> {
>
> Logger.Debug("=");
> Stopwatch sw = new Stopwatch();
> sw.Start();
> for (int i = 0; i < 5000; i++)
> {
> Logger.Debug("Write item [" + i.ToString() + "]...");
> }
> sw.Stop();
> Logger.Debug("TOTAL TIME [" + sw.ElapsedMilliseconds.ToString() +
> "]");
> this.lblTime.Text = sw.ElapsedMilliseconds.ToString() + " ms";
>
> Logger.Debug("=");
> }
> }
> }
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LOG4NET-487) Control mutex type
[
https://issues.apache.org/jira/browse/LOG4NET-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15105049#comment-15105049
]
Dominik Psenner commented on LOG4NET-487:
-
Here comes a small refinement of the locking options:
1. global (all processes, even ones that are not on the same machine should be
synchronized so that only one process on one machine rolls): this will be hard
to implement
2. local (all processes on the same machine are synchronized so that one of
them rolls): this is a mutex lock and the way it works at the moment
3. thread (it is assumed that there is only one process that logs and rolls): a
"lock (instanceOfObject) {}" could to the job
4. no lock (no locking required as there is only one process and thread who
logs and rolls): no locks should happen for maximum performance
At the time of writing, only option 2. and 4. make sense to be implemented.
> Control mutex type
> --
>
> Key: LOG4NET-487
> URL: https://issues.apache.org/jira/browse/LOG4NET-487
> Project: Log4net
> Issue Type: Improvement
> Components: Appenders
>Affects Versions: 1.2.14, 1.3.0
>Reporter: NN
>Assignee: Dominik Psenner
>
> The only missing feature is an option for choosing Local (per session) or
> Global (per machine) mutex.
> The current code just uses the filename for mutex which good but it always
> makes a local one, so if you have two sessions you cannot synchronize them.
> Default is Local for backward compatibility.
> See Note in:
> https://msdn.microsoft.com/en-us/library/system.threading.mutex%28v=vs.110%29.aspx
>
> I think it can be an option like
>
> or something like that.
> It also applies to FileAppender mutex .
>
>
>
> See issue #485 for reference.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LOG4NET-500) 1.2.15 RollingFileAppender is 60% slower than 1.2.11
[
https://issues.apache.org/jira/browse/LOG4NET-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominik Psenner updated LOG4NET-500:
Priority: Minor (was: Major)
> 1.2.15 RollingFileAppender is 60% slower than 1.2.11
>
>
> Key: LOG4NET-500
> URL: https://issues.apache.org/jira/browse/LOG4NET-500
> Project: Log4net
> Issue Type: Improvement
> Components: Appenders
>Affects Versions: 1.2.15
> Environment: 4.5.2 .NET Framework
>Reporter: Larry Aucoin
>Priority: Minor
>
> 1.2.15 RollingFileAppender is 60% slower than 1.2.11. I am using the
> following code and app.config file to test the 2 versions.
> APP.CONFIG
>
>
>
>
> type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
>
>
>
>
>
>
> type="log4net.Appender.RollingFileAppender, log4net">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> CODE:
>
> using System;
> using System.Collections.Generic;
> using System.ComponentModel;
> using System.Data;
> using System.Drawing;
> using System.Linq;
> using System.Text;
> using System.Threading.Tasks;
> using System.Windows.Forms;
> using System.Diagnostics;
> using log4net.Core;
> namespace TraceLoggingTest
> {
> public partial class Form1 : Form
> {
> public log4net.ILog Logger;
> public Form1()
> {
> InitializeComponent();
> Logger = log4net.LogManager.GetLogger("Form1");
> log4net.Config.XmlConfigurator.Configure();
> }
> private void btnTest_Click(object sender, EventArgs e)
> {
>
> Logger.Debug("=");
> Stopwatch sw = new Stopwatch();
> sw.Start();
> for (int i = 0; i < 5000; i++)
> {
> Logger.Debug("Write item [" + i.ToString() + "]...");
> }
> sw.Stop();
> Logger.Debug("TOTAL TIME [" + sw.ElapsedMilliseconds.ToString() +
> "]");
> this.lblTime.Text = sw.ElapsedMilliseconds.ToString() + " ms";
>
> Logger.Debug("=");
> }
> }
> }
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LOG4NET-500) 1.2.15 RollingFileAppender is 60% slower than 1.2.11
[
https://issues.apache.org/jira/browse/LOG4NET-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15085680#comment-15085680
]
Dominik Psenner commented on LOG4NET-500:
-
Does your application run in multiple processes and do the applications log
into the same files?
> 1.2.15 RollingFileAppender is 60% slower than 1.2.11
>
>
> Key: LOG4NET-500
> URL: https://issues.apache.org/jira/browse/LOG4NET-500
> Project: Log4net
> Issue Type: Improvement
> Components: Appenders
>Affects Versions: 1.2.15
> Environment: 4.5.2 .NET Framework
>Reporter: Larry Aucoin
>
> 1.2.15 RollingFileAppender is 60% slower than 1.2.11. I am using the
> following code and app.config file to test the 2 versions.
> APP.CONFIG
>
>
>
>
> type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
>
>
>
>
>
>
> type="log4net.Appender.RollingFileAppender, log4net">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> CODE:
>
> using System;
> using System.Collections.Generic;
> using System.ComponentModel;
> using System.Data;
> using System.Drawing;
> using System.Linq;
> using System.Text;
> using System.Threading.Tasks;
> using System.Windows.Forms;
> using System.Diagnostics;
> using log4net.Core;
> namespace TraceLoggingTest
> {
> public partial class Form1 : Form
> {
> public log4net.ILog Logger;
> public Form1()
> {
> InitializeComponent();
> Logger = log4net.LogManager.GetLogger("Form1");
> log4net.Config.XmlConfigurator.Configure();
> }
> private void btnTest_Click(object sender, EventArgs e)
> {
>
> Logger.Debug("=");
> Stopwatch sw = new Stopwatch();
> sw.Start();
> for (int i = 0; i < 5000; i++)
> {
> Logger.Debug("Write item [" + i.ToString() + "]...");
> }
> sw.Stop();
> Logger.Debug("TOTAL TIME [" + sw.ElapsedMilliseconds.ToString() +
> "]");
> this.lblTime.Text = sw.ElapsedMilliseconds.ToString() + " ms";
>
> Logger.Debug("=");
> }
> }
> }
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LOG4NET-500) 1.2.15 RollingFileAppender is 60% slower than 1.2.11
[
https://issues.apache.org/jira/browse/LOG4NET-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15085744#comment-15085744
]
Dominik Psenner commented on LOG4NET-500:
-
Then you will have to live with the performance penalty. Without the locking
mutex, rolling has a race condition and may fail from time to time.
If you cannot live with the performance of the rolling file appender you will
have to use another appender. A good choice could be a buffering database
appender.
> 1.2.15 RollingFileAppender is 60% slower than 1.2.11
>
>
> Key: LOG4NET-500
> URL: https://issues.apache.org/jira/browse/LOG4NET-500
> Project: Log4net
> Issue Type: Improvement
> Components: Appenders
>Affects Versions: 1.2.15
> Environment: 4.5.2 .NET Framework
>Reporter: Larry Aucoin
>
> 1.2.15 RollingFileAppender is 60% slower than 1.2.11. I am using the
> following code and app.config file to test the 2 versions.
> APP.CONFIG
>
>
>
>
> type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
>
>
>
>
>
>
> type="log4net.Appender.RollingFileAppender, log4net">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> CODE:
>
> using System;
> using System.Collections.Generic;
> using System.ComponentModel;
> using System.Data;
> using System.Drawing;
> using System.Linq;
> using System.Text;
> using System.Threading.Tasks;
> using System.Windows.Forms;
> using System.Diagnostics;
> using log4net.Core;
> namespace TraceLoggingTest
> {
> public partial class Form1 : Form
> {
> public log4net.ILog Logger;
> public Form1()
> {
> InitializeComponent();
> Logger = log4net.LogManager.GetLogger("Form1");
> log4net.Config.XmlConfigurator.Configure();
> }
> private void btnTest_Click(object sender, EventArgs e)
> {
>
> Logger.Debug("=");
> Stopwatch sw = new Stopwatch();
> sw.Start();
> for (int i = 0; i < 5000; i++)
> {
> Logger.Debug("Write item [" + i.ToString() + "]...");
> }
> sw.Stop();
> Logger.Debug("TOTAL TIME [" + sw.ElapsedMilliseconds.ToString() +
> "]");
> this.lblTime.Text = sw.ElapsedMilliseconds.ToString() + " ms";
>
> Logger.Debug("=");
> }
> }
> }
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (LOG4NET-500) 1.2.15 RollingFileAppender is 60% slower than 1.2.11
[
https://issues.apache.org/jira/browse/LOG4NET-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15081809#comment-15081809
]
Dominik Psenner edited comment on LOG4NET-500 at 1/4/16 9:12 PM:
-
This is probably related to how we fixed LOG4NET-485. Making the roll lock
configurable would probably improve the performance penalty, but one could
check if the lock gets acquired more often than necessary.
Is the performance a problem?
was (Author: nachbarslumpi):
This is probably related to how we fixed LOG4NET-485. Making the roll lock
configurable would probably improve the performance penalty, but one could
check if the lock gets acquired more often than necessary.
> 1.2.15 RollingFileAppender is 60% slower than 1.2.11
>
>
> Key: LOG4NET-500
> URL: https://issues.apache.org/jira/browse/LOG4NET-500
> Project: Log4net
> Issue Type: Improvement
> Components: Appenders
>Affects Versions: 1.2.15
> Environment: 4.5.2 .NET Framework
>Reporter: Larry Aucoin
>
> 1.2.15 RollingFileAppender is 60% slower than 1.2.11. I am using the
> following code and app.config file to test the 2 versions.
> APP.CONFIG
>
>
>
>
> type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
>
>
>
>
>
>
> type="log4net.Appender.RollingFileAppender, log4net">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> CODE:
>
> using System;
> using System.Collections.Generic;
> using System.ComponentModel;
> using System.Data;
> using System.Drawing;
> using System.Linq;
> using System.Text;
> using System.Threading.Tasks;
> using System.Windows.Forms;
> using System.Diagnostics;
> using log4net.Core;
> namespace TraceLoggingTest
> {
> public partial class Form1 : Form
> {
> public log4net.ILog Logger;
> public Form1()
> {
> InitializeComponent();
> Logger = log4net.LogManager.GetLogger("Form1");
> log4net.Config.XmlConfigurator.Configure();
> }
> private void btnTest_Click(object sender, EventArgs e)
> {
>
> Logger.Debug("=");
> Stopwatch sw = new Stopwatch();
> sw.Start();
> for (int i = 0; i < 5000; i++)
> {
> Logger.Debug("Write item [" + i.ToString() + "]...");
> }
> sw.Stop();
> Logger.Debug("TOTAL TIME [" + sw.ElapsedMilliseconds.ToString() +
> "]");
> this.lblTime.Text = sw.ElapsedMilliseconds.ToString() + " ms";
>
> Logger.Debug("=");
> }
> }
> }
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LOG4NET-500) 1.2.15 RollingFileAppender is 60% slower than 1.2.11
[
https://issues.apache.org/jira/browse/LOG4NET-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15081809#comment-15081809
]
Dominik Psenner commented on LOG4NET-500:
-
This is probably related to how we fixed LOG4NET-485. Making the roll lock
configurable would probably improve the performance penalty, but one could
check if the lock gets acquired more often than necessary.
> 1.2.15 RollingFileAppender is 60% slower than 1.2.11
>
>
> Key: LOG4NET-500
> URL: https://issues.apache.org/jira/browse/LOG4NET-500
> Project: Log4net
> Issue Type: Improvement
> Components: Appenders
>Affects Versions: 1.2.15
> Environment: 4.5.2 .NET Framework
>Reporter: Larry Aucoin
>
> 1.2.15 RollingFileAppender is 60% slower than 1.2.11. I am using the
> following code and app.config file to test the 2 versions.
> APP.CONFIG
>
>
>
>
> type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
>
>
>
>
>
>
> type="log4net.Appender.RollingFileAppender, log4net">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> CODE:
>
> using System;
> using System.Collections.Generic;
> using System.ComponentModel;
> using System.Data;
> using System.Drawing;
> using System.Linq;
> using System.Text;
> using System.Threading.Tasks;
> using System.Windows.Forms;
> using System.Diagnostics;
> using log4net.Core;
> namespace TraceLoggingTest
> {
> public partial class Form1 : Form
> {
> public log4net.ILog Logger;
> public Form1()
> {
> InitializeComponent();
> Logger = log4net.LogManager.GetLogger("Form1");
> log4net.Config.XmlConfigurator.Configure();
> }
> private void btnTest_Click(object sender, EventArgs e)
> {
>
> Logger.Debug("=");
> Stopwatch sw = new Stopwatch();
> sw.Start();
> for (int i = 0; i < 5000; i++)
> {
> Logger.Debug("Write item [" + i.ToString() + "]...");
> }
> sw.Stop();
> Logger.Debug("TOTAL TIME [" + sw.ElapsedMilliseconds.ToString() +
> "]");
> this.lblTime.Text = sw.ElapsedMilliseconds.ToString() + " ms";
>
> Logger.Debug("=");
> }
> }
> }
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (LOG4NET-398) SerializationException after setting a LogicalThreadContext property
[ https://issues.apache.org/jira/browse/LOG4NET-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15061999#comment-15061999 ] Dominik Psenner edited comment on LOG4NET-398 at 12/17/15 12:47 PM: Only classes derived from MarshalByRefObj are allowed to cross application domains. I'm still wondering why the ReadOnlyPropertiesDictionary crosses application domains. A class should not travel between application domains "by magic" as both application domains do not share the same memory and are virtually two processes executing in one process (this really sounds strange, yeah). Not even static readonly classes / properties are the same across two application domains.. So long as the root cause is not found I do not think that this patch should be applied. was (Author: nachbarslumpi): Only classes derived from MarshalByRefObj are allowed to cross application domains. I'm still wondering why the ReadOnlyPropertiesDictionary crosses application domains. A class should not travel between application domains "by magic" as both application domains do not share the same memory and are virtually two processes executing in one process (this really sounds strange, yeah). So long as the root cause is not found I do not think that this patch should be applied. > SerializationException after setting a LogicalThreadContext property > > > Key: LOG4NET-398 > URL: https://issues.apache.org/jira/browse/LOG4NET-398 > Project: Log4net > Issue Type: Task > Components: Core >Affects Versions: 1.2.12 > Environment: Visual Studio 2010 >Reporter: Thomas Meum >Priority: Minor > Labels: triaged > Attachments: log4net.zip > > > I have found that accessing Page.Request.Url after setting a > LogicalThreadContext property causes a SerializationException with the > following message: Type is not resolved for member > 'log4net.Util.PropertiesDictionary,log4net, Version=1.2.12.0, > Culture=neutral, PublicKeyToken=669e0ddf0bb1aa2a'. > I have been able to reproduce the problem on two different machines with the > following steps: > 1. Create a new ASP.NET Empty Web Application > 2. Add a reference to log4net.dll > 3. Add a new Web Form > 4. Add the following code to Page_Load: > log4net.LogicalThreadContext.Properties["Test"] = 1; > Uri url = Request.Url; > 5. Hit F5 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LOG4NET-398) SerializationException after setting a LogicalThreadContext property
[ https://issues.apache.org/jira/browse/LOG4NET-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15061999#comment-15061999 ] Dominik Psenner commented on LOG4NET-398: - Only classes derived from MarshalByRefObj are allowed to cross application domains. I'm still wondering why the ReadOnlyPropertiesDictionary crosses application domains. A class should not travel between application domains "by magic" as both application domains do not share the same memory and are virtually two processes executing in one process (this really sounds strange, yeah). So long as the root cause is not found I do not think that this patch should be applied. > SerializationException after setting a LogicalThreadContext property > > > Key: LOG4NET-398 > URL: https://issues.apache.org/jira/browse/LOG4NET-398 > Project: Log4net > Issue Type: Task > Components: Core >Affects Versions: 1.2.12 > Environment: Visual Studio 2010 >Reporter: Thomas Meum >Priority: Minor > Labels: triaged > Attachments: log4net.zip > > > I have found that accessing Page.Request.Url after setting a > LogicalThreadContext property causes a SerializationException with the > following message: Type is not resolved for member > 'log4net.Util.PropertiesDictionary,log4net, Version=1.2.12.0, > Culture=neutral, PublicKeyToken=669e0ddf0bb1aa2a'. > I have been able to reproduce the problem on two different machines with the > following steps: > 1. Create a new ASP.NET Empty Web Application > 2. Add a reference to log4net.dll > 3. Add a new Web Form > 4. Add the following code to Page_Load: > log4net.LogicalThreadContext.Properties["Test"] = 1; > Uri url = Request.Url; > 5. Hit F5 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LOG4NET-496) RollingFileAppender.ActivateOptions throws UnauthorizedAccessException
[
https://issues.apache.org/jira/browse/LOG4NET-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15057612#comment-15057612
]
Dominik Psenner commented on LOG4NET-496:
-
I do not think that you have to grant permissions to the log directory as a
mutex is requested operating system wide. The second process requesting the
mutex throws an UnauthorizedAccessException because the mutex already exists
and the process does not have the mutex privilege SYNCHRONIZE|MUTEX_MODIFY or
MUTEX_ALL respectively. I'm not that familiar with cloud services, but maybe
there's some magic switch or configuration option that allows you to configure
this for your application?
Another option could be to try to create the mutex and if that fails with an
UnauthorizedAccessException we could try to open the existing mutex. But this
feels hacky and it would introduce a race condition if the mutex exists but is
released by the first process before the second process can open it.
> RollingFileAppender.ActivateOptions throws UnauthorizedAccessException
> --
>
> Key: LOG4NET-496
> URL: https://issues.apache.org/jira/browse/LOG4NET-496
> Project: Log4net
> Issue Type: Bug
>Affects Versions: 1.2.14
>Reporter: Fabian Pachner
>
> We upgraded our Azure cloud service project from log4net 1.2.13 to 1.2.14 and
> received the following exception when the web roles are starting up:
> {code}
> System.UnauthorizedAccessException: Access to the path
> 'C__Resources_directory_9b9a1e064b78414281c81f861d0634b0.Role.Web.Frontend.DiagnosticStore_LogFiles_UI_UI_0'
> is denied.
>at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
>at System.Threading.Mutex.MutexTryCodeHelper.MutexTryCode(Object userData)
>at
> System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode
> code, CleanupCode backoutCode, Object userData)
>at System.Threading.Mutex.CreateMutexWithGuaranteedCleanup(Boolean
> initiallyOwned, String name, Boolean& createdNew, SECURITY_ATTRIBUTES
> secAttrs)
>at System.Threading.Mutex..ctor(Boolean initiallyOwned, String name,
> Boolean& createdNew, MutexSecurity mutexSecurity)
>at System.Threading.Mutex..ctor(Boolean initiallyOwned, String name,
> Boolean& createdNew)
>at log4net.Appender.RollingFileAppender.ActivateOptions()
>at Base.Logging.AzureFileLogAppender.ActivateOptions() in
> j:\Source\Commons\Logging\AzureFileLogAppender.cs:line 95
>at
> log4net.Repository.Hierarchy.XmlHierarchyConfigurator.ParseAppender(XmlElement
> appenderElement)
> {code}
> This affects the w3wp process of the web role. A consequence of this is that
> file logging isn't working for that process. We didn't have that exception
> with log4net 1.2.13 and recognized there was a change in 1.2.14 in
> RollingFileAppender.ActivateOptions: A mutex is created there and that seems
> to lead to the mentioned exception.
> Can you tell us whether it is likely that this issue was already fixed with
> 1.2.15? And if so, when will this version be available via Nuget package?
> Thank you!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (LOG4NET-496) RollingFileAppender.ActivateOptions throws UnauthorizedAccessException
[
https://issues.apache.org/jira/browse/LOG4NET-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15052496#comment-15052496
]
Dominik Psenner edited comment on LOG4NET-496 at 12/11/15 9:20 AM:
---
I thought a little bit about this and I wonder why you are using a rolling file
appender in a cloud scenario. If I do not know on which machine my code
executes, a file appender is the wrong appender for this usecase, isn't it?
was (Author: nachbarslumpi):
I thought a little bit about this and what I am wondering about is why you are
using a rolling file appender in a cloud scenario. If I do not know on which
machine my code executes, a file appender is the wrong appender for this
usecase, isn't it?
> RollingFileAppender.ActivateOptions throws UnauthorizedAccessException
> --
>
> Key: LOG4NET-496
> URL: https://issues.apache.org/jira/browse/LOG4NET-496
> Project: Log4net
> Issue Type: Bug
>Affects Versions: 1.2.14
>Reporter: Fabian Pachner
>
> We upgraded our Azure cloud service project from log4net 1.2.13 to 1.2.14 and
> received the following exception when the web roles are starting up:
> {code}
> System.UnauthorizedAccessException: Access to the path
> 'C__Resources_directory_9b9a1e064b78414281c81f861d0634b0.Role.Web.Frontend.DiagnosticStore_LogFiles_UI_UI_0'
> is denied.
>at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
>at System.Threading.Mutex.MutexTryCodeHelper.MutexTryCode(Object userData)
>at
> System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode
> code, CleanupCode backoutCode, Object userData)
>at System.Threading.Mutex.CreateMutexWithGuaranteedCleanup(Boolean
> initiallyOwned, String name, Boolean& createdNew, SECURITY_ATTRIBUTES
> secAttrs)
>at System.Threading.Mutex..ctor(Boolean initiallyOwned, String name,
> Boolean& createdNew, MutexSecurity mutexSecurity)
>at System.Threading.Mutex..ctor(Boolean initiallyOwned, String name,
> Boolean& createdNew)
>at log4net.Appender.RollingFileAppender.ActivateOptions()
>at Base.Logging.AzureFileLogAppender.ActivateOptions() in
> j:\Source\Commons\Logging\AzureFileLogAppender.cs:line 95
>at
> log4net.Repository.Hierarchy.XmlHierarchyConfigurator.ParseAppender(XmlElement
> appenderElement)
> {code}
> This affects the w3wp process of the web role. A consequence of this is that
> file logging isn't working for that process. We didn't have that exception
> with log4net 1.2.13 and recognized there was a change in 1.2.14 in
> RollingFileAppender.ActivateOptions: A mutex is created there and that seems
> to lead to the mentioned exception.
> Can you tell us whether it is likely that this issue was already fixed with
> 1.2.15? And if so, when will this version be available via Nuget package?
> Thank you!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LOG4NET-496) RollingFileAppender.ActivateOptions throws UnauthorizedAccessException
[
https://issues.apache.org/jira/browse/LOG4NET-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15052496#comment-15052496
]
Dominik Psenner commented on LOG4NET-496:
-
I thought a little bit about this and what I am wondering about is why you are
using a rolling file appender in a cloud scenario. If I do not know on which
machine my code executes, a file appender is the wrong appender for this
usecase, isn't it?
> RollingFileAppender.ActivateOptions throws UnauthorizedAccessException
> --
>
> Key: LOG4NET-496
> URL: https://issues.apache.org/jira/browse/LOG4NET-496
> Project: Log4net
> Issue Type: Bug
>Affects Versions: 1.2.14
>Reporter: Fabian Pachner
>
> We upgraded our Azure cloud service project from log4net 1.2.13 to 1.2.14 and
> received the following exception when the web roles are starting up:
> {code}
> System.UnauthorizedAccessException: Access to the path
> 'C__Resources_directory_9b9a1e064b78414281c81f861d0634b0.Role.Web.Frontend.DiagnosticStore_LogFiles_UI_UI_0'
> is denied.
>at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
>at System.Threading.Mutex.MutexTryCodeHelper.MutexTryCode(Object userData)
>at
> System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode
> code, CleanupCode backoutCode, Object userData)
>at System.Threading.Mutex.CreateMutexWithGuaranteedCleanup(Boolean
> initiallyOwned, String name, Boolean& createdNew, SECURITY_ATTRIBUTES
> secAttrs)
>at System.Threading.Mutex..ctor(Boolean initiallyOwned, String name,
> Boolean& createdNew, MutexSecurity mutexSecurity)
>at System.Threading.Mutex..ctor(Boolean initiallyOwned, String name,
> Boolean& createdNew)
>at log4net.Appender.RollingFileAppender.ActivateOptions()
>at Base.Logging.AzureFileLogAppender.ActivateOptions() in
> j:\Source\Commons\Logging\AzureFileLogAppender.cs:line 95
>at
> log4net.Repository.Hierarchy.XmlHierarchyConfigurator.ParseAppender(XmlElement
> appenderElement)
> {code}
> This affects the w3wp process of the web role. A consequence of this is that
> file logging isn't working for that process. We didn't have that exception
> with log4net 1.2.13 and recognized there was a change in 1.2.14 in
> RollingFileAppender.ActivateOptions: A mutex is created there and that seems
> to lead to the mentioned exception.
> Can you tell us whether it is likely that this issue was already fixed with
> 1.2.15? And if so, when will this version be available via Nuget package?
> Thank you!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (LOG4NET-495) Error when BufferSize is >1, parameter already defined
[
https://issues.apache.org/jira/browse/LOG4NET-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominik Psenner closed LOG4NET-495.
---
Great, thanks.
> Error when BufferSize is >1, parameter already defined
> --
>
> Key: LOG4NET-495
> URL: https://issues.apache.org/jira/browse/LOG4NET-495
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 1.2.15
> Environment: Windows 7
>Reporter: Rick Burge
>Assignee: Dominik Psenner
> Fix For: 1.2.15
>
>
> Downloaded the subject revision 1714197 in order to get the
> ADONetAppender_SqlServer appender to work as this revision corrected a
> problem. The appender began to work. However if the BufferSize was increased
> to >1 an error was reported that the parameter @log_date was already defined.
> The error appears to be in SendBuffer. Because the IDbCommand dbCmd is being
> reused inside the foreach (LoggingEvent e in Events), each time the
> param.Prepare(dbCmd) is called for the same appender it will attempt to add a
> parameter that has already been added.
> My local solution was to clear the commands parameter list prior to adding
> the preparing the paramters:
>foreach (LoggingEvent e in events)
> {
> dbCmd.Parameters.Clear(); //*added this
> line*
> // Set the parameter values
> foreach (AdoNetAppenderParameter param in
> m_parameters)
> {
> param.Prepare(dbCmd);
> param.FormatValue(dbCmd, e);
> }
> // Execute the query
> dbCmd.ExecuteNonQuery();
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (LOG4NET-495) Error when BufferSize is >1, parameter already defined
[
https://issues.apache.org/jira/browse/LOG4NET-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominik Psenner reassigned LOG4NET-495:
---
Assignee: Dominik Psenner
> Error when BufferSize is >1, parameter already defined
> --
>
> Key: LOG4NET-495
> URL: https://issues.apache.org/jira/browse/LOG4NET-495
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 1.2.15
> Environment: Windows 7
>Reporter: Rick Burge
>Assignee: Dominik Psenner
>
> Downloaded the subject revision 1714197 in order to get the
> ADONetAppender_SqlServer appender to work as this revision corrected a
> problem. The appender began to work. However if the BufferSize was increased
> to >1 an error was reported that the parameter @log_date was already defined.
> The error appears to be in SendBuffer. Because the IDbCommand dbCmd is being
> reused inside the foreach (LoggingEvent e in Events), each time the
> param.Prepare(dbCmd) is called for the same appender it will attempt to add a
> parameter that has already been added.
> My local solution was to clear the commands parameter list prior to adding
> the preparing the paramters:
>foreach (LoggingEvent e in events)
> {
> dbCmd.Parameters.Clear(); //*added this
> line*
> // Set the parameter values
> foreach (AdoNetAppenderParameter param in
> m_parameters)
> {
> param.Prepare(dbCmd);
> param.FormatValue(dbCmd, e);
> }
> // Execute the query
> dbCmd.ExecuteNonQuery();
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (LOG4NET-489) AdoNetAppender fails after upgrade to 2.0.4
[ https://issues.apache.org/jira/browse/LOG4NET-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15030189#comment-15030189 ] Dominik Psenner edited comment on LOG4NET-489 at 11/27/15 7:38 PM: --- Hi Marek, I understand your point, but we will not provide unofficial binaries to be used in production environments. Please download 1.2.13 from the archives or build the latest trunk from source. Cheers was (Author: nachbarslumpi): Hi Marek, I understand your point, but we will not provide unofficial binaries to be used in production environments. Please download 1.2.13 from the archives or build it from source. Cheers > AdoNetAppender fails after upgrade to 2.0.4 > --- > > Key: LOG4NET-489 > URL: https://issues.apache.org/jira/browse/LOG4NET-489 > Project: Log4net > Issue Type: Bug > Components: Appenders >Affects Versions: 1.2.14 > Environment: Windows >Reporter: Philip Lee >Assignee: Dominik Psenner > Fix For: 1.2.15 > > Attachments: screenshot-1.png > > > with 1.2.13 everything is working fine. > Update to 1.2.14 (2.0.4 on Nuget), logging fails. > I would have attached screenshots, but can't work out how. > For example >value="System.Data.SqlClient.SqlConnection, System.Data, > Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" /> > >value="INSERT INTO dbo.Logging > ([LogDate],[Level],[Operation],[OperationInfo],[User],[Label],[Application],[CorrelationId],[Method],[Line],[Logger],[Message],[Exception]) > > VALUES (@log_date, @log_level, @operation, @operationInfo, > @user, @label, @application, @correlationId, @pgm_method, @pgm_line, @logger, > @message, @exception)" /> > > > > > > ... etc > This now causes the error > 'Exception while writing to database System.IndexOutOfRangeException: An > SqlParameter with ParamerName '@log_date' is not contained by this > SqlParameterCollection -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LOG4NET-489) AdoNetAppender fails after upgrade to 2.0.4
[ https://issues.apache.org/jira/browse/LOG4NET-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15030189#comment-15030189 ] Dominik Psenner commented on LOG4NET-489: - Hi Marek, I understand your point, but we will not provide unofficial binaries to be used in production environments. Please download 1.2.13 from the archives or build it from source. Cheers > AdoNetAppender fails after upgrade to 2.0.4 > --- > > Key: LOG4NET-489 > URL: https://issues.apache.org/jira/browse/LOG4NET-489 > Project: Log4net > Issue Type: Bug > Components: Appenders >Affects Versions: 1.2.14 > Environment: Windows >Reporter: Philip Lee >Assignee: Dominik Psenner > Fix For: 1.2.15 > > Attachments: screenshot-1.png > > > with 1.2.13 everything is working fine. > Update to 1.2.14 (2.0.4 on Nuget), logging fails. > I would have attached screenshots, but can't work out how. > For example >value="System.Data.SqlClient.SqlConnection, System.Data, > Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" /> > >value="INSERT INTO dbo.Logging > ([LogDate],[Level],[Operation],[OperationInfo],[User],[Label],[Application],[CorrelationId],[Method],[Line],[Logger],[Message],[Exception]) > > VALUES (@log_date, @log_level, @operation, @operationInfo, > @user, @label, @application, @correlationId, @pgm_method, @pgm_line, @logger, > @message, @exception)" /> > > > > > > ... etc > This now causes the error > 'Exception while writing to database System.IndexOutOfRangeException: An > SqlParameter with ParamerName '@log_date' is not contained by this > SqlParameterCollection -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LOG4NET-495) Error when BufferSize is >1, parameter already defined
[
https://issues.apache.org/jira/browse/LOG4NET-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15030179#comment-15030179
]
Dominik Psenner commented on LOG4NET-495:
-
Fix committed as svn revision 1716909.
> Error when BufferSize is >1, parameter already defined
> --
>
> Key: LOG4NET-495
> URL: https://issues.apache.org/jira/browse/LOG4NET-495
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 1.2.15
> Environment: Windows 7
>Reporter: Rick Burge
>
> Downloaded the subject revision 1714197 in order to get the
> ADONetAppender_SqlServer appender to work as this revision corrected a
> problem. The appender began to work. However if the BufferSize was increased
> to >1 an error was reported that the parameter @log_date was already defined.
> The error appears to be in SendBuffer. Because the IDbCommand dbCmd is being
> reused inside the foreach (LoggingEvent e in Events), each time the
> param.Prepare(dbCmd) is called for the same appender it will attempt to add a
> parameter that has already been added.
> My local solution was to clear the commands parameter list prior to adding
> the preparing the paramters:
>foreach (LoggingEvent e in events)
> {
> dbCmd.Parameters.Clear(); //*added this
> line*
> // Set the parameter values
> foreach (AdoNetAppenderParameter param in
> m_parameters)
> {
> param.Prepare(dbCmd);
> param.FormatValue(dbCmd, e);
> }
> // Execute the query
> dbCmd.ExecuteNonQuery();
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (LOG4NET-495) Error when BufferSize is >1, parameter already defined
[
https://issues.apache.org/jira/browse/LOG4NET-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominik Psenner resolved LOG4NET-495.
-
Resolution: Fixed
Fix Version/s: 1.2.15
> Error when BufferSize is >1, parameter already defined
> --
>
> Key: LOG4NET-495
> URL: https://issues.apache.org/jira/browse/LOG4NET-495
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 1.2.15
> Environment: Windows 7
>Reporter: Rick Burge
>Assignee: Dominik Psenner
> Fix For: 1.2.15
>
>
> Downloaded the subject revision 1714197 in order to get the
> ADONetAppender_SqlServer appender to work as this revision corrected a
> problem. The appender began to work. However if the BufferSize was increased
> to >1 an error was reported that the parameter @log_date was already defined.
> The error appears to be in SendBuffer. Because the IDbCommand dbCmd is being
> reused inside the foreach (LoggingEvent e in Events), each time the
> param.Prepare(dbCmd) is called for the same appender it will attempt to add a
> parameter that has already been added.
> My local solution was to clear the commands parameter list prior to adding
> the preparing the paramters:
>foreach (LoggingEvent e in events)
> {
> dbCmd.Parameters.Clear(); //*added this
> line*
> // Set the parameter values
> foreach (AdoNetAppenderParameter param in
> m_parameters)
> {
> param.Prepare(dbCmd);
> param.FormatValue(dbCmd, e);
> }
> // Execute the query
> dbCmd.ExecuteNonQuery();
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
