Dominik Psenner (JIRA | 22 Oct 08:44 2014
Picon

[jira] [Commented] (LOG4NET-443) Logger.CallAppenders


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

Dominik Psenner commented on LOG4NET-443:
-----------------------------------------

Or maybe you could try to use several remoting appenders that send events to one remoting sink which then
writes to the log files? This could be a safe way to abort threads without leaking locks since every thread
has his own appender and does not have to be synchronized with the other threads.

> Logger.CallAppenders
> --------------------
>
>                 Key: LOG4NET-443
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-443
>             Project: Log4net
>          Issue Type: Bug
>    Affects Versions: 1.2.13
>         Environment: Windows service implemented with .NET 4.5  using Log4Net 1.2.13 on Windows 2008 R2
>            Reporter: Calin Pavel
>            Priority: Critical
>         Attachments: log4net.xml
>
>
> I do have an .NET application (Windows Service) that collects data from a lot of sources (DBs, log files,
machines event logs, ...) and uses Log4Net to log details of the actions / execution.  As expected, I'm
using a high number of threads to collect data, threads that are writing logs in some files (RollingFileAppenderer).
> Lately it happens that the entire application is BLOCKED because all threads were trying to acquire a read
(Continue reading)

Dominik Psenner (JIRA | 21 Oct 16:35 2014
Picon

[jira] [Commented] (LOG4NET-443) Logger.CallAppenders


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

Dominik Psenner commented on LOG4NET-443:
-----------------------------------------

Then this one might be hitting you here:

http://joeduffyblog.com/2007/01/29/monitorenter-thread-aborts-and-orphaned-locks/

Quite worrying .. That blog post tells us this: THOU SHALL NOT ABORT THREADS. :-) As far as I can understand
this you will have to work around this issue by untangling the threads.

> Logger.CallAppenders
> --------------------
>
>                 Key: LOG4NET-443
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-443
>             Project: Log4net
>          Issue Type: Bug
>    Affects Versions: 1.2.13
>         Environment: Windows service implemented with .NET 4.5  using Log4Net 1.2.13 on Windows 2008 R2
>            Reporter: Calin Pavel
>            Priority: Critical
>         Attachments: log4net.xml
>
>
> I do have an .NET application (Windows Service) that collects data from a lot of sources (DBs, log files,
(Continue reading)

Calin Pavel (JIRA | 21 Oct 14:32 2014
Picon

[jira] [Commented] (LOG4NET-443) Logger.CallAppenders


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

Calin Pavel commented on LOG4NET-443:
-------------------------------------

It's a Win 2008 R2 x64

> Logger.CallAppenders
> --------------------
>
>                 Key: LOG4NET-443
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-443
>             Project: Log4net
>          Issue Type: Bug
>    Affects Versions: 1.2.13
>         Environment: Windows service implemented with .NET 4.5  using Log4Net 1.2.13 on Windows 2008 R2
>            Reporter: Calin Pavel
>            Priority: Critical
>         Attachments: log4net.xml
>
>
> I do have an .NET application (Windows Service) that collects data from a lot of sources (DBs, log files,
machines event logs, ...) and uses Log4Net to log details of the actions / execution.  As expected, I'm
using a high number of threads to collect data, threads that are writing logs in some files (RollingFileAppenderer).
> Lately it happens that the entire application is BLOCKED because all threads were trying to acquire a read
lock, like in the stack trace:
> 000000001ac3d998 00000000774715fa [HelperMethodFrame: 000000001ac3d998] System.Threading.Thread.SleepInternal(Int32)
(Continue reading)

Dominik Psenner (JIRA | 21 Oct 13:59 2014
Picon

[jira] [Commented] (LOG4NET-443) Logger.CallAppenders


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

Dominik Psenner commented on LOG4NET-443:
-----------------------------------------

This could be indeed an orphaned lock issue if thread aborts happen regularily. Is your Win2008 server
running on x64 or x32?

> Logger.CallAppenders
> --------------------
>
>                 Key: LOG4NET-443
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-443
>             Project: Log4net
>          Issue Type: Bug
>    Affects Versions: 1.2.13
>         Environment: Windows service implemented with .NET 4.5  using Log4Net 1.2.13 on Windows 2008 R2
>            Reporter: Calin Pavel
>            Priority: Critical
>         Attachments: log4net.xml
>
>
> I do have an .NET application (Windows Service) that collects data from a lot of sources (DBs, log files,
machines event logs, ...) and uses Log4Net to log details of the actions / execution.  As expected, I'm
using a high number of threads to collect data, threads that are writing logs in some files (RollingFileAppenderer).
> Lately it happens that the entire application is BLOCKED because all threads were trying to acquire a read
lock, like in the stack trace:
(Continue reading)

Calin Pavel (JIRA | 21 Oct 10:44 2014
Picon

[jira] [Updated] (LOG4NET-443) Logger.CallAppenders


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

Calin Pavel updated LOG4NET-443:
--------------------------------
    Attachment: log4net.xml

For configuring log4net I'm using an XML (attached) and some dynamic configuration:
private void addLogger(Hierarchy loggerRepository, MonitorConfig monitorConfig)
        {
            Logger root = loggerRepository.Root;
            RollingFileAppender mainAppender = (RollingFileAppender)root.GetAppender(MAIN_FILE_APPENDER_NAME);
            string logPath = mainAppender.File;
            string logDir = logPath.Substring(0, logPath.LastIndexOf( <at> "\"));

            // create the appender
            RollingFileAppender monitorAppender = new RollingFileAppender();
            monitorAppender.Name = buildAppendererName(monitorConfig);
            monitorAppender.File = Path.Combine(logDir, MONITOR_LOGGING_PARENT_DIR, monitorConfig.name) +  <at> "\";

            // Copy values from the DataCollector appenderer (main appenderer)
            monitorAppender.DatePattern = DateHelper.DATE_FORMAT + "'_" + monitorConfig.name + ".log'";
            monitorAppender.AppendToFile = mainAppender.AppendToFile;
            monitorAppender.RollingStyle = mainAppender.RollingStyle;
            monitorAppender.StaticLogFileName = mainAppender.StaticLogFileName;
            monitorAppender.PreserveLogFileNameExtension = mainAppender.PreserveLogFileNameExtension;

            PatternLayout layout = new PatternLayout("%date [%thread] %-5level %logger{1}:%L - %message%newline");
            monitorAppender.Layout = layout;
(Continue reading)

Calin Pavel (JIRA | 21 Oct 10:33 2014
Picon

[jira] [Created] (LOG4NET-443) Logger.CallAppenders

Calin Pavel created LOG4NET-443:
-----------------------------------

             Summary: Logger.CallAppenders
                 Key: LOG4NET-443
                 URL: https://issues.apache.org/jira/browse/LOG4NET-443
             Project: Log4net
          Issue Type: Bug
    Affects Versions: 1.2.13
         Environment: Windows service implemented with .NET 4.5  using Log4Net 1.2.13 on Windows 2008 R2
            Reporter: Calin Pavel
            Priority: Critical

I do have an .NET application (Windows Service) that collects data from a lot of sources (DBs, log files,
machines event logs, ...) and uses Log4Net to log details of the actions / execution.  As expected, I'm
using a high number of threads to collect data, threads that are writing logs in some files (RollingFileAppenderer).

Lately it happens that the entire application is BLOCKED because all threads were trying to acquire a read
lock, like in the stack trace:
000000001ac3d998 00000000774715fa [HelperMethodFrame: 000000001ac3d998] System.Threading.Thread.SleepInternal(Int32)
000000001ac3da90 000007fef747b5e9 System.Threading.Thread.Sleep(Int32)
000000001ac3dac0 000007fef5fb9631 System.Threading.ReaderWriterLockSlim.EnterMyLockSpin()
000000001ac3db90 000007fef5cd297e System.Threading.ReaderWriterLockSlim.TryEnterReadLockCore(TimeoutTracker)
000000001ac3dbf0 000007fef5cd28fa System.Threading.ReaderWriterLockSlim.TryEnterReadLock(TimeoutTracker)
000000001ac3dc40 000007fe98fb4efd log4net.Repository.Hierarchy.Logger.CallAppenders(log4net.Core.LoggingEvent)
000000001ac3dcc0 000007fe98fb4907 log4net.Repository.Hierarchy.Logger.Log(System.Type,
log4net.Core.Level, System.Object, System.Exception)
000000001ac3dd30 000007fe98fb47f9 log4net.Core.LogImpl.Info(System.Object)  

It's important to mention that my threads have a timeout, and if they do not finish the job in the given
(Continue reading)

antoniusriha | 18 Oct 00:06 2014
Picon

[GitHub] log4net pull request: Mono improvements

GitHub user antoniusriha opened a pull request:

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

    Mono improvements

    This PR
     * introduces mono-4.0 as supported target platform,
     * fixes a casing issue with two source files and
     * fixes a unit test

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/antoniusriha/log4net mono-improvements

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/log4net/pull/11.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #11

----
commit ace6fd9636b525c22def3f9e694e8a1dc67f3aee
Author: Antonius Riha <antoniusriha <at> gmail.com>
Date:   2014-10-17T21:14:39Z

    Add support for mono-4.0 build
(Continue reading)

Kanchan Mehrotra | 15 Oct 00:46 2014
Picon

Supporting Log4Net on ASP.NET vNext

Hi Log4Net Developers,

 

I am Kanchan Mehrotra, a Senior Test Lead on the ASP.NET team. I am reaching out to you as you are contributors to the Log4Net package which is popular in the .NET community. We would like to discuss with you plans for releasing support for your package for ASP.NET vNext. ASP.NET vNext is a new, lean and composable framework for building Web and cloud applications. It is open source, cross-platform, and supports true side-by-side versioning. ASP.NET vNext is “The Future of .NET on the Server” and we are very excited about what it brings to the .NET community!

 

As a part of our testing to understand the porting experience to ASP.NET vNext we ported some parts of your package source to use the latest preview release of ASP.NET vNext. We would like to share our initial investigations with you. Jiří Činčura, Daniel Roth and I met earlier and thought it would be great to include some of you in these discussions so please do let me know who on the project owners team should we involve in these discussions to share more information about ASP.Net vNext and support Serilog on this new stack.  

 

Thanks,

Kanchan

Dominik Psenner (JIRA | 3 Oct 14:43 2014
Picon

[jira] [Comment Edited] (LOG4NET-442) ReconnectOnError


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

Dominik Psenner edited comment on LOG4NET-442 at 10/3/14 12:43 PM:
-------------------------------------------------------------------

I'm afraid this might be a new "feature" of .NET framework 4.5.1:

http://blogs.msdn.com/b/dotnet/archive/2013/06/26/announcing-the-net-framework-4-5-1-preview.aspx

{quote}ADO.NET connection resiliency is a great answer to these connection scenarios. It is able to
*re-connect an app to the database* and replay session state transparently *when* an app’s *database
connection is broken*.{quote}

You could try to set ConnectRetryCount to 0 in the ConnectionString according to this source:

http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectionstring%28v=vs.110%29.aspx

was (Author: nachbarslumpi):
I'm afraid this might be a new "feature" of .NET framework 4.5.1:

http://blogs.msdn.com/b/dotnet/archive/2013/06/26/announcing-the-net-framework-4-5-1-preview.aspx

{quote}ADO.NET connection resiliency is a great answer to these connection scenarios. It is able to
*re-connect an app to the database* and replay session state transparently *when* an app’s *database
connection is broken*.{quote}

> ReconnectOnError 
> -----------------
>
>                 Key: LOG4NET-442
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-442
>             Project: Log4net
>          Issue Type: Bug
>          Components: Builds
>    Affects Versions: 1.2.13
>         Environment: Microsoft .NET 4.5
>            Reporter: Alessio Sanguineti
>         Attachments: log4net.txt
>
>
> Hello, in our .NET application using Log4Net to log on a Sql Server 2014 database, we set the parameter
"ReconnectOnError" to true in the ADO.Net Appender configuration. 
> Even if the property seems to be read correctly (as visible on the log), whenever the server is not
reachable for a while the appender does not reconnect anymore thus not logging anything else.
> We get the log file attached of a test where we turned off SQL Server for about 1 minute before restarting it.
> Thank you.
> Regards

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Dominik Psenner (JIRA | 3 Oct 14:40 2014
Picon

[jira] [Commented] (LOG4NET-442) ReconnectOnError


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

Dominik Psenner commented on LOG4NET-442:
-----------------------------------------

I'm afraid this might be a new "feature" of .NET framework 5.1:

http://blogs.msdn.com/b/dotnet/archive/2013/06/26/announcing-the-net-framework-4-5-1-preview.aspx

{quote}ADO.NET connection resiliency is a great answer to these connection scenarios. It is able to
*re-connect an app to the database* and replay session state transparently *when* an app’s *database
connection is broken*.{quote}

> ReconnectOnError 
> -----------------
>
>                 Key: LOG4NET-442
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-442
>             Project: Log4net
>          Issue Type: Bug
>          Components: Builds
>    Affects Versions: 1.2.13
>         Environment: Microsoft .NET 4.5
>            Reporter: Alessio Sanguineti
>         Attachments: log4net.txt
>
>
> Hello, in our .NET application using Log4Net to log on a Sql Server 2014 database, we set the parameter
"ReconnectOnError" to true in the ADO.Net Appender configuration. 
> Even if the property seems to be read correctly (as visible on the log), whenever the server is not
reachable for a while the appender does not reconnect anymore thus not logging anything else.
> We get the log file attached of a test where we turned off SQL Server for about 1 minute before restarting it.
> Thank you.
> Regards

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Dominik Psenner (JIRA | 3 Oct 14:40 2014
Picon

[jira] [Comment Edited] (LOG4NET-442) ReconnectOnError


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

Dominik Psenner edited comment on LOG4NET-442 at 10/3/14 12:40 PM:
-------------------------------------------------------------------

I'm afraid this might be a new "feature" of .NET framework 4.5.1:

http://blogs.msdn.com/b/dotnet/archive/2013/06/26/announcing-the-net-framework-4-5-1-preview.aspx

{quote}ADO.NET connection resiliency is a great answer to these connection scenarios. It is able to
*re-connect an app to the database* and replay session state transparently *when* an app’s *database
connection is broken*.{quote}

was (Author: nachbarslumpi):
I'm afraid this might be a new "feature" of .NET framework 5.1:

http://blogs.msdn.com/b/dotnet/archive/2013/06/26/announcing-the-net-framework-4-5-1-preview.aspx

{quote}ADO.NET connection resiliency is a great answer to these connection scenarios. It is able to
*re-connect an app to the database* and replay session state transparently *when* an app’s *database
connection is broken*.{quote}

> ReconnectOnError 
> -----------------
>
>                 Key: LOG4NET-442
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-442
>             Project: Log4net
>          Issue Type: Bug
>          Components: Builds
>    Affects Versions: 1.2.13
>         Environment: Microsoft .NET 4.5
>            Reporter: Alessio Sanguineti
>         Attachments: log4net.txt
>
>
> Hello, in our .NET application using Log4Net to log on a Sql Server 2014 database, we set the parameter
"ReconnectOnError" to true in the ADO.Net Appender configuration. 
> Even if the property seems to be read correctly (as visible on the log), whenever the server is not
reachable for a while the appender does not reconnect anymore thus not logging anything else.
> We get the log file attached of a test where we turned off SQL Server for about 1 minute before restarting it.
> Thank you.
> Regards

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


Gmane