Re: [jira] [Commented] (LOG4NET-562) LogicalThreadContext is not per Thread

[Dominik Psenner]

Thanks Alexander, that's exactly what I was suspecting. 
Parallel.ForEach() may not necessarily be using different threads to 
execute the tasks. Also, the latest stuff that can be implemented with 
async/await levers high parallelism without the need of multithreading. 
Only I'm afraid you have to post this on JIRA as well because Husain is 
probably not subscribed to the mailing list.



On 2017-04-07 10:31, Alexander Houben wrote:

Hello Husain,

I think the observed behavior lies in the implementation of 
Parallel.ForEach. All your assumptions seem correct to me except that 
Parallel.ForEach does not execute its actions on a separate thread or 
separate task each.


If you look at mscorlib with ILSpy and find 
System.Threading.Tasks.Parallel.ForEach you'll see that it does some 
heavy optimization to find the right ratio of threads/tasks and load.


IMHO it may be reusing a task where your "x-correlation-id" was set 
(if (i==3)) for other values of i, this is why you are seeing multiple 
modified log outputs.


cheers,
alex

On Fri, Apr 7, 2017 at 10:04 AM, Dominik Psenner (JIRA) 
<j...@apache.org <mailto:j...@apache.org>> wrote:



[

https://issues.apache.org/jira/browse/LOG4NET-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15960445#comment-15960445

<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
<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"

[jira] [Commented] (LOG4NET-562) LogicalThreadContext is not per Thread

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

[ 
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)

Re: [Discuss][VOTE] Combine the project user and dev mailing lists into user@ and dev@

[Dominik Psenner]

Total agreement.

On 10 Mar 2017 6:26 p.m., "Ralph Goers" <ralph.go...@dslextreme.com> wrote:

> This is exactly why we need one dev list. These last two responses dropped
> the other lists.  This is a horrible way to have discussions that affect
> all the sub projects.
>
> Ralph
>
>
> On Mar 10, 2017, at 9:11 AM, Matt Sicker <boa...@gmail.com> wrote:
>
> I'd love to see more unified configurations in all the subprojects. Gary
> mentioned that as an idea for log4cxx as that would make it useful for his
> use case where they're using both Java and C++ in various projects.
>
> While the programming languages in use here (Java, .NET, PHP, and C++)
> aren't really compatible with each other, having similar architectures and
> plugin systems could help a bit in this regard. Having more inclusive
> conversations about this would be great.
>
> On 10 March 2017 at 04:29, Mikael Ståldal <mikael.stal...@magine.com>
> wrote:
>
>> I think that a vast majority of our users only uses one of the languages
>> we support, and therefore only are interested in one of the subprojects.
>>
>> On Fri, Mar 10, 2017 at 11:23 AM, Dominik Psenner <dpsen...@gmail.com> w
>> rote:
>>
>>> We had once the discussion that we wanted all Apache Logging projects to
>>> become very similar in their usage, starting with the same or a very
>>> similar configuration. Given that we should aim towards one Apache Logging
>>> specification and several Apache Logging specification implementations in
>>> the form of Apache Logging subprojects. That means all the devs for all
>>> subprojects have to talk more. To me this is a good reasons to merge the
>>> dev mailing lists. Further I don't see why the same use case should not
>>> apply to the user mailing lists, too. Those mailing lists see very low
>>> traffic but all of them need a larger audience. Just quoting the last few
>>> messages of two user mailing lists I follow:
>>>
>>> log4j-user: the last topic came in a week ago, the topic before that
>>> about two weeks ago
>>> log4net-user: the last topic came in 24 hours ago and the topic before
>>> that a month ago
>>>
>>> Cheers
>>> On 2017-03-09 19:24, Ralph Goers wrote:
>>>
>>> We use general as mainly an announcement list for topics that might be
>>> of general interest to all logging projects. Generally, these are just
>>> release announcements.
>>>
>>> Ralph
>>>
>>> On Mar 9, 2017, at 10:37 AM, Matt Sicker <boa...@gmail.com> wrote:
>>>
>>> Yeah, I agree that the user lists can remain separate as it doesn't
>>> cause any issues currently. The main idea here is whether we should merge
>>> the dev lists into one, or if we need a common dev list for all devs to
>>> subscribe to (general@ doesn't sound appropriate, but I don't know what
>>> that list is for).
>>>
>>> On 9 March 2017 at 10:26, Ralph Goers <ralph.go...@dslextreme.com>
>>> wrote:
>>>
>>>> You should note that while we consider all votes only PMC votes are
>>>> “binding”. I don’t think that changes much however.
>>>>
>>>> From a PMC perspective I have to say that keeping the user’s lists
>>>> separate isn’t likely to be an issue as most of the things that would need
>>>> to be discussed would be on a dev list anyway.
>>>>
>>>> Ralph
>>>>
>>>> On Mar 9, 2017, at 2:45 AM, Dominik Psenner <dpsen...@gmail.com> wrote:
>>>>
>>>> The votes are way too scattered over the different mailing lists so
>>>> that I didn't even find my own vote. ;-) Therefore I'm trying to summarize
>>>> the current state of the vote:
>>>>
>>>> log4j-dev@, log4php-dev@, log4net-dev@, log4cxx-dev@ -> 
>>>> d...@logging.apache.org
>>>>
>>>> Matt Sicker: +1
>>>> Ralph Goers: +1
>>>> Stefan Bodewig: +1
>>>> Sven Rautenverg: -1
>>>> Thorsten Schöning: -0
>>>> Ivan Habunek: -0
>>>> Dominik Psenner: +1
>>>> Remko Popma: +1
>>>> Mikael Ståldal: +0
>>>>
>>>> Totals so far:
>>>> +1: 5
>>>> +0: 1
>>>> -0: 2
>>>> -1: 1
>>>>
>>>> log4j-user@, log4php-user@, log4net-user@, log4cxx-user@, general@ -> 
>>>> u...@logging.apache.org
>>>>
>>>> Matt Sicker: -1
>>>> Ralph Goers: +1
>>>> 

Re: [Discuss][VOTE] Combine the project user and dev mailing lists into user@ and dev@

[Dominik Psenner]

We had once the discussion that we wanted all Apache Logging projects to 
become very similar in their usage, starting with the same or a very 
similar configuration. Given that we should aim towards one Apache 
Logging specification and several Apache Logging specification 
implementations in the form of Apache Logging subprojects. That means 
all the devs for all subprojects have to talk more. To me this is a good 
reasons to merge the dev mailing lists. Further I don't see why the same 
use case should not apply to the user mailing lists, too. Those mailing 
lists see very low traffic but all of them need a larger audience. Just 
quoting the last few messages of two user mailing lists I follow:


log4j-user: the last topic came in a week ago, the topic before that 
about two weeks ago
log4net-user: the last topic came in 24 hours ago and the topic before 
that a month ago


Cheers

On 2017-03-09 19:24, Ralph Goers wrote:
We use general as mainly an announcement list for topics that might be 
of general interest to all logging projects. Generally, these are just 
release announcements.


Ralph

On Mar 9, 2017, at 10:37 AM, Matt Sicker <boa...@gmail.com 
<mailto:boa...@gmail.com>> wrote:


Yeah, I agree that the user lists can remain separate as it doesn't 
cause any issues currently. The main idea here is whether we should 
merge the dev lists into one, or if we need a common dev list for all 
devs to subscribe to (general@ doesn't sound appropriate, but I don't 
know what that list is for).


On 9 March 2017 at 10:26, Ralph Goers <ralph.go...@dslextreme.com 
<mailto:ralph.go...@dslextreme.com>> wrote:


You should note that while we consider all votes only PMC votes
are “binding”. I don’t think that changes much however.

From a PMC perspective I have to say that keeping the user’s
lists separate isn’t likely to be an issue as most of the things
that would need to be discussed would be on a dev list anyway.

Ralph


On Mar 9, 2017, at 2:45 AM, Dominik Psenner <dpsen...@gmail.com
<mailto:dpsen...@gmail.com>> wrote:

The votes are way too scattered over the different mailing lists
so that I didn't even find my own vote. ;-) Therefore I'm trying
to summarize the current state of the vote:

log4j-dev@, log4php-dev@, log4net-dev@, log4cxx-dev@ ->d...@logging.apache.org 
<mailto:d...@logging.apache.org>

Matt Sicker: +1
Ralph Goers: +1
Stefan Bodewig: +1
Sven Rautenverg: -1
Thorsten Schöning: -0
Ivan Habunek: -0
Dominik Psenner: +1
Remko Popma: +1
Mikael Ståldal: +0

Totals so far:
+1: 5
+0: 1
-0: 2
-1: 1

log4j-user@, log4php-user@, log4net-user@, log4cxx-user@, general@ 
->u...@logging.apache.org <mailto:u...@logging.apache.org>

Matt Sicker: -1
Ralph Goers: +1
Stefan Bodewig: -1
Sven Rautenverg: -1
Thorsten Schöning: -0
Ivan Habunek: -0
Dominik Psenner: +1
Remko Popma: +1
Mikael Ståldal: -1

Totals so far:
+1: 3
+0: 0
-0: 2
-1: 4
Sorry to anyone who's vote is missing.

On 2017-03-08 05:20, Matt Sicker wrote:

I may be missing some mailing lists considering I just
subscribed to half of them less than five minutes ago.

This is a vote to merge the various Apache Logging Services
mailing lists. The proposal is to combine them as follows:

log4j-dev@, log4php-dev@, log4net-dev@, log4cxx-dev@ ->
d...@logging.apache.org <mailto:d...@logging.apache.org>
log4j-user@, log4php-user@, log4net-user@, log4cxx-user@,
general@ -> u...@logging.apache.org
<mailto:u...@logging.apache.org>

commits@ and private@ remain the same as before.

The proposal would also suggest that the old emails become
aliases for the combined email names so as not to lose any
future emails. To distinguish between projects, a subject tag
can be added such as:

[java]
[net]
[cxx]
[php]

Though I wouldn't think such a tag is required, though it
should help in gaining the attention of the appropriate audience.

Voting:

+1: Yes, combine the mailing lists!
+0: Go ahead, don't care that much.
-0: Don't like it, but not vetoing it.
-1: No, don't do that! I have a better idea!

This vote follows the same "lazy consensus" (at least 3 +1
binding, no -1/vetoes) we use for general releases and whatnot.
The vote will be open for at least 72 hours.

-- 
Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>







--
Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>

Re: [VOTE] Combine the project user and dev mailing lists into user@ and dev@

[Dominik Psenner]

The votes are way too scattered over the different mailing lists so that 
I didn't even find my own vote. ;-) Therefore I'm trying to summarize 
the current state of the vote:


log4j-dev@, log4php-dev@, log4net-dev@, log4cxx-dev@ ->d...@logging.apache.org

Matt Sicker: +1
Ralph Goers: +1
Stefan Bodewig: +1
Sven Rautenverg: -1
Thorsten Schöning: -0
Ivan Habunek: -0
Dominik Psenner: +1
Remko Popma: +1
Mikael Ståldal: +0

Totals so far:
+1: 5
+0: 1
-0: 2
-1: 1

log4j-user@, log4php-user@, log4net-user@, log4cxx-user@, general@ 
->u...@logging.apache.org

Matt Sicker: -1
Ralph Goers: +1
Stefan Bodewig: -1
Sven Rautenverg: -1
Thorsten Schöning: -0
Ivan Habunek: -0
Dominik Psenner: +1
Remko Popma: +1
Mikael Ståldal: -1

Totals so far:
+1: 3
+0: 0
-0: 2
-1: 4

Sorry to anyone who's vote is missing.

On 2017-03-08 05:20, Matt Sicker wrote:
I may be missing some mailing lists considering I just subscribed to 
half of them less than five minutes ago.


This is a vote to merge the various Apache Logging Services mailing 
lists. The proposal is to combine them as follows:


log4j-dev@, log4php-dev@, log4net-dev@, log4cxx-dev@ -> 
d...@logging.apache.org <mailto:d...@logging.apache.org>
log4j-user@, log4php-user@, log4net-user@, log4cxx-user@, general@ -> 
u...@logging.apache.org <mailto:u...@logging.apache.org>


commits@ and private@ remain the same as before.

The proposal would also suggest that the old emails become aliases for 
the combined email names so as not to lose any future emails. To 
distinguish between projects, a subject tag can be added such as:


[java]
[net]
[cxx]
[php]

Though I wouldn't think such a tag is required, though it should help 
in gaining the attention of the appropriate audience.


Voting:

+1: Yes, combine the mailing lists!
+0: Go ahead, don't care that much.
-0: Don't like it, but not vetoing it.
-1: No, don't do that! I have a better idea!

This vote follows the same "lazy consensus" (at least 3 +1 binding, no 
-1/vetoes) we use for general releases and whatnot. The vote will be 
open for at least 72 hours.


--
Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>

Re: [VOTE] Release log4net 2.0.8 Based on RC1

[Dominik Psenner]

Of course, this is just something I've noticed while clicking through 
the site and it is definitely not a blocker for 2.0.8.



On 2017-03-09 09:13, Stefan Bodewig wrote:

On 2017-03-08, Dominik Psenner wrote:


I am looking through the release and am going to give a few feedbacks
during the next hour. The first thing i noticed is this:
The website page 'features' still mentions that log4net has builds for
ancient .net framework versions. We should change that.

Sure. But we can do so independent of any release anyway.

Thanks

 Stefan

Re: [VOTE] Release log4net 2.0.8 Based on RC1

[Dominik Psenner]

Assemblies work, checksums match.

+1

On 2017-03-08 19:52, Stefan Bodewig wrote:

Hi all

log4net 2.0.8 RC1 is available for review here:
   https://dist.apache.org/repos/dist/dev/logging/log4net
   (revision 18620)

Details of changes since 2.0.7 are in the release notes:
   https://stefan.samaflost.de/staging/log4net-2.0.8/release/release-notes.html

I have tested this with Mono and several .NET frameworks using NAnt.

The tag is here:
   https://svn.apache.org/repos/asf/logging/log4net/tags/2.0.8RC1
   (revision 1786048)

Site:
   https://stefan.samaflost.de/staging/log4net-2.0.8/

RAT Report:
   https://stefan.samaflost.de/staging/log4net-2.0.8/rat-report.html

Nuget Package:
   https://www.myget.org/feed/log4net-test/package/nuget/log4net

Votes, please.  This vote will close no sooner than in 72 hours,
1900 GMT 11-Mar 2017

[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...

Thanks!

Stefan

Re: [VOTE] Release log4net 2.0.8 Based on RC1

[Dominik Psenner]

The site and rat report look good, going to test the nuget binary tomorrow.

On 8 Mar 2017 9:39 p.m., "Dominik Psenner" <dpsen...@gmail.com> wrote:

> I am looking through the release and am going to give a few feedbacks
> during the next hour. The first thing i noticed is this:
>
> The website page 'features' still mentions that log4net has builds for
> ancient .net framework versions. We should change that.
>
> On 8 Mar 2017 7:52 p.m., "Stefan Bodewig" <bode...@apache.org> wrote:
>
>> Hi all
>>
>> log4net 2.0.8 RC1 is available for review here:
>>   https://dist.apache.org/repos/dist/dev/logging/log4net
>>   (revision 18620)
>>
>> Details of changes since 2.0.7 are in the release notes:
>>   https://stefan.samaflost.de/staging/log4net-2.0.8/release/re
>> lease-notes.html
>>
>> I have tested this with Mono and several .NET frameworks using NAnt.
>>
>> The tag is here:
>>   https://svn.apache.org/repos/asf/logging/log4net/tags/2.0.8RC1
>>   (revision 1786048)
>>
>> Site:
>>   https://stefan.samaflost.de/staging/log4net-2.0.8/
>>
>> RAT Report:
>>   https://stefan.samaflost.de/staging/log4net-2.0.8/rat-report.html
>>
>> Nuget Package:
>>   https://www.myget.org/feed/log4net-test/package/nuget/log4net
>>
>> Votes, please.  This vote will close no sooner than in 72 hours,
>> 1900 GMT 11-Mar 2017
>>
>> [ ] +1 Release these artifacts
>> [ ] +0 OK, but...
>> [ ] -0 OK, but really should fix...
>> [ ] -1 I oppose this release because...
>>
>> Thanks!
>>
>> Stefan
>>
>

Re: [VOTE] Release log4net 2.0.8 Based on RC1

[Dominik Psenner]

I am looking through the release and am going to give a few feedbacks
during the next hour. The first thing i noticed is this:

The website page 'features' still mentions that log4net has builds for
ancient .net framework versions. We should change that.

On 8 Mar 2017 7:52 p.m., "Stefan Bodewig"  wrote:

> Hi all
>
> log4net 2.0.8 RC1 is available for review here:
>   https://dist.apache.org/repos/dist/dev/logging/log4net
>   (revision 18620)
>
> Details of changes since 2.0.7 are in the release notes:
>   https://stefan.samaflost.de/staging/log4net-2.0.8/release/
> release-notes.html
>
> I have tested this with Mono and several .NET frameworks using NAnt.
>
> The tag is here:
>   https://svn.apache.org/repos/asf/logging/log4net/tags/2.0.8RC1
>   (revision 1786048)
>
> Site:
>   https://stefan.samaflost.de/staging/log4net-2.0.8/
>
> RAT Report:
>   https://stefan.samaflost.de/staging/log4net-2.0.8/rat-report.html
>
> Nuget Package:
>   https://www.myget.org/feed/log4net-test/package/nuget/log4net
>
> Votes, please.  This vote will close no sooner than in 72 hours,
> 1900 GMT 11-Mar 2017
>
> [ ] +1 Release these artifacts
> [ ] +0 OK, but...
> [ ] -0 OK, but really should fix...
> [ ] -1 I oppose this release because...
>
> Thanks!
>
> Stefan
>

[jira] [Commented] (LOG4NET-557) Create a Replacement/Alternative to RollingFileAppender that works

[Dominik Psenner (JIRA)]

[ 
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)

Re: Releasing 2.0.8?

[Dominik Psenner]

*hm*

Rereading the patch its probably safe to just apply the patch [1] and 
check if all the unittests pass.


[1] 
https://issues.apache.org/jira/secure/attachment/12852105/log4net-DebugAppenderCategory3.patch


On 2017-03-07 10:42, Stefan Bodewig wrote:

On 2017-03-06, Dominik Psenner wrote:


The codereview of 553 is fine and includes reasonable unittests. The
regression tests for all supported framework targets is the bottleneck here.

What kind of regression tests do you envision? Is there anything I or a
different member of the community can do to move this forward?

Stefan

Re: Releasing 2.0.8?

[Dominik Psenner]

The codereview of 553 is fine and includes reasonable unittests. The
regression tests for all supported framework targets is the bottleneck here.

On 6 Mar 2017 12:20 p.m., "Stefan Bodewig" <bode...@apache.org> wrote:

On 2017-03-06, Dominik Psenner wrote:

> Testing and applying the patch for LOG4NET-553 is on my todo, but
> can't see when I can free the spare time to actually get it done.

I see.

Maybe we really should get back into the habbit of more frequent
releases. :-)  If that's ever been the case, I'm not sure.

Schedule LOG4NET-553 for 2.0.9?

Stefan

Re: Releasing 2.0.8?

[Dominik Psenner]

Hi Stefan,

Testing and applying the patch for LOG4NET-553 is on my todo, but can't 
see when I can free the spare time to actually get it done.


Cheers

On 2017-03-06 10:27, Stefan Bodewig wrote:

Hi all

apart from the LockRecursionException Joe has fixed, we probably should
also bring back support for LogicalThreadContext for the .NET Standard
build.

I'll try to find time to build the release during the coming days, is
there anything that should be done before starting the release process?

Cheers

 Stefan

[jira] [Commented] (LOG4NET-554) LogicalThreadContext was removed in .NETStandard

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

[ 
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)

Re: [ANN] New Committer Joe

[Dominik Psenner]

Hi joe,

Glad to welcome you among us!

Cheers

On 6 Feb 2017 10:43 a.m., "Joe"  wrote:

Thanks to everyone for the good wishes and I'm looking forward to working
with you all.
--
*From:* Harry Martyrossian 
*Sent:* 05 February 2017 17:54:11
*To:* Log4NET Dev
*Subject:* RE: [ANN] New Committer Joe

Welcome to the team, Joe!

Wish you happy coding,
Harry

-Original Message-
From: Stefan Bodewig [mailto:bode...@apache.org ]
Sent: Sunday, February 05, 2017 4:23 AM
To: log4net-dev@logging.apache.org
Subject: [ANN] New Committer Joe

Hi all

on behalf of the log4net committers it's my pleasure to announce that
Joe has been elected as a new log4net committer.

Please join me in welcoming him.

Cheers

Stefan

Re: Sorry for the JIRA Spam

[Dominik Psenner]

Interesting. I dont mind the spam unless i have to look at all the content
to filter the spam manually. Can i safely mark everything as read or is
there anything i have to catch up with?

On 17 Jan 2017 9:54 p.m., "Stefan Bodewig"  wrote:

> Hi
>
> there's been a cycle where a mailer daemon responded to a JIRA ticket
> because of an "undeliverable" notification and this response caused a
> new comment creating a new mail to the same failing address ...
>
> Over the course of the day I've been wading through the comments,
> deleting them one by one. I thought JIRA notifications had been going to
> a special "issues" list and never thought I'd be spamming more people
> than just myself and Dominik. I'll stop deleting the comments
> immediately.
>
> Sorry for the noise
>
>   Stefan
>

[jira] [Closed] (LOG4NET-543) ConsoleAppender hangs at WriteFileNative

[Dominik Psenner (JIRA)]

 [ 
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)

Re: [GitHub] log4net issue #40: Implemented changes for the Util/AppenderAttachedImpl.cs ...

[Dominik Psenner]

Welcome to the list, marty! Here we go, feel free to start discussions.

On 6 Jan 2017 8:17 a.m., "HMartyrossian"  wrote:

Github user HMartyrossian commented on the issue:

https://github.com/apache/log4net/pull/40

@bodewig: Thank you very much, Stefan, for your prompt answer! I did
subscribe for log4net messages.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [VOTE] Release log4net 2.0.6 based on RC1

[Dominik Psenner]

Great! All in all this is a clear

+1

from Italy.

On 2016-12-22 14:04, Stefan Bodewig wrote:

On 2016-12-22, Dominik Psenner wrote:


A question about the .net core support:
according to the documentation, .net remoting is not available with
.net standard 1.3. Would that mean too that the
log4net.ThreadLogicalContext is not available either because it
requires System.Runtime.Remoting.Messaging.CallContext?

You mean LogicalThreadContext? You are right, this one is excluded. I'll
add it to the list of things that don't work.

This - as well as fixing the license page - can be done independent of
the release as we can change the site whenever we want to.

Many thanks for testing

  Stefan

Re: [VOTE] Release log4net 2.0.6 based on RC1

[Dominik Psenner]

Just finished the tests and the binaries work for me. This means that 
the functionality is there but we have to discuss if the license issue 
is a showstopper before I can cast my vote.


Cheers

On 2016-12-20 11:07, Stefan Bodewig wrote:

Hi all

log4net 2.0.6 RC1 is available for review here:
   https://dist.apache.org/repos/dist/dev/logging/log4net
   (revision 17495)

Details of changes since 1.2.15 are in the release notes:
   http://stefan.samaflost.de/staging/log4net-2.0.6/release/release-notes.html

I have tested this with Mono and several .NET frameworks using NAnt.

The tag is here:
   https://svn.apache.org/repos/asf/logging/log4net/tags/2.0.6RC1
   (revision 1775236)

Site:
   http://stefan.samaflost.de/staging/log4net-2.0.6/

RAT Report:
   http://stefan.samaflost.de/staging/log4net-2.0.6/rat-report.html

Nuget Package:
   https://www.myget.org/feed/log4net-test/package/nuget/log4net

Votes, please.  This vote will close in 72 hours, 1000 GMT 24-Dec 2016

[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...

Thanks!

Re: [VOTE] Release log4net 2.0.6 based on RC1

[Dominik Psenner]

Gotcha at http://stefan.samaflost.de/staging/log4net-2.0.6/license.html

{quote}

 Copyright [] [name of copyright owner]


{quote

We should replace the placeholders.

On 2016-12-20 11:07, Stefan Bodewig wrote:

Hi all

log4net 2.0.6 RC1 is available for review here:
   https://dist.apache.org/repos/dist/dev/logging/log4net
   (revision 17495)

Details of changes since 1.2.15 are in the release notes:
   http://stefan.samaflost.de/staging/log4net-2.0.6/release/release-notes.html

I have tested this with Mono and several .NET frameworks using NAnt.

The tag is here:
   https://svn.apache.org/repos/asf/logging/log4net/tags/2.0.6RC1
   (revision 1775236)

Site:
   http://stefan.samaflost.de/staging/log4net-2.0.6/

RAT Report:
   http://stefan.samaflost.de/staging/log4net-2.0.6/rat-report.html

Nuget Package:
   https://www.myget.org/feed/log4net-test/package/nuget/log4net

Votes, please.  This vote will close in 72 hours, 1000 GMT 24-Dec 2016

[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...

Thanks!

Re: [VOTE] Release log4net 2.0.6 based on RC1

[Dominik Psenner]

Hi Stefan,

thanks for carving out 2.0.6. I'm looking through the website and am 
going to run some sanity checks right now. Are you planning to push this 
to nuget?


Cheers,
Dominik

On 2016-12-20 11:07, Stefan Bodewig wrote:

Hi all

log4net 2.0.6 RC1 is available for review here:
   https://dist.apache.org/repos/dist/dev/logging/log4net
   (revision 17495)

Details of changes since 1.2.15 are in the release notes:
   http://stefan.samaflost.de/staging/log4net-2.0.6/release/release-notes.html

I have tested this with Mono and several .NET frameworks using NAnt.

The tag is here:
   https://svn.apache.org/repos/asf/logging/log4net/tags/2.0.6RC1
   (revision 1775236)

Site:
   http://stefan.samaflost.de/staging/log4net-2.0.6/

RAT Report:
   http://stefan.samaflost.de/staging/log4net-2.0.6/rat-report.html

Nuget Package:
   https://www.myget.org/feed/log4net-test/package/nuget/log4net

Votes, please.  This vote will close in 72 hours, 1000 GMT 24-Dec 2016

[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...

Thanks!

[jira] [Closed] (LOG4NET-411) Release 1.2.13.0 is no longer compatible with .Net 2.0

[Dominik Psenner (JIRA)]

 [ 
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

[Dominik Psenner (JIRA)]

[ 
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)

Re: [jira] [Commented] (LOG4NET-538) AdoNetAppender to PostgreSQL

[Dominik Psenner]

The author of the issue is most probably not subscribed to the mailing
list, therefore i quote you in the issue tracker.

On 13 Dec 2016 5:16 p.m., "Raymond Sanchez" <agileraym...@gmail.com> wrote:

Hi Dominik,

I upgrade my database to 9.5.4 and it works fine. Cristian, are you able to
push your project to Github?

If you are not able to do so, check the raw sql query being sent to
Postgres. I have seen .net providers sending incorrect column names to the
database.

Hope this helps.




On Mon, Dec 12, 2016 at 10:05 AM, Dominik Psenner <dpsen...@gmail.com>
wrote:

> Hi Raymond,
>
> have you already tried to migrate to postgresql 9.5 or newer?
>
> Best regards,
> Dominik
> On 2016-12-12 16:06, Raymond Sanchez wrote:
>
> What version of Postgresql are you using?
>
> Our company is using 9.4.5 and log4net 1.2.15 with no issues.
>
>
> On Mon, Dec 12, 2016 at 7:30 AM, Cristian Margescu (JIRA) <j...@apache.org
> > wrote:
>
>>
>> [ https://issues.apache.org/jira/browse/LOG4NET-538?page=com.a
>> tlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&
>> focusedCommentId=15741894#comment-15741894 ]
>>
>> Cristian Margescu commented on LOG4NET-538:
>> ---
>>
>> Hi,
>> I would be glad to but I have time as of 20th this month. So if there is
>> no real hurry would be my pleasure. you can contact me per email with
>> details.
>> Thank You
>>
>> > 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)
>>
>
>
>

Re: [jira] [Commented] (LOG4NET-538) AdoNetAppender to PostgreSQL

[Dominik Psenner]

Hi Raymond,

have you already tried to migrate to postgresql 9.5 or newer?

Best regards,
Dominik

On 2016-12-12 16:06, Raymond Sanchez wrote:

What version of Postgresql are you using?

Our company is using 9.4.5 and log4net 1.2.15 with no issues.


On Mon, Dec 12, 2016 at 7:30 AM, Cristian Margescu (JIRA) 
> wrote:



[

https://issues.apache.org/jira/browse/LOG4NET-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15741894#comment-15741894


]

Cristian Margescu commented on LOG4NET-538:
---

Hi,
I would be glad to but I have time as of 20th this month. So if
there is no real hurry would be my pleasure. you can contact me
per email with details.
Thank You

> 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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

 [ 
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

[Dominik Psenner (JIRA)]

 [ 
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

[Dominik Psenner (JIRA)]

 [ 
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

[Dominik Psenner (JIRA)]

 [ 
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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

 [ 
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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

 [ 
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

[Dominik Psenner (JIRA)]

 [ 
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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

 [ 
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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

[ 
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)

Re: Towards 2.0.6

[Dominik Psenner]

On 2016-11-09 10:11, Stefan Bodewig wrote:

On 2016-11-07, Dominik Psenner wrote:


LOG4NET-487 is about the configuration option and the issue I would
like to see in the release. The reason is, not having this
configurable costs performance and creating a mutex always is
troublesome to some configurations.

I should be able to carve out some time the coming days and will look
into LOG4NET-487 unless anybody beats me to it. Would you be OK with me
calling a release vote after that?


It is something I would like to see in 2.0.6, which doesn't imply that 
it must be part of 2.0.6. I'm going to vote for 2.0.6 even if 
LOG4NET-487 is not part of it, so long 2.0.6 passes my checks.


Cheers

RE: Apache log4net Needs Help

[Dominik Psenner]

This sounds like a plan.

On 6 Nov 2016 8:25 p.m., "Joe"  wrote:

> > A long time ago I had started a reimplementation of the
> RollingFileAppender because we've seen that we cannot fix it without
> breaking compatibility or redefining its features. Most of the
>
> > issues related to the RollingFileAppender should be marked as related
> issues to the rewrite issue. I dont have the issue id at hand, though. If
> you wanted to pick up that initial work and
>
> > continue it would be awesome! Most probably I am going to jump in
> helping you because the RollingFileAppender is one of the most used
> features and therefore one of the crucial points
>
> > where performance and sanity can make a difference of users moving away
> from log4net or attracting more users.
>
>
>
> I’d be willing to get involved in that.  A suggestion for what I could do
> over the next months:
>
>
>
> 1.  Complete AsyncAppenderSkeleton and AsyncForwardingAppender
>
>
>
> 2. Possibly implement the ability to log to an ILog from an appender
> derived from AsyncAppenderSkeleton if the re-entrancy issues can be solved
> (which I think they can).
>
>
>
> 3. Implement performance counters in AsyncAppenderSkeleton (and maybe
> AppenderSkeleton).  I’ve recently done something similar for a custom
> asynchronous appender, and it should be fairly straightforward to
> implement.  The idea is to make it easy to monitor performance of an
> appender: number of logging events processed, rate at which they’re
> processed, average processing time, queue length when in asynchronous mode,
> …  I’ll create an issue for this in due course with a more detailed
> description.
>
>
>
> 4. Reimplement RollingFileAppender, perhaps as AsyncRollingFileAppender
> derived from AsyncAppenderSkeleton.  It might be useful to be able to use
> it in asynchronous mode, for example to reduce the performance impact of
> contention for the mutex when logging to a shared file.
>
>
>
>
>

RE: Towards 2.0.6

[Dominik Psenner]

We had introduced a mutex to secure rolling operations in the rolling file
appender. It would be nice if we could make the rolling locking
configurable (none, lock, mutex), defaulting to none. There should be an
issue for that, too.

On 6 Nov 2016 2:19 p.m., "Joe"  wrote:

I just had a quick look through the commits since 1.2.15 and I don't see
anything that looks particularly risky.
I'd vote for cutting an RC.

-Original Message-
From: Stefan Bodewig [mailto:bode...@apache.org]
Sent: 06 November 2016 11:14
To: log4net-dev@logging.apache.org
Subject: Towards 2.0.6

Hi all

I'd like to get 2.0.6 released in order to help out people who want to use
log4net with .NET Core.

We've had some changes since I built the last test assemblies, but AFAIK
nobody has given them a try anyway. I wonder whether creating test
assemblies is worth the effort or whether I should simply proceed with
cutting a release candidate and call for a vote.

So what do you think, should I just cut an RC? Is there anything floating
around that should go into 2.0.6?

Stefan

[jira] [Closed] (LOG4NET-264) Unexpected/Invalid(?) System.PlatformNotSupportedException

[Dominik Psenner (JIRA)]

 [ 
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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

 [ 
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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

[ 
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?

[Dominik Psenner (JIRA)]

[ 
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)

Re: Apache log4net Needs Help

[Dominik Psenner]

2016-11-05 19:38 GMT+01:00 Stefan Bodewig <bode...@apache.org>:

> On 2016-11-05, Joe wrote:
>
> >> If you are willing to help, please join log4net's dev mailing list and
> raise your hand. Look through log4net's issue tracker and pick things you'd
> like to work on. If you don't know where to start, please ask, Dominik and
> Stefan will be there to help.
>
> >> If there is anything holding you back from contributing, let's discuss
> it and get it out of the way.
>
> > Looking through the log4net issue tracker, I find it difficult to pick
> > out things to work on.
>
> > - There are an awful lot of open issues that have been open for a long
> > time and are unassigned
>
> I've gone through them a long time ago when it looked like we had a plan
> of moving forward - that's why you may find some issues assigned to
> versions like 3.5 or 4. Reality has rendered those versions moot.
>
> > - Some of the ones I've looked through seem like they could be closed
> > as Won't fix, Incomplete, Cannot Reproduce, Later or Not a Bug.  Doing
> > this might show that things are moving and be an incentive for people
> > to get involved.
>
> Fine with me. So far I haven't closed any enhancement requests as I
> thought somebody might pick it up. But at the same time I knew I
> wouldn't be working on it. I've tried to keep up with real bug reports
> and enhancement requests that came with a path - but likely failed to do
> so as well.
>
> > - It would help to have a roadmap for the next couple of releases.
> > For example, if we know that someone is working on a revamped
> > RollingFileAppender, all issues related to RollingFileAppender should
> > be assigned to them.
>
> The main reason we've lacked a roadmap so far is that we've been
> reacting to reported bugs. I'd be happy if we could change this. Short
> term I'd love to see us release 2.0.6 as a sign of life.
>

A long time ago I had started a reimplementation of the RollingFileAppender
because we've seen that we cannot fix it without breaking compatibility or
redefining its features. Most of the issues related to the
RollingFileAppender should be marked as related issues to the rewrite
issue. I dont have the issue id at hand, though. If you wanted to pick up
that initial work and continue it would be awesome! Most probably I am
going to jump in helping you because the RollingFileAppender is one of the
most used features and therefore one of the crucial points where
performance and sanity can make a difference of users moving away from
log4net or attracting more users.


>
> > - Perhaps some of them need to be reprioritized, so that it's easier
> > to focus on what is high priority and consistent with the roadmap.
>
> Current priorities are most likely the ones set by the reporters. Which
> usually means everybody considers their issues the most important ones.
>

I tend to prioritize recent reports because the reporters of those old
issues most likely have found a workaround or moved to another logging
framework. Those issues are most likely to be closed because they are not
reproducable.

-- 
Dominik Psenner

[jira] [Closed] (LOG4NET-255) Problem with getting path to appdata with windows service in Windows XP

[Dominik Psenner (JIRA)]

 [ 
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

[Dominik Psenner (JIRA)]

 [ 
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)

Re: [jira] [Closed] (LOG4NET-281) Insufficient Granularity on Log methods in ILog

[Dominik Psenner]

Thanks joe for bringing up this issue. This is a good catch for a won't
fix. :-)

2016-11-05 20:54 GMT+01:00 Dominik Psenner (JIRA) <j...@apache.org>:

>
>  [ 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)
>



-- 
Dominik Psenner

Re: AsyncAppenderSkeleton

[Dominik Psenner]

On 2016-11-04 10:37, Stefan Bodewig wrote:

On 2016-11-03, Joe wrote:


However I don’t understand your point about event formatters – are
there any formatters that aren’t thread safe?  It doesn’t seem to be
an unreasonable restriction to require writers of formatters / layout
implementations to be thread-safe.

It may not be unreasonable, but it has never been imposed, I'm
afraid. Some of the layouts and formatters out there may not be
thread-safe.


True.



If I'm taking away one thing of the discussion between Dominik and
yourself it is that log4net's internals would look different if done
today *and* the people that are here today don't really know why certain
design decisions have been taken.


True, too. :-)

Re: AsyncAppenderSkeleton

[Dominik Psenner]

On 2016-11-03 22:06, Joe wrote:


OK I understand the point about potential corruption when a derived 
class is writing logging events in a non-atomic way, which is probably 
typical of most appenders.


However I don’t understand your point about event formatters – are 
there any formatters that aren’t thread safe?  It doesn’t seem to be 
an unreasonable restriction to require writers of formatters / layout 
implementations to be thread-safe.


I looked at the implementation of AbsoluteTimeDateFormatter, which 
uses a static buffer internally.  It seems to be thread-safe, but if I 
understood the code correctly, it seems to have a superfluous lock on 
s_lastTimeBuf, since it is only ever accessed when the current thread 
is already holding a lock on s_lastTimeStrings.   Also it seems to me 
that any performance gains achieved by reusing a static buffer could 
easily be cancelled out by the overhead of holding locks if an 
application does a lot of concurrent logging from multiple threads.  
Perhaps a better implementation would be to use a ThreadStatic buffer, 
which I think would give the same result without locking.




You are right about this. Locking must be avoided where ever it is 
possible. Unless populating caches altogether with locking is faster 
than recalculating things on every run. The former is probably the case 
for the formatters. The AbsoluteTimeDateFormatter is a good example for 
that. It has to update the formatted date/time string only once in a 
while which is way less frequent than the frequency of generated log 
events and for all log events in between it can reuse the cached string 
representation.


As for an async appender: I still think the best approach is to write 
a new base class AsyncAppenderSkeleton, that doesn’t inherit from 
either BufferingAppenderSkeleton or AppenderSkeleton.  I’ll give it 
some more thought and post again to justify this opinion soon(ish).


*From:*Dominik Psenner [mailto:dpsen...@gmail.com]
*Sent:* 03 November 2016 00:14
*To:* Log4NET Dev
*Subject:* Re: AsyncAppenderSkeleton

As far as I can recall, log4net logs to an appender in the thread that 
the log event was created on unless there is buffering of log events 
in between (BufferingAppenderSkeleton). This in general means that 
multiple threads write content to an appender at the same time and 
that in turn means that there is a chance that log events get mixed up.


Think of two threads A and B that try to write to the same sink at the 
same time. Thread A begins to write the timestamp of his log event and 
gets interrupted. B wakes up and writes another timestamp. Now there 
are two timestamps after each other and the outcome is not two 
distinct log messages but garbage.


And the issues can go even further. What if the event formatter 
populates a (not thread safe) local cache while processing log events? 
The outcome is unpredictable. I can imagine that back then it was 
decided to better be safe than sorry. A pessimistic lock fixes this 
issue for good at the cost of performance.


Writing this down today in 2016, one major question jumps into my 
mind: why is locking not left up to the appender or a event formatter? 
There are appenders out there that append log events to sinks that can 
handle concurrency very well (databases for example). It would 
definitely result in more locks; more locks cost more and thus a 
single (outer) lock is better.


Still, today I would not bother about locking and rather configure a 
buffering appender and let that appender append events into another 
appender that must not care about locking because the buffering 
appender already does. If one knows that locking/buffering is not 
needed because his application does no multithreading at all, he could 
still configure the other appender all alone.


2016-11-02 20:55 GMT+01:00 Joe <jocular...@hotmail.com 
<mailto:jocular...@hotmail.com>>:


I’m trying to understand what locking is necessary in AppenderSkeleton 
and its derived classes.  There is a lock(this) in AppenderSkeleton’s 
DoAppend and Close methods, which ensure that the appender can’t be 
closed while an Append is in progress.   Implementing Append in a 
derived class is easier, because the lock ensures it can never be 
called concurrently by more than one thread.


That’s all fairly clear, but I don’t understand the comment in the 
AppenderSkeleton.DoAppend method:


// This lock is absolutely critical for correct formatting

// of the message in a multi-threaded environment.  Without

// this, the message may be broken up into elements from

// multiple thread contexts (like get the wrong thread ID).

The lock is clearly necessary for the above reasons, but I don’t see 
what race condition could cause a message to be “broken up into 
elements from multiple thread contexts”?


Can you throw any light on that?

*From:*Dominik Psenner [mailto:dpsen...@apache.org 
<mailto:dpsen...@apache.org>]

*Sent:* 31 October 2016 15:31

Re: AsyncAppenderSkeleton

[Dominik Psenner]

As far as I can recall, log4net logs to an appender in the thread that the
log event was created on unless there is buffering of log events in between
(BufferingAppenderSkeleton). This in general means that multiple threads
write content to an appender at the same time and that in turn means that
there is a chance that log events get mixed up.

Think of two threads A and B that try to write to the same sink at the same
time. Thread A begins to write the timestamp of his log event and gets
interrupted. B wakes up and writes another timestamp. Now there are two
timestamps after each other and the outcome is not two distinct log
messages but garbage.

And the issues can go even further. What if the event formatter populates a
(not thread safe) local cache while processing log events? The outcome is
unpredictable. I can imagine that back then it was decided to better be
safe than sorry. A pessimistic lock fixes this issue for good at the cost
of performance.

Writing this down today in 2016, one major question jumps into my mind: why
is locking not left up to the appender or a event formatter? There are
appenders out there that append log events to sinks that can handle
concurrency very well (databases for example). It would definitely result
in more locks; more locks cost more and thus a single (outer) lock is
better.

Still, today I would not bother about locking and rather configure a
buffering appender and let that appender append events into another
appender that must not care about locking because the buffering appender
already does. If one knows that locking/buffering is not needed because his
application does no multithreading at all, he could still configure the
other appender all alone.

2016-11-02 20:55 GMT+01:00 Joe <jocular...@hotmail.com>:

> I’m trying to understand what locking is necessary in AppenderSkeleton and
> its derived classes.  There is a lock(this) in AppenderSkeleton’s DoAppend
> and Close methods, which ensure that the appender can’t be closed while an
> Append is in progress.   Implementing Append in a derived class is easier,
> because the lock ensures it can never be called concurrently by more than
> one thread.
>
>
>
> That’s all fairly clear, but I don’t understand the comment in the
> AppenderSkeleton.DoAppend method:
>
>
>
>// This lock is absolutely critical for correct formatting
>
>// of the message in a multi-threaded environment.  Without
>
>// this, the message may be broken up into elements from
>
>// multiple thread contexts (like get the wrong thread ID).
>
>
>
> The lock is clearly necessary for the above reasons, but I don’t see what
> race condition could cause a message to be “broken up into elements from
> multiple thread contexts”?
>
>
>
> Can you throw any light on that?
>
>
>
>
>
>
>
> *From:* Dominik Psenner [mailto:dpsen...@apache.org]
> *Sent:* 31 October 2016 15:31
> *To:* log4net-dev@logging.apache.org
> *Subject:* Re: AsyncAppenderSkeleton
>
>
>
> See inlines.
>
> On 2016-10-31 11:30, Joe wrote:
>
> Hi Dominik,
>
>
>
> Thanks for the feedback
>
>
>
> > Please note also that MSMQ sounds like a MS only service and that would
> in turn mean that the .net core variant would no longer be able to benefit
> from the AsyncAppenderSkeleton. To me this outlines a path that we would
> not like to walk on
>
>
>
> I don’t see the problem here.
>
>
>
> I’m proposing that we could implement the queue as a separate class
> implementing a suitable interface (ILoggingEventQueue, IAppenderQueue or
> whatever – I’m with Philip Karlton on naming).The default
> implementation would be an in-memory queue, would not depend on MSMQ and
> would be available for .net core etc.
>
>
>
>
> Sorry, my fault, the sentence was TL;DR it's entirety. I had it read it as
> "The default implementation could be MSMQ". ;-) Thanks for the
> clarification.
>
>
> Then there could be an alternate implementation with a persistent queue
> using MSMQ, or users could provide their own custom implementations using
> some other persistent queueing technology if they wish.
>
>
>
> The alternative of a persistent queue is useful to reduce the risk of
> (probably the last and therefore most important) logging events being lost
> when an application crashes: with a persistent queue they could be picked
> up again from the queue when the application restarts, or by an independent
> utility.
>
>
>
>
>
> > This sounds mostly like the BufferingAppenderSkeleton, which only
> misses the background worker thread to send the buffer.
>
>
>
> I’m not convinced that BufferingAppenderSkeleton is a good candidate.  For
> example:
>
&

Re: AsyncAppenderSkeleton

[Dominik Psenner]

These few lines alone are very suspicious indeed. Without further 
investigations I'm unable to give any sensible feedback.


On 2016-10-31 11:54, Joe wrote:


Another point is that for any asynchronous appender implementation, 
it’s a sine qua non that the LoggingEvent class be thread-safe.


At least for the manipulations an appender might do: layout, accessing 
properties, fixing properties.


I had a quick browse through the source and found what looks to me 
like a race condition here:


publicobjectLookupProperty(stringkey)

 {

if(m_data.Properties != null)

{

returnm_data.Properties[key];

}

if(m_compositeProperties == null)

{

CreateCompositeProperties();

}

returnm_compositeProperties[key];

}

privatevoidCreateCompositeProperties()

 {

m_compositeProperties = newCompositeProperties();

if(m_eventProperties != null)

{

m_compositeProperties.Add(m_eventProperties);

}

... etc

If two threads call LookupProperty concurrently, one may start 
executing CreateCompositeProperties and the other might access 
m_compositeProperties before it’s fully created.


If I’m right, the fix is simple – don’t set m_compositeProperties 
until it’s completely created.

Re: AsyncAppenderSkeleton

[Dominik Psenner]

See inlines.

On 2016-10-31 11:30, Joe wrote:


Hi Dominik,

Thanks for the feedback

> Please note also that MSMQ sounds like a MS only service and that would in turn mean that the .net core 
variant would no longer be able to benefit from the 
AsyncAppenderSkeleton. To me this outlines a path that we would not 
like to walk on


I don’t see the problem here.

I’m proposing that we could implement the queue as a separate class 
implementing a suitable interface (ILoggingEventQueue, IAppenderQueue 
or whatever – I’m with Philip Karlton on naming).The default 
implementation would be an in-memory queue, would not depend on MSMQ 
and would be available for .net core etc.




Sorry, my fault, the sentence was TL;DR it's entirety. I had it read it 
as "The default implementation could be MSMQ". ;-) Thanks for the 
clarification.


Then there could be an alternate implementation with a persistent 
queue using MSMQ, or users could provide their own custom 
implementations using some other persistent queueing technology if 
they wish.


The alternative of a persistent queue is useful to reduce the risk of 
(probably the last and therefore most important) logging events being 
lost when an application crashes: with a persistent queue they could 
be picked up again from the queue when the application restarts, or by 
an independent utility.


> This sounds mostly like the BufferingAppenderSkeleton, which only 
misses the background worker thread to send the buffer.


I’m not convinced that BufferingAppenderSkeleton is a good candidate. 
 For example:


- Locking is problematic.  The appender would need to lock(this) while 
it is forwarding logging events to the sink 
(BufferingAppenderSkeleton.SendBuffer).  This could hold the lock for 
an extended period (e.g. due to a communication timeout).  Therefore 
DoAppend should not lock(this) while enqueueing logging events or 
we’ll be unnecessarily blocking the calling application.  This is one 
of the main reasons I want to implement my own DoEvents rather than 
deriving from AppenderSkeleton.




If the implementation requires lock(this) to work, the implementation is 
broken. The queue itself has to be thread safe. Hence, a true async 
appender should block the calling application only to fix a few logging 
event properties that would otherwise be lost (i.e. stacktrace or thread 
information).


- I see the buffering and triggering logic being implemented in a 
pluggable ILoggingEventQueue.   By default, there would be no 
buffering, except what is implicit in the fact that events may be 
enqueued faster than they can be dequeued.  I.e. whenever the 
background thread detects events in the queue, by default it processes 
all available events immediately, in blocks whose maximum size is a 
configurable SendBufferSize.A custom queue implementation could 
implement triggering logic akin to BufferingAppenderSkeleton, e.g. 
wait for a timeout defined by TimeEvaluator if there are fewer than 
SendBufferSize events in the queue.




A async appender working in async mode always buffers, by definition. If 
it wouldn't buffer, there would be nothing that a background thread 
could work on and it would block the calling application.



> System.Threading.Task.Run().

The TPL could be one way of implementing the queue, though I’m not 
convinced that it adds much value.  The custom implementation I did 
recently didn’t use TPL, and that would be my starting point.  This 
also means it would be compatible with .NET 3.5.




If .net 3.5 is a target for async logging, then the implementation 
cannot use the System.Threading.Tasks namespace. Otherwise I would build 
upon the default task scheduler implementation or provide a custom task 
scheduler implementation that derives from 
System.Threading.Tasks.TaskScheduler and let all logging tasks run on 
that task scheduler.


  I found having a single background thread made it easier to 
implement things like flushing.




Mileage may vary but to me, this is not the case.


   Flush was implemented to:

- return true immediately if the queue is empty and all events have 
been successfully sent to the sink.


- return false immediately if the last attempt to send events to the 
sink failed.


- else wait for the background thread to set a ManualResetEvent when 
it’s finished processing all events in the queue.




That could read as:

bool Flush() {
return await Task.Run(() => {
  return doFlush();
});
}

or:

bool Flush() {
 Task task = Task.Run() => {
  return doFlush();
});
 task.Wait();
 return task.Result;
}

or even:

Task FlushAsync() {
return Task.Run() => {
  return doFlush();
});
}

> The default implementation should probably be able to operate 
asynchronously or synchronously and change mode of operation based on 
a configuration flag "Asynchronous=True"


That’s exactly what I had in mind.



Cheers

Re: AsyncAppenderSkeleton

[Dominik Psenner]

Hi Joe!

On 2016-10-31 08:15, Joe wrote:


I have some ideas for developing a new AsyncAppenderSkeleton, based on 
recent experience developing a custom async appender that sends 
logging events to a Web API.


My current thoughts are:

1.A new base class AsyncAppenderSkeleton that can be configured to 
work in synchronous mode (identical to AppenderSkeleton) or 
asynchronous mode, where DoAppend queues events on to a FIFO queue, 
and has a single background thread that dequeues events and calls the 
existing Append methods.




This sounds mostly like the BufferingAppenderSkeleton, which only misses 
the background worker thread to send the buffer. Therefore the 
AsyncAppenderSkeleton could derive from BufferingAppenderSkeleton and 
override a few methods that would additionally dispatch the job to a 
background thread. See System.Threading.Task.Run().


2.When in asynchronous mode, there will be customizable and 
configurable retry logic that can call Append if it throws an 
exception.  The retry login will be able to inspect the exception that 
was thrown and keep a count of the number of retries so far.  For 
example, a derived appender that logs to a Web API might want to retry 
5xx HTTP status codes, but treat 4xx status codes as permanent 
errors.   There will no retry logic in synchronous mode as this would 
impact performance.




When running a task with System.Threading.Task.Run() it returns a 
System.Threading.Tasks.Task object that allows to inspect the outcome of 
the task. See:


https://msdn.microsoft.com/en-us/library/system.threading.tasks.task(v=vs.110).aspx

3.The default queue implementation would be a lossy in-memory Queue 
with a configurable maximum length.  It might be nice to provide the 
possibility to plug in alternate queue implementations, such as a 
persistent queue using MSMQ.




We would reuse the BufferingAppenderSkeleton implementation of the queue 
which does (not yet) persist the queue. Please note also that MSMQ 
sounds like a MS only service and that would in turn mean that the .net 
core variant would no longer be able to benefit from the 
AsyncAppenderSkeleton. To me this outlines a path that we would not like 
to walk on.


4.A class AsyncForwardingAppender would derive from 
AsyncAppenderSkeleton and implement IAppenderAttachable.




That's sensible to me. Looking at the class hierarchy of other 
ForwardingAppender implementations composition sounds more sensible and 
could be preferred over inheritance. We could try and work out a generic 
ForwardingAppenderSkeleton implementation that can take arbitrary 
appenders and must no longer be derived by every appender that should 
become a Forwarding one.


5.It would be easy to create asynchronous versions of existing custom 
appenders, by changing the base class from AppenderSkeleton to 
AsyncAppenderSkeleton and optionally implementing some retry logic.  
E.g. we could have a new AdoNetAppender that can be configured to 
operate in synchronous mode when logging to a local database, or in 
asynchronous mode when logging to a cloud-based database.




The default implementation should probably be able to operate 
asynchronously or synchronously and change mode of operation based on a 
configuration flag "Asynchronous=True". This levers easy reconfiguration 
at runtime and has probably other benefits too.


In terms of timescales, I think it would be possible to produce 
something by the end of 2016.


To do it I need to reimplement AppenderSkeleton’s DoAppend methods, to 
enqueue events if in asynchronous mode, or call Append in synchronous 
mode.


I don’t want to duplicate code by reimplementing the rest of 
AppenderSkeleton, so I would like to do one of the following:


Option 1:

-Refactor all of AppenderSkeleton’s implementation except IAppender 
and IBulkAppender into a new base class AppenderSkeletonBase.  This 
includes filtering, IOptionHandler, layout.


-Derive AppenderSkeleton and later the new AsyncAppenderSkeleton from 
AppenderSkeletonBase.


Option 2:

-Make AppenderSkeleton’s DoAppend methods virtual, and derive 
AsyncAppenderSkeleton from AppenderSkeleton.


Option 1 seems the cleanest to me; any thoughts?



Let's first write out a few thoughts and concepts. When we have a 
concept, the best way to get it done will hopefully be obvious.


Cheers

[jira] [Commented] (LOG4NET-528) AdoNetAppender giving .net lock

[Dominik Psenner (JIRA)]

[ 
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)

RE: Better support for logging from an Appender

[Dominik Psenner]

Appenders that log is immensely hard to implement if not separated entirely
from the normal logging. Therefore there is the loglog class. It could be a
feature to allow the configuration of loglog appenders under the
precondition that those appenders do not append events back into the
logging framework, even if events travel over remote sinks.

On 26 Oct 2016 8:40 p.m., "Joe"  wrote:

> Thanks for the response.
>
> After more thought and some tests, this idea is a non-starter.
>
> 1. Hierarchy.Logger.CallAppenders acquires a ReaderWriterLockSlim instance
> that doesn't allow recursion (the default LockRecursionPolicy.NoRecursion).
> Thus if a synchronous appender attempts to log, it will fail with a
> LogRecursionException.
>
>  I'm not sure if this behaviour is intentional.  Because when compiled for
> .NET 1.x it uses a ReaderWriterLock which *does* allow recursion.
>
> Any thoughts on this?  Should the log4net.Util.ReaderWriterLock class be
> instantiating its ReaderWriterLockSlim with LockRecursionPolicy.
> SupportsRecursion?
>
> Another point about ReaderWriterLockSlim is that it is IDisposable, which
> means that strictly speaking classes that own an instance (e.g.
> Hierarchy.Logger) should be IDisposable, and should be disposed when no
> longer used.  I doubt if this is a big deal in practice as most log4net
> objects will live until the AppDomain is unloaded.
>
> 2. Even in the asynchronous case, there is a risk of infinite recursion.
> Each Appender can ignore logging events generated by its own logger, but
> consider the following, assuming appenders want verbose logging of every
> LoggingEvent they see:
>
> - Appender A logs to logger A
> - Appender B logs to logger B
> - log4net is configured to route logging events to both appenders
>
> Every logging event received by A is logged which triggers a logging event
> to B, which logs it and triggers a log event to A, ...
>
> So back to the drawing board.
>
> My main reason for wanting this is for the case of an asynchronous
> appender, which will typically be forwarding events to a remote sink, the
> connection to which may be unreliable.
> In this case, it's desirable for errors to be logged in log4net even in a
> production environment where log4net.internal.debug is false.  Probably
> using a "once-only" logging technique which only logs the error the first
> time it occurs.
>
>
> -Original Message-
> From: Stefan Bodewig [mailto:bode...@apache.org]
> Sent: 22 October 2016 22:18
> To: Log4NET Dev
> Subject: Re: Better support for logging from an Appender
>
> On 2016-10-21, Joe wrote:
>
> > From within DoAppend, there is a flag m_recursiveGuard which should
> > prevent re-entrancy problems from a synchronous appender's Append
> > method.  For an asynchronous appender there would need to be an
> > additional check since it will want to log from a different thread.
>
> We could store some kind of flag that acts like the recursive guard inside
> the (logical) thread context and then check for its existence inside the
> LoggingEvent's properties.
>
> > The following commit will give you an idea of what I'm thinking of:
>
> > https://github.com/apache/log4net/commit/9dc3ed9ae079d9abeacdf86c380b1
> > 7efff4b3a97?w=1
>
> > Is this something we should support?
>
> Your idea works for the case where you know you are logging from inside an
> appender. There is a different way an appender might receive messages that
> originate from itself when the appender uses a library that again uses
> log4net for logging. This wouldn't get caught by your approach but a
> property on the event would work.
>
> This is just an idea, nothing I've actually tried.
>
> > BTW if you look at the above commit without the ?w=1 suffix, you'll
> > see whitespace differences in the Flush method.  I think the
> > .gitattributes file needs to add rules for converting spaces to tabs.
>
> Indentation inside the code base is a mess and I'm sure I've contributed
> to it by not using visual studio. Using .gitattributes could help if git
> was our primary SCM. For people using svn it wouldn't have any effect.
>
> Maybe we need somebody to configure VS with a "proper configuration"
> that we agree upon and re-indent the whole codebase once.
>
> Stefan
>

[jira] [Resolved] (LOG4NET-527) broken link on config-examples.html

[Dominik Psenner (JIRA)]

 [ 
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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

[ 
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

[Dominik Psenner (JIRA)]

 [ 
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

[Dominik Psenner (JIRA)]

[ 
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)

Re: Response to call to arms

[Dominik Psenner]

It's great to see new faces! Welcome Tommy!


On 2016-10-19 14:20, Tommy Parnell wrote:


I too added myself to this list from the blog post. I am 
https://github.com/terribledev <https://github.com/terribledev> I 
usually have a few days a month to help with these kinds of projects. 
Been using log4net since 2011. Mostly interested in performance 
things, and helping on .net core compatibility. That being said always 
willing to bug fix, and shave some yaks. My bread and butter is 
in CI/CD (i've built dotnet projects in ruby, node, msbuild only, 
cake, sake, etc.) so yeah can do that too! I have done quite a bit 
with shared projects, with compiler directives. Work in Boston, MA USA 
 moved here from the UK . so yeah that's me!



Oh also, Generics  and linq  Love the ideas! I'll probably 
grok the codebase for a while, and eventually pick up a jira or two.



<https://github.com/terribledev>

TerribleDev (Tommy Parnell) · GitHub <https://github.com/terribledev>
github.com
TerribleDev has 116 repositories available. Follow their code on GitHub.



--------
*From:* Dominik Psenner <dpsen...@apache.org>
*Sent:* Wednesday, October 19, 2016 4:28 AM
*To:* log4net-dev@logging.apache.org
*Subject:* Re: Response to call to arms

Hi Joe,

good to read you and welcome on the dev list! You're free to work on 
issues that attract your attention. Nobody's going to force you to 
work on things you don't deem to be worth the effort.


We've already decided to gradually drop official support for ancient 
.net frameworks like .NET 1.X. We are no longer going to actively 
maintain those targets and if changes to the codebase break those 
targets we are no longer going to fix that unless someone else 
provides a patch that restores compatibility. This means that we are 
shifting the responsibility of maintenance to whoever requires the 
latest log4net version to work on those ancient platforms.


Further, compact framework mostly does not support several appenders 
that for example target the System.Net namespace. Please correct me if 
I'm wrong, but from memory a prominent example appender is the 
EmailAppender. I agree with you that it would be a great improvement 
if we were able to refactor away all those #ifdef's. Unfortunately 
this wish is very hard to achieve, even impossible if we wanted to 
stay backwards compatible.


Backwards compatibility is the next thing I would like to mention. 
log4net is a logging framework and one of the highest goods is its 
backwards compatibility. If we are going to break that we must follow 
a path similar to that of log4j2. In that world the old API facades 
the log4j2 API and therefore migration of existing code is trivial.


Cheers and greets,Dominik

On 2016-10-18 22:42, Joe wrote:


I'm responding to Stefan's call-to-arms, though I have limited time 
available, currently probably not more than a day or two a month.


Given my lack of time I would probably want to get involved in 
specific short-term tasks, such as taking on issues from the issue 
tracker, rather than being a driver to shape the future of log4net.


I have been involved recently in writing a custom asynchronous 
appender that logs to a WebAPI, so asynchronous appenders is one area 
I could get involved in.


One thing I'd personally like to see is to drop support for some 
legacy platforms:


   - The few .NET 1.x users left are probably adequately served by 
existing versions of log4net.


   - It's not onerous for .NET 2.0/3.0 users to upgrade to .NET 3.5, 
so these could maybe be dropped too (existing apps don’t need to be 
rebuilt; they just need to ensure 3.5 is installed).


   - I've no experience with Compact Framework, but wonder whether, 
given the platform restrictions, it would be better served going 
forward by a separate code base with a simplified and restricted 
logging framework that exposes an identical API to applications.


Doing this would make development easier, for example by allowing the 
use of generics and Linq.


Which in turn might attract more developers ...

One way to approach it would be to remove the binaries for these 
platforms from the next release, and only remove from the source code 
if a reasonable period elapses without too much wailing and gnashing 
of teeth.

Re: Response to call to arms

[Dominik Psenner]

You've got the point. Obviously this all greatly depends what needs to 
get done. Let me outline this with an example:


Requirement: we want log4net to have an API where users must not invoke 
IsLogLevelEnabled to check if a log level is enabled and we want to have 
this without changing the current public API of the ILog interface

Implementation: we are going to implement this with lambdas
Implementation dependencies: this in turn requires us to target at least 
net 3.5 and above


The outcome of this example is the log4net.Utils.ILogExtensions static 
class.


Cheers,
Dominik

On 2016-10-19 20:02, Joe wrote:


Thanks for the response.

I don’t think there’s any rush to remove the ifdefs for obsolete 
platforms ; the important thing is to know we don’t need to add them 
for new code.


As a minor example I recently contributed code which measured elapsed 
time using DateTime.UtcNow: I’d probably have used a Stopwatch had I 
known .NET 1.x support was not required.


By implication you are planning to continue to target .NET 2.0 so 
presumably the rules are:


-Avoid using features from .NET 3.5+ in core components

-It’s OK to depend on .NET 3.5 for new loosely-coupled components such 
as Appenders – in this case the whole file just needs to be included 
in an #ifdef


I’ll start off by looking at LOGNET-407 as suggested by Stefan.

*From:*Dominik Psenner [mailto:dpsen...@apache.org]
*Sent:* 19 October 2016 10:29
*To:* log4net-dev@logging.apache.org
*Subject:* Re: Response to call to arms

Hi Joe,

good to read you and welcome on the dev list! You're free to work on 
issues that attract your attention. Nobody's going to force you to 
work on things you don't deem to be worth the effort.


We've already decided to gradually drop official support for ancient 
.net frameworks like .NET 1.X. We are no longer going to actively 
maintain those targets and if changes to the codebase break those 
targets we are no longer going to fix that unless someone else 
provides a patch that restores compatibility. This means that we are 
shifting the responsibility of maintenance to whoever requires the 
latest log4net version to work on those ancient platforms.


Further, compact framework mostly does not support several appenders 
that for example target the System.Net namespace. Please correct me if 
I'm wrong, but from memory a prominent example appender is the 
EmailAppender. I agree with you that it would be a great improvement 
if we were able to refactor away all those #ifdef's. Unfortunately 
this wish is very hard to achieve, even impossible if we wanted to 
stay backwards compatible.


Backwards compatibility is the next thing I would like to mention. 
log4net is a logging framework and one of the highest goods is its 
backwards compatibility. If we are going to break that we must follow 
a path similar to that of log4j2. In that world the old API facades 
the log4j2 API and therefore migration of existing code is trivial.


Cheers and greets,Dominik

On 2016-10-18 22:42, Joe wrote:

I'm responding to Stefan's call-to-arms, though I have limited
time available, currently probably not more than a day or two a month.

Given my lack of time I would probably want to get involved in
specific short-term tasks, such as taking on issues from the issue
tracker, rather than being a driver to shape the future of log4net.

I have been involved recently in writing a custom asynchronous
appender that logs to a WebAPI, so asynchronous appenders is one
area I could get involved in.

One thing I'd personally like to see is to drop support for some
legacy platforms:

   - The few .NET 1.x users left are probably adequately served by
existing versions of log4net.

   - It's not onerous for .NET 2.0/3.0 users to upgrade to .NET
3.5, so these could maybe be dropped too (existing apps don’t need
to be rebuilt; they just need to ensure 3.5 is installed).

   - I've no experience with Compact Framework, but wonder
whether, given the platform restrictions, it would be better
served going forward by a separate code base with a simplified and
restricted logging framework that exposes an identical API to
applications.

Doing this would make development easier, for example by allowing
the use of generics and Linq.

Which in turn might attract more developers ...

One way to approach it would be to remove the binaries for these
platforms from the next release, and only remove from the source
code if a reasonable period elapses without too much wailing and
gnashing of teeth.

Re: [GitHub] log4net issue #25: API to flush appenders that buffer logging data

[Dominik Psenner]

Said this, one may use his favorite line endings locally. When applying a
patch with different line endings, the applier of tge patch will either
reject the patch or fix line endings on thy fly.

Sorry for the various mails on the same thread. Sending from mobiles is not
really comfortable.

On 16 Oct 2016 5:13 p.m., "Dominik Psenner" <dpsen...@gmail.com> wrote:

> I suggest to agree on one line ending and use that throughout the
> repository.
>
> Until today the only rule that exists is that each file must use exactly
> one type of line endings. Mixed line endings are forbidden by svn
> properties.
>
> On 16 Oct 2016 4:21 p.m., "JJoe2" <g...@git.apache.org> wrote:
>
>> Github user JJoe2 commented on the issue:
>>
>> https://github.com/apache/log4net/pull/25
>>
>> The .gitattributes file you committed doesn’t specify line endings
>> for most file types including .cs and .csproj (the most commonly modified
>> ones).
>>
>> However I don’t feel competent to say whether it’s really a good
>> idea.   Having read the section on “Refreshing the repository after
>> changing line endings”, it seems that a number of arcane git incantations
>> may be required to get everything working again after doing so.   Which
>> might cause problems for people who have forked but are struggling with git.
>>
>>
>>
>> ---
>> If your project is set up for it, you can reply to this email and have
>> your
>> reply appear on GitHub as well. If your project does not have this feature
>> enabled and wishes so, or if the feature is enabled but not working,
>> please
>> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
>> with INFRA.
>> ---
>>
>

Re: [GitHub] log4net issue #25: API to flush appenders that buffer logging data

[Dominik Psenner]

I suggest to agree on one line ending and use that throughout the
repository.

Until today the only rule that exists is that each file must use exactly
one type of line endings. Mixed line endings are forbidden by svn
properties.

On 16 Oct 2016 4:21 p.m., "JJoe2"  wrote:

> Github user JJoe2 commented on the issue:
>
> https://github.com/apache/log4net/pull/25
>
> The .gitattributes file you committed doesn’t specify line endings for
> most file types including .cs and .csproj (the most commonly modified ones).
>
> However I don’t feel competent to say whether it’s really a good
> idea.   Having read the section on “Refreshing the repository after
> changing line endings”, it seems that a number of arcane git incantations
> may be required to get everything working again after doing so.   Which
> might cause problems for people who have forked but are struggling with git.
>
>
>
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
>

Re: [GitHub] log4net issue #25: API to flush appenders that buffer logging data

[Dominik Psenner]

What do you think of adding a timezone field such that people can calculate
the utc timestamp if they care? Nothing breaks while all usecases are taken
care of.

On 15 Oct 2016 7:23 p.m., "Dominik Psenner" <dpsen...@gmail.com> wrote:

I highly recommend to stay compatible and add a utc timestampas a new field
and deprecate the old field for at least one release cyle.

On 15 Oct 2016 7:20 p.m., "JJoe2" <g...@git.apache.org> wrote:

Github user JJoe2 commented on the issue:

https://github.com/apache/log4net/pull/25

Thanks.

I agree that I should have done a better job of keeping these changes
separate but when I did the initial work I was very much a git novice.
I’ll bite the bullet and separate these changes into two branches with
a rebase on the latest trunk.

I take your point about the binary serialization format.  For now I’ll
roll back the change in the serialization / deserialization methods.  Users
of RemotingAppender will therefore still be subject to ambiguous timestamps
but it’s no longer a breaking change.

We could also consider implementing serialization as follows (perhaps
enabled by a configuration setting if preserving backwards compatibility is
important):


info.AddValue("TimeStamp", m_data.TimeStampUtc);
  // Serialize
m_data.TimeStampUtc = info.GetDateTime("TimeStamp").ToUniversalTime();
  // Deserialize

Given that DateTime.ToUniversalTime() is a noop if the Kind property is
already set to Utc, this would give the correct result if both sides have
the new version, and the following result (ignoring .NET 1.x which didn’t
have a Kind property) for mixed versions:


1.   Old client and new server

Old client serializes as local time; New server converts this to UTC
based on the server’s timezone.  Result unchanged as long as client and
server timezones are the same.


2.   New client and old server



New client serializes as UTC.  Old server will have a UTC time in the
TimeStamp, and will probably interpret it as local time.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [GitHub] log4net issue #25: API to flush appenders that buffer logging data

[Dominik Psenner]

I highly recommend to stay compatible and add a utc timestampas a new field
and deprecate the old field for at least one release cyle.

On 15 Oct 2016 7:20 p.m., "JJoe2"  wrote:

Github user JJoe2 commented on the issue:

https://github.com/apache/log4net/pull/25

Thanks.

I agree that I should have done a better job of keeping these changes
separate but when I did the initial work I was very much a git novice.
I’ll bite the bullet and separate these changes into two branches with
a rebase on the latest trunk.

I take your point about the binary serialization format.  For now I’ll
roll back the change in the serialization / deserialization methods.  Users
of RemotingAppender will therefore still be subject to ambiguous timestamps
but it’s no longer a breaking change.

We could also consider implementing serialization as follows (perhaps
enabled by a configuration setting if preserving backwards compatibility is
important):


info.AddValue("TimeStamp", m_data.TimeStampUtc);
  // Serialize
m_data.TimeStampUtc = info.GetDateTime("TimeStamp").ToUniversalTime();
  // Deserialize

Given that DateTime.ToUniversalTime() is a noop if the Kind property is
already set to Utc, this would give the correct result if both sides have
the new version, and the following result (ignoring .NET 1.x which didn’t
have a Kind property) for mixed versions:


1.   Old client and new server

Old client serializes as local time; New server converts this to UTC
based on the server’s timezone.  Result unchanged as long as client and
server timezones are the same.


2.   New client and old server



New client serializes as UTC.  Old server will have a UTC time in the
TimeStamp, and will probably interpret it as local time.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---