[jira] [Updated] (LOG4NET-151) Cache DateTime.Now values when creating LoggingEvent when Environment.TickCount has not changed
[
https://issues.apache.org/jira/browse/LOG4NET-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated LOG4NET-151:
---
Fix Version/s: (was: 1.2.11)
1.2 Maintenance Release
Pushing it back so we can take more time to design it properly.
Cache DateTime.Now values when creating LoggingEvent when
Environment.TickCount has not changed
---
Key: LOG4NET-151
URL: https://issues.apache.org/jira/browse/LOG4NET-151
Project: Log4net
Issue Type: Improvement
Affects Versions: 1.2.10
Reporter: Ron Grabowski
Assignee: Ron Grabowski
Priority: Minor
Fix For: 1.2 Maintenance Release
When creating a lot of logging events in tight loop, DateTime.Now is called
for each new LoggingEvent even if several LoggingEvents are created within
the same millisecond. We can reuse the same DateTime object because DateTime
objects only track time down to the millisecond:
// inspired by nlog
int ticks = Environment.TickCount;
if (ticks != cachedTicks)
{
cachedTicks = ticks;
cachedDateTime = DateTime.Now;
}
return cachedDateTime;
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-154) Add a StackTracePatternConverter to display method calls leading up to log message
[
https://issues.apache.org/jira/browse/LOG4NET-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13103456#comment-13103456
]
Stefan Bodewig commented on LOG4NET-154:
Documentation on stacktracedetail pattern is missing completely and stacktrace
isn't documented in all places where it should be.
I'll look into Adam's latest attachment to see what is still missing from his
patch.
Add a StackTracePatternConverter to display method calls leading up to log
message
--
Key: LOG4NET-154
URL: https://issues.apache.org/jira/browse/LOG4NET-154
Project: Log4net
Issue Type: New Feature
Reporter: Ron Grabowski
Assignee: Ron Grabowski
Fix For: 1.2.11
Attachments: StackTracePatternConverter.cs,
StackTracePatternConverter.zip, log4net - StackTrace and StackTraceDetail.zip
Modify LocationInfo to save StackTrace information and make it available as
StackTracePatternConverter to display call stack leading up to the log
message:
log.Debug(Item Saved);
[%stackTrace{3}] %message%newline
[default_aspx.btnSubmit_Click productController.Save
productService.Save] Item Saved
This will probably be a slow pattern converter on par with other LocationInfo
derived pattern converters.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LOG4NET-313) Document %stacktrace and %stacktracedetail
Document %stacktrace and %stacktracedetail -- Key: LOG4NET-313 URL: https://issues.apache.org/jira/browse/LOG4NET-313 Project: Log4net Issue Type: Sub-task Components: Documentation Reporter: Stefan Bodewig Fix For: 1.2.11 There currently only is class-level documentation on %stacktrace and no documentation on %stacktracedetail outside of the StackTraceDetailPatternConverter class at all. Need to update PatternLayout as well as the site. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-154) Add a StackTracePatternConverter to display method calls leading up to log message
[
https://issues.apache.org/jira/browse/LOG4NET-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13103474#comment-13103474
]
Stefan Bodewig commented on LOG4NET-154:
I've had a look at Adam's (MAX|MIN) contribution and would suggest some
improvements (in particular in the light of Lars' comments further up).
Therefore I've opened LOG4NET-314 - which will not be part of the 1.2.11
release - and intend to close this issue as soon as the docs are in.
Add a StackTracePatternConverter to display method calls leading up to log
message
--
Key: LOG4NET-154
URL: https://issues.apache.org/jira/browse/LOG4NET-154
Project: Log4net
Issue Type: New Feature
Reporter: Ron Grabowski
Assignee: Ron Grabowski
Fix For: 1.2.11
Attachments: StackTracePatternConverter.cs,
StackTracePatternConverter.zip, log4net - StackTrace and StackTraceDetail.zip
Modify LocationInfo to save StackTrace information and make it available as
StackTracePatternConverter to display call stack leading up to the log
message:
log.Debug(Item Saved);
[%stackTrace{3}] %message%newline
[default_aspx.btnSubmit_Click productController.Save
productService.Save] Item Saved
This will probably be a slow pattern converter on par with other LocationInfo
derived pattern converters.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Name for MutexLock?
Hi, LOG4NET-164 introduced a new locking strategy for FileAppender which technically uses a System.Threading.Mutex with a name built from the log file's name. This should allow separate processes to share a log file without repeatedly opening and closing it. The main remaining issue is its name (apart from docs which will follow once the name is settled). Right now it is called MutexLock but that may not convey to users what this actually does - they'd need to know what a Mutex is in the first place. I'm notoriously bad at names so I'm asking here now. Names suggested in the JIRA ticket are InterProcessLock, SystemWideLock and GlobalLock. Stefan
[jira] [Commented] (LOG4NET-87) Support ASP.Net related PatternConverters to allow items from the HttpContext.Current.Session, Cache, Request, etc. to be captured.
[
https://issues.apache.org/jira/browse/LOG4NET-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13103583#comment-13103583
]
Stefan Bodewig commented on LOG4NET-87:
---
just missing some documentation
Support ASP.Net related PatternConverters to allow items from the
HttpContext.Current.Session, Cache, Request, etc. to be captured.
---
Key: LOG4NET-87
URL: https://issues.apache.org/jira/browse/LOG4NET-87
Project: Log4net
Issue Type: Wish
Components: Core
Affects Versions: 1.2.10
Reporter: Ron Grabowski
Assignee: Ron Grabowski
Priority: Minor
Fix For: 1.2.11
It would be nice if there were built-in Pattern Converters to support core
ASP.Net objects:
%aspnet-session{UserId}
%aspnet-session
%aspnet-request{ProductId}
This issue may be a good time to investigate supporting a more advanced
syntax for the Option parameter:
%aspnet-request{queryString:ProductId}
that could be shared across all Pattern Converters.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: Name for MutexLock?
LOG4NET-164 introduced a new locking strategy for FileAppender which technically uses a System.Threading.Mutex with a name built from the log file's name. This should allow separate processes to share a log file without repeatedly opening and closing it. The main remaining issue is its name (apart from docs which will follow once the name is settled). Right now it is called MutexLock but that may not convey to users what this actually does - they'd need to know what a Mutex is in the first place. I'm notoriously bad at names so I'm asking here now. Names suggested in the JIRA ticket are InterProcessLock, SystemWideLock and GlobalLock. Are we talking about the variable name? In that case I would prefer a name that makes it obvious what it is behind: MutexLock :-) Did you actually do performance tests too? A mutex is rather expensive and it should be avoided to acquire/release it multiple times unless really necessary. Greetings, D.
Re: Name for MutexLock?
On 2011-09-13, Dominik Psenner wrote: LOG4NET-164 introduced a new locking strategy for FileAppender which technically uses a System.Threading.Mutex with a name built from the log file's name. This should allow separate processes to share a log file without repeatedly opening and closing it. The main remaining issue is its name (apart from docs which will follow once the name is settled). Right now it is called MutexLock but that may not convey to users what this actually does - they'd need to know what a Mutex is in the first place. I'm notoriously bad at names so I'm asking here now. Names suggested in the JIRA ticket are InterProcessLock, SystemWideLock and GlobalLock. Are we talking about the variable name? In that case I would prefer a name that makes it obvious what it is behind: MutexLock Not only, it would also appear inside the config file in order to set the locking model of FileAppender like in the third example of http://logging.apache.org/log4net/release/config-examples.html#fileappender Right now it would be lockingModel type=log4net.Appender.FileAppender+MutexLock / Did you actually do performance tests too? A mutex is rather expensive and it should be avoided to acquire/release it multiple times unless really necessary. It would be aquired and released for each single logging event. The alternatives are (1) don't share the same log file between different processes or (2) repeatedly open and close the file (which is the MinimalLocking model). Whether the mutex performs better or worse than MinimalLocking depends on the concrete circumstances, I guess, but I'd expect the overhead of opening a file to be significant as well. Stefan
RE: Name for MutexLock?
I like InterProcessLock and would like to propose MultiProcessLock as my favorite. I HOPE that the documentation will indicate what a bad plan this is and that a remoteing appender etc might be a better plan. -- Roy Chastain -Original Message- From: Stefan Bodewig [mailto:bode...@apache.org] Sent: Tuesday, September 13, 2011 06:47 To: log4net-dev@logging.apache.org Subject: Name for MutexLock? Hi, LOG4NET-164 introduced a new locking strategy for FileAppender which technically uses a System.Threading.Mutex with a name built from the log file's name. This should allow separate processes to share a log file without repeatedly opening and closing it. The main remaining issue is its name (apart from docs which will follow once the name is settled). Right now it is called MutexLock but that may not convey to users what this actually does - they'd need to know what a Mutex is in the first place. I'm notoriously bad at names so I'm asking here now. Names suggested in the JIRA ticket are InterProcessLock, SystemWideLock and GlobalLock. Stefan
RE: Name for MutexLock?
Not only, it would also appear inside the config file in order to set the locking model of FileAppender like in the third example of http://logging.apache.org/log4net/release/config-examples.html#fileappender Right now it would be lockingModel type=log4net.Appender.FileAppender+MutexLock / Quite obvious what it does. If one enters MutexLock .NET into google there are plenty useful resources to find out what it does. Did you actually do performance tests too? A mutex is rather expensive and it should be avoided to acquire/release it multiple times unless really necessary. It would be aquired and released for each single logging event. The alternatives are (1) don't share the same log file between different processes or (2) repeatedly open and close the file (which is the MinimalLocking model). Whether the mutex performs better or worse than MinimalLocking depends on the concrete circumstances, I guess, but I'd expect the overhead of opening a file to be significant as well. Based on my observations, acquiring a mutex lock can take up to 30ms. IMHO the solution alternative 3) would require a little more effort. Namely collect a bunch of log events in the appender and dispatch them with one Mutex lock as fast as possible. I've here a reference implementation, but unfortunately I can't share it due to license restrictions. :-( The implementation basically works on two queues containing a ordered set of log events: * outerQueue * innerQueue New events are put to the outerQueue and all items in the innerQueue are written to the logfile in one go. And to speed things up, the queues are swapped in two conditions: * new log event is put to the outerQueue and the innerQueue is empty = swap innerQueue and outerQueue and write all events in innerQueue * innerQueue write is finished and the outerQueue is not empty = swap innerQueue and outerQueue and write all events in innerQueue I tested this on a quad-core, running 8 processes with 8 threads each logging in a while(true) loop and it works like a charm. :-) Greetings, D.
diffs between 1.2.10 and current trunk
Hi all, in order to shape up for the release I diffed the 1.2.10 release ZIP source tree against current trunk's src and used BitDiffer from bitwidgets[1] to compare the DEBUG assemblies targeting 2.0 in binary. The results can be found in http://people.apache.org/~bodewig/log4net/diffs/ The source code diffs are mainly there so we can put together proper release notes and see whether there are changes not covered by resolved JIRA issues. They may also be useful to catch mistakes now, but that is going to require a long time and sharp eyes, I'm afraid. I've set up BitDiffer to not compare implementations but really only signatures. The breaking changes it flags right now: (1) the several variations of static Configure methods in configurators now return ICollection, they used to be void methods. (2) ConverterInfo used to be a nested class of PatternLayout and has been moved to the Util namespace. (3) The signature of the CreateLogger method in ILoggerFactory has changed. (4) Several LogLog method signatures have changed. Of this only (3) really concerns me as I consider ConverterInfo and LogLog internal to log4net and the change in return type shouldn't cause anything to break IMHO. The change in ILoggerFactory happend in svn revision 515275[2] for LOG4NET-97[3]. Back then Nicko was aware this was breaking BWC (the commit log says so) but accepted it as necessary. This likely means we should document the change and live with it. Stefan [1] http://bitwidgets.com/ [2] https://svn.apache.org/viewvc?view=revisionrevision=515275 [3] https://issues.apache.org/jira/browse/LOG4NET-97
[jira] [Commented] (LOG4NET-314) Improve StackTracePatternConverter
[
https://issues.apache.org/jira/browse/LOG4NET-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13103699#comment-13103699
]
Adam Davies commented on LOG4NET-314:
-
I can add a theshold constraint if desired, and rename the MAX / MIN. My only
concern with adding the theshold constraint to a pattern converter is the same
goal can be achieved with the Filter element at the appender level. The
Filter element also gives us the capability to set the max and min levels. As
in
?xml version=1.0 encoding=utf-8?
log4net
xsi:noNamespaceSchemaLocation=http://csharptest.net/downloads/schema/log4net.xsd;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
appender name=ConsoleAppender
type=log4net.Appender.ConsoleAppender
filter type=log4net.Filter.LevelRangeFilter
levelMax value=WARN/
levelMin value=DEBUG/
/filter
layout type=log4net.Layout.PatternLayout
conversionPattern value=%stacktracedetail{-1|1} /
/layout
/appender
/log4net
Suggestions / comments?
Improve StackTracePatternConverter
--
Key: LOG4NET-314
URL: https://issues.apache.org/jira/browse/LOG4NET-314
Project: Log4net
Issue Type: Improvement
Components: Core
Affects Versions: 1.2.11
Reporter: Stefan Bodewig
Fix For: 1.2 Maintenance Release
LOG4NET-154 contains a patch that would introduce a MIN-Option to skip a
certain number of stack traces that didn't make it into 1.2.11.
There also is Lars' comment (
https://issues.apache.org/jira/browse/LOG4NET-154?focusedCommentId=12710413page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12710413
) that shows other possible improvements.
Personally I'm not convinved MIN is the right name for the option in Adam's
patch (skip feels more natural but I'm notoriously bad at names). Also I'd
prefer some sort of key-value option string as we expect more improvements
and the pipe-syntax likely won't scale. Something like
%stacktrace{frames:3,skip:2,threshold:WARN}.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-235) IP Address Pattern Converter
[ https://issues.apache.org/jira/browse/LOG4NET-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13104037#comment-13104037 ] Ron Grabowski commented on LOG4NET-235: --- I don't think having one aspnet pattern converter was the problem with those. It was more of a do we really want/need to expose _all_ the properties relating to HttpContext via pattern convertors? IP Address Pattern Converter Key: LOG4NET-235 URL: https://issues.apache.org/jira/browse/LOG4NET-235 Project: Log4net Issue Type: New Feature Components: Other Affects Versions: 1.2.10 Reporter: Adam Davies Priority: Trivial Fix For: 1.2 Maintenance Release Attachments: log4net - IP Address.zip Original Estimate: 0h Remaining Estimate: 0h Created AspNetIPAddressPatternConverter to provide the client IP Address. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: diffs between 1.2.10 and current trunk
The signature changes from void to ICollection shouldn't break anything. Now the configurators return a list of configuration messages. I suppose it should return an array of a certain type instead of just ICollection. Maybe something like ConfigurationMessage[] or LogLog[]. I lean more towards ConfigurationMessage[]...LogLog sounds like it came from the Department of Redundancy Department. Calls to LogLog are now required to pass in the Type of the caller which replaced inconsistent string identifiers to identify the source of internal log messages. From: Stefan Bodewig bode...@apache.org To: log4net-dev@logging.apache.org Sent: Tuesday, September 13, 2011 10:51 AM Subject: diffs between 1.2.10 and current trunk Hi all, in order to shape up for the release I diffed the 1.2.10 release ZIP source tree against current trunk's src and used BitDiffer from bitwidgets[1] to compare the DEBUG assemblies targeting 2.0 in binary. The results can be found in http://people.apache.org/~bodewig/log4net/diffs/ The source code diffs are mainly there so we can put together proper release notes and see whether there are changes not covered by resolved JIRA issues. They may also be useful to catch mistakes now, but that is going to require a long time and sharp eyes, I'm afraid. I've set up BitDiffer to not compare implementations but really only signatures. The breaking changes it flags right now: (1) the several variations of static Configure methods in configurators now return ICollection, they used to be void methods. (2) ConverterInfo used to be a nested class of PatternLayout and has been moved to the Util namespace. (3) The signature of the CreateLogger method in ILoggerFactory has changed. (4) Several LogLog method signatures have changed. Of this only (3) really concerns me as I consider ConverterInfo and LogLog internal to log4net and the change in return type shouldn't cause anything to break IMHO. The change in ILoggerFactory happend in svn revision 515275[2] for LOG4NET-97[3]. Back then Nicko was aware this was breaking BWC (the commit log says so) but accepted it as necessary. This likely means we should document the change and live with it. Stefan [1] http://bitwidgets.com/ [2] https://svn.apache.org/viewvc?view=revisionrevision=515275 [3] https://issues.apache.org/jira/browse/LOG4NET-97
Re: Name for MutexLock?
I don't have any hard numbers but the last time I played around with MinimalLock it was very very slow. I view InterProcessLock as an intermediary between exclusive and minimal locking. From: Dominik Psenner dpsen...@gmail.com To: 'Log4NET Dev' log4net-dev@logging.apache.org Sent: Tuesday, September 13, 2011 8:37 AM Subject: RE: Name for MutexLock? LOG4NET-164 introduced a new locking strategy for FileAppender which technically uses a System.Threading.Mutex with a name built from the log file's name. This should allow separate processes to share a log file without repeatedly opening and closing it. The main remaining issue is its name (apart from docs which will follow once the name is settled). Right now it is called MutexLock but that may not convey to users what this actually does - they'd need to know what a Mutex is in the first place. I'm notoriously bad at names so I'm asking here now. Names suggested in the JIRA ticket are InterProcessLock, SystemWideLock and GlobalLock. Are we talking about the variable name? In that case I would prefer a name that makes it obvious what it is behind: MutexLock :-) Did you actually do performance tests too? A mutex is rather expensive and it should be avoided to acquire/release it multiple times unless really necessary. Greetings, D.
[jira] [Commented] (LOG4NET-164) using a named mutex for file appenders
[ https://issues.apache.org/jira/browse/LOG4NET-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13104050#comment-13104050 ] Ron Grabowski commented on LOG4NET-164: --- I like the name InterProcessLock using a named mutex for file appenders -- Key: LOG4NET-164 URL: https://issues.apache.org/jira/browse/LOG4NET-164 Project: Log4net Issue Type: Improvement Components: Appenders Reporter: Frank Assignee: Ron Grabowski Fix For: 1.2.11 Attachments: MutexProcessLock.patch Original Estimate: 24h Remaining Estimate: 24h About logging to the same file from 2 or more instances of an application. As opposed to a minimallock which makes it still possible for 2 application instances to interfere. Why not use a named mutex so that the logging will wait for the lock to be released from another instance. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Name for MutexLock?
Can you share a config snippet showing how to use the RemotingAppender like you've described? What happens when one of the apps goes down? I envision the InterProcessLock as a locking model used between two low/medium chatty apps that want to write to the same file that may or may not be running at the same time. From: Roy Chastain r...@roychastain.org To: Log4NET Dev log4net-dev@logging.apache.org Sent: Tuesday, September 13, 2011 9:25 AM Subject: RE: Name for MutexLock? I like InterProcessLock and would like to propose MultiProcessLock as my favorite. I HOPE that the documentation will indicate what a bad plan this is and that a remoteing appender etc might be a better plan. -- Roy Chastain -Original Message- From: Stefan Bodewig [mailto:bode...@apache.org] Sent: Tuesday, September 13, 2011 06:47 To: log4net-dev@logging.apache.org Subject: Name for MutexLock? Hi, LOG4NET-164 introduced a new locking strategy for FileAppender which technically uses a System.Threading.Mutex with a name built from the log file's name. This should allow separate processes to share a log file without repeatedly opening and closing it. The main remaining issue is its name (apart from docs which will follow once the name is settled). Right now it is called MutexLock but that may not convey to users what this actually does - they'd need to know what a Mutex is in the first place. I'm notoriously bad at names so I'm asking here now. Names suggested in the JIRA ticket are InterProcessLock, SystemWideLock and GlobalLock. Stefan
RE: Name for MutexLock?
No, I do not have a configuration, but the idea would be to setup a logging application that would be the receiver of logging sent out from 2 or more applications using a remoting appender. Basically the same idea as remote Syslog application. Yes, it might be slow to log, but (other than the logging application crashing) should an alternative worth considering vs. the mutex. Of course the idea of the remoting appender becomes more attractive and robust once someone provides a WCF appender. -- Roy Chastain -Original Message- From: Ron Grabowski [mailto:rongrabow...@yahoo.com] Sent: Tuesday, September 13, 2011 18:44 To: Log4NET Dev Subject: Re: Name for MutexLock? Can you share a config snippet showing how to use the RemotingAppender like you've described? What happens when one of the apps goes down? I envision the InterProcessLock as a locking model used between two low/medium chatty apps that want to write to the same file that may or may not be running at the same time. From: Roy Chastain r...@roychastain.org To: Log4NET Dev log4net-dev@logging.apache.org Sent: Tuesday, September 13, 2011 9:25 AM Subject: RE: Name for MutexLock? I like InterProcessLock and would like to propose MultiProcessLock as my favorite. I HOPE that the documentation will indicate what a bad plan this is and that a remoteing appender etc might be a better plan. -- Roy Chastain -Original Message- From: Stefan Bodewig [mailto:bode...@apache.org] Sent: Tuesday, September 13, 2011 06:47 To: log4net-dev@logging.apache.org Subject: Name for MutexLock? Hi, LOG4NET-164 introduced a new locking strategy for FileAppender which technically uses a System.Threading.Mutex with a name built from the log file's name. This should allow separate processes to share a log file without repeatedly opening and closing it. The main remaining issue is its name (apart from docs which will follow once the name is settled). Right now it is called MutexLock but that may not convey to users what this actually does - they'd need to know what a Mutex is in the first place. I'm notoriously bad at names so I'm asking here now. Names suggested in the JIRA ticket are InterProcessLock, SystemWideLock and GlobalLock. Stefan
Re: Name for MutexLock?
On 2011-09-14, Ron Grabowski wrote: Can you share a config snippet showing how to use the RemotingAppender like you've described? We used to have an extraordinally simple Windows Service at $work that didn't do much but using log4net writing to a file and starting the RemoteLoggingServerPlugin. Unfortunately I don't think I can share the code (trivial as it is). The real applications would then all use RemotingAppenders. What happens when one of the apps goes down? The RemotingAppender tries to flush all message in shutdown but if things go really bad you may be losing some messages, this is true. Stefan
