Dominik Psenner (JIRA | 29 Oct 20:56 2014
Picon

[jira] [Commented] (LOG4NET-445) the log content can not write the right files by date


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

Dominik Psenner commented on LOG4NET-445:
-----------------------------------------

Is this actually a bug? If the local time was changed I would want to see that in the logfiles.

> the log content can not write the right files by date
> -----------------------------------------------------
>
>                 Key: LOG4NET-445
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-445
>             Project: Log4net
>          Issue Type: Task
>         Environment: visual studio 2010 ,net framework 4.0
>            Reporter: cwguang
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
>  Change the system date,for example ,change May  1st  to May 2nd,log4net will create a new log
20140502log.txt.but when you chang the date back to May 1st,log4net  still write the log content in
20140502log.txt. it should write the log content  to  20140501log.txt

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

(Continue reading)

cwguang (JIRA | 28 Oct 06:45 2014
Picon

[jira] [Created] (LOG4NET-445) the log content can not write the right files by date

cwguang created LOG4NET-445:
-------------------------------

             Summary: the log content can not write the right files by date
                 Key: LOG4NET-445
                 URL: https://issues.apache.org/jira/browse/LOG4NET-445
             Project: Log4net
          Issue Type: Task
         Environment: visual studio 2010 ,net framework 4.0
            Reporter: cwguang

 Change the system date,for example ,change May  1st  to May 2nd,log4net will create a new log
20140502log.txt.but when you chang the date back to May 1st,log4net  still write the log content in
20140502log.txt. it should write the log content  to  20140501log.txt

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

Bruno Marotta (JIRA | 24 Oct 11:10 2014
Picon

[jira] [Created] (LOG4NET-444) XmlHierarchyConfigurator is not extensible

Bruno Marotta created LOG4NET-444:
-------------------------------------

             Summary: XmlHierarchyConfigurator is not extensible
                 Key: LOG4NET-444
                 URL: https://issues.apache.org/jira/browse/LOG4NET-444
             Project: Log4net
          Issue Type: Improvement
          Components: Core
    Affects Versions: 1.2.13
         Environment: Any
            Reporter: Bruno Marotta
             Fix For: 1.2 Maintenance Release

Although the class XmlHierarchyConfigurator has many protected methods, none of them are marked as
virtual, making it impossible to be extended. This would be a really minor change and would allow the
extension of the XML parsing (for instance, for merging different XML files).

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

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


Gmane