[jira] [Commented] (LOG4NET-412) Millisecond always return 0 in wince
[ https://issues.apache.org/jira/browse/LOG4NET-412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14390067#comment-14390067 ] Dominik Psenner commented on LOG4NET-412: - I almost am convinced that if the operating system / framework / whoever does not report milliseconds, log4net shouldn't try to do fancy things that might make the situation even worse. Millisecond always return 0 in wince - Key: LOG4NET-412 URL: https://issues.apache.org/jira/browse/LOG4NET-412 Project: Log4net Issue Type: Bug Components: Appenders Affects Versions: 1.3.0 Environment: NETCF Reporter: Son Tran Priority: Trivial Labels: DateTime, As I check the DateTime.Ticks is used in function AbsoluteTimeDateFormatter.FormatDate always return 0 work around by using Enviroment.TichCount. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (LOG4NET-412) Millisecond always return 0 in wince
[ https://issues.apache.org/jira/browse/LOG4NET-412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14390067#comment-14390067 ] Dominik Psenner edited comment on LOG4NET-412 at 4/1/15 6:28 AM: - I almost am convinced that if the operating system / framework / whoever does not report milliseconds, log4net shouldn't try to do fancy things that might make the situation even worse. After all we will never be able to calculate a good value if the hardware lacks the capabilities. was (Author: nachbarslumpi): I almost am convinced that if the operating system / framework / whoever does not report milliseconds, log4net shouldn't try to do fancy things that might make the situation even worse. Millisecond always return 0 in wince - Key: LOG4NET-412 URL: https://issues.apache.org/jira/browse/LOG4NET-412 Project: Log4net Issue Type: Bug Components: Appenders Affects Versions: 1.3.0 Environment: NETCF Reporter: Son Tran Priority: Trivial Labels: DateTime, As I check the DateTime.Ticks is used in function AbsoluteTimeDateFormatter.FormatDate always return 0 work around by using Enviroment.TichCount. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LOG4NET-412) Millisecond always return 0 in wince
[ https://issues.apache.org/jira/browse/LOG4NET-412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14390567#comment-14390567 ] Stefan Bodewig commented on LOG4NET-412: I tend to agree. Millisecond always return 0 in wince - Key: LOG4NET-412 URL: https://issues.apache.org/jira/browse/LOG4NET-412 Project: Log4net Issue Type: Bug Components: Appenders Affects Versions: 1.3.0 Environment: NETCF Reporter: Son Tran Priority: Trivial Labels: DateTime, As I check the DateTime.Ticks is used in function AbsoluteTimeDateFormatter.FormatDate always return 0 work around by using Enviroment.TichCount. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LOG4NET-412) Millisecond always return 0 in wince
[ https://issues.apache.org/jira/browse/LOG4NET-412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14390566#comment-14390566 ] Stefan Bodewig commented on LOG4NET-412: Hmm, after about 25 days Environment.Ticks starts to wrap around and returns negative values. I'm not sure where you find CF nowadays, but I wouldn't rely on those systems restarting regularly :-) Millisecond always return 0 in wince - Key: LOG4NET-412 URL: https://issues.apache.org/jira/browse/LOG4NET-412 Project: Log4net Issue Type: Bug Components: Appenders Affects Versions: 1.3.0 Environment: NETCF Reporter: Son Tran Priority: Trivial Labels: DateTime, As I check the DateTime.Ticks is used in function AbsoluteTimeDateFormatter.FormatDate always return 0 work around by using Enviroment.TichCount. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (LOG4NET-344) Make AdoNetAppender not to stuck application process
[ https://issues.apache.org/jira/browse/LOG4NET-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved LOG4NET-344. Resolution: Fixed Fix Version/s: (was: 3.5) 1.3.0 Promoted (and simplified) the AsyncAppender from log4net's examples to log4net proper. If you need buffering, nest the AsyncAppender into a BufferingFormwardingAppender. Make AdoNetAppender not to stuck application process Key: LOG4NET-344 URL: https://issues.apache.org/jira/browse/LOG4NET-344 Project: Log4net Issue Type: Improvement Components: Appenders Affects Versions: 1.2.10 Environment: Windows series Reporter: Tom Tang Labels: patch Fix For: 1.3.0 Attachments: AdoNetAppender.cs, AsyncForwardingAppender.cs Original Estimate: 24h Remaining Estimate: 24h The original AdoNetAppender could stuck application during log insertion. Because it use the sync method call to do database insert, once the DB is unavailable or table was locked. I change the implementation that has an inner queue inside to store the messages, and the other independent thread will be going to cunsuming the queue messages and do DB insertion. This implementation will not have any impact on application performance and much stable. Trade off: Once the queue max buffer was full, the later coming log message would be ignored and gone forever. But log4net is not designed for guarantee delivery in purpose, right? So it's not big deal at all. :) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LOG4NET-407) AsyncAppender - better Implementation
[ https://issues.apache.org/jira/browse/LOG4NET-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14391132#comment-14391132 ] Stefan Bodewig commented on LOG4NET-407: svn revision 1670747 contains a hybrid of Michael's code, as well as code found in LOG4NET-344 and the existing AsyncAppender of the example. It should keep event order for all versions and not lose LoggingEvents when used on .NET = 4.0. Documentation is still needed, that's why I'm not closing the ticket immediately. AsyncAppender - better Implementation - Key: LOG4NET-407 URL: https://issues.apache.org/jira/browse/LOG4NET-407 Project: Log4net Issue Type: Improvement Components: Appenders Environment: .Net 4.0 and newer Reporter: Michael Goldfinger Priority: Minor Fix For: 1.3.0 I checked out the AsyncAppender (http://svn.apache.org/viewvc/logging/log4net/trunk/examples/net/2.0/Appenders/SampleAppendersApp/cs/src/Appender/AsyncAppender.cs?view=markup) and found some drawbacks. * logevents are not logged if the appender close * order of logevents got lost I created an new implementation that waits for all logevents to be computed before close and maintains the order of the events. If the application process got killed the logevents are lost too but in any other case the loss of logevents could be prevented. The drawback of my implementation is that the TLP is requred so .NET 2.0 is not supported. I could not find the place to contribute so I created this ticket. I hope it's useful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
