You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4net-dev@logging.apache.org by "Tom Tang (JIRA)" <ji...@apache.org> on 2012/05/31 06:25:22 UTC
[jira] [Created] (LOG4NET-344) Make AdoNetAppender not to stuck
application process
Tom Tang created LOG4NET-344:
--------------------------------
Summary: 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
Fix For: 3.5
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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-344) Make AdoNetAppender not to stuck
application process
Posted by "Tom Tang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tom Tang updated LOG4NET-344:
-----------------------------
Attachment: (was: AsyncForwardingAppender.cs)
> 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: 3.5
>
> Attachments: AdoNetAppender.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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-344) Make AdoNetAppender not to stuck
application process
Posted by "Dominik Psenner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13286475#comment-13286475 ]
Dominik Psenner commented on LOG4NET-344:
-----------------------------------------
Hi Tom, thanks for your work. Just a few comments:
1] The AdoNetAppender is an implementation of the BufferingAppenderSkeleton and thus I would assume that it already caches log messages and processes them asynchronously?
If I'm wrong with assumption 1]:
2] Trace.WriteLine is generally not used by log4net, but rather it uses its own implementation namely LogLog. It can be used as LogLog.Debug("message")
3] Using Thread.Sleep() to reduce idle cpu cycles has several impacts. One is that log messages are (worst case) cached for about a second before being processed. Since an application can log a lot during that time this increases the probability of outofmemory exceptions. Further it reduces the responsiveness of the logging facility. This ensures also that crash log messages of uncatched exceptions will not make it into the persistent log database before the application is terminated.
4] Last but not least I believe that it makes much more sense to keep the current AdoNetAppender and extend it by creating a subclass named AsyncAdoNetAppender that adds the async functionality. This allows to swap between the normal and the asynch appender.
Regarding 3] I would rather implement it with a ThreadPool workerthread that is started on demand. Further I would implemented it using two queues that are hotswapped whenever there is a event in the outer queue but none in the inner queue.
Cheers
> 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: 3.5
>
> Attachments: AdoNetAppender.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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-344) Make AdoNetAppender not to stuck
application process
Posted by "Tom Tang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tom Tang updated LOG4NET-344:
-----------------------------
Attachment: AsyncForwardingAppender.cs
Revise to have its own BlockingCollection implementation without any external dependency.
> 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: 3.5
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-344) Make AdoNetAppender not to stuck
application process
Posted by "Tom Tang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13286502#comment-13286502 ]
Tom Tang commented on LOG4NET-344:
----------------------------------
Hi, Dominik:
Thanks for your quick reply.
1] Unfortunately, BufferingAppenderSkeleton is not using async way to consume these messages.
It stored them and flush them once the counter reach the size limit. All are in sync invocation. That's why I'm headache now.
The most simple way to prove, use AdoNetAppender to write database log, then begin an uncommitted updating transaction on the table, you will find your application suspend outside till the execute timeout(30 sec in default).
And every [buffersize] log invocation, your application will hang 30 sec till you end up the transaction.
2] Got you. I can update the implementation by this.
3] My implementation won't have OutOfMemoryException issue., due to I drop these LoggingEvent objects once if my inner queue is full. If there's no size limit design in my inner queue, your concern could be true.
But you're right with the crash log could be missed from persistent log in DB during the sleep duration.
4] Create a subclass for such implementation is now what my workaround is, but I'm not satisfied with this situation. It makes our cross teams developers have to reference an external DLL or source code for the subclass implementation. I would like if we can give one more parameter to switch the sync/async mode in AdoNetAppender? If there's no such new parameter in configuration, AdoNetAppender can do what it's doing now as usual.
About 3] again. I may not full-understand your design suggestion about using 2 queues.
> 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: 3.5
>
> Attachments: AdoNetAppender.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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-344) Make AdoNetAppender not to stuck
application process
Posted by "Tom Tang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tom Tang updated LOG4NET-344:
-----------------------------
Attachment: AdoNetAppender.cs
Here's my new implementation as what I described in ticket content.
I wish to be one of project contributor, what shall I do?
Wish this code patch could be merged into the official release ASAP. :)
I'm going to use this feature with our product.
Best regards
> 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: 3.5
>
> Attachments: AdoNetAppender.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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-344) Make AdoNetAppender not to stuck
application process
Posted by "Tom Tang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tom Tang updated LOG4NET-344:
-----------------------------
Attachment: AsyncForwardingAppender.cs
I found there's a much smart idea to resolve this, and doesn't take any risk to change any current implementation of appenders.
Provide an async forwarding appender that can wrap any existing appender. It makes all appenders able to work in async way!
I got this idea from the url:
http://stackoverflow.com/a/9314846
After some enhancements, I release here within the attachment.
I wish the official release could include this new appender ASAP.
> 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: 3.5
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-344) Make AdoNetAppender not to stuck
application process
Posted by "Stefan Bodewig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291557#comment-13291557 ]
Stefan Bodewig commented on LOG4NET-344:
----------------------------------------
Tom, thanks, your work is very much appreciated.
I need to find more (actually any) time to look into your patch and Ron's code to provide a substantial comment. In any case I agree we should have support for this kind of async appending inside log4net itself.
> 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: 3.5
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-344) Make AdoNetAppender not to stuck
application process
Posted by "Tom Tang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13289998#comment-13289998 ]
Tom Tang commented on LOG4NET-344:
----------------------------------
Hi, Ron:
I got your point, and thanks for that.
I have granted the ASF license on the contributed code snippet, wish to save time for merging the feature back to official release.
Means all participants could improve it in their own opinions.
I think team guys will improve it in the best effort if they decide to take it.
I may not walk around here and do maintenance by the way keeping submit file attachment for minor changes.
Your advice are all wisdom. I just wouldn't do the revisions.
Cheers :)
> 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: 3.5
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-344) Make AdoNetAppender not to stuck
application process
Posted by "Ron Grabowski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13288947#comment-13288947 ]
Ron Grabowski commented on LOG4NET-344:
---------------------------------------
When I posted a link to AsyncBulkInsertAppender.cs I wanted the focus to be more on the threading code rather than limiting it to just BulkInsert operations.
Taking the interesting parts AsyncBulkInsertAppender.cs and extending BufferingForwardingAppender gives us async support in about 30 lines of code:
// https://github.com/lorenzomelato/rhino-commons/blob/master/Rhino.Commons/Logging/AsyncBulkInsertAppender.cs
protected override void SendBuffer(LoggingEvent[] events)
{
ThreadPool.QueueUserWorkItem(delegate
{
lock (syncLock)
{
eventsList.AddLast(events);
if (anotherThreadAlreadyHandlesLogging)
return;
anotherThreadAlreadyHandlesLogging = true;
}
while (true)
{
LoggingEvent[] current;
lock (syncLock)
{
if (eventsList.Count == 0)
{
anotherThreadAlreadyHandlesLogging = false;
return;
}
current = eventsList.First.Value;
eventsList.RemoveFirst();
}
base.SendBuffer(current);
}
});
}
Some suggestions for improving your AsyncForwardingAppender...change the variable names that reference "File" and make the buffer size settable. I don't see the benefit of using dedicated thread in this case because you aren't giving the thread a chance to shutdown and process its messages when the repository shutsdown. Modern CLRs have lots of threads available in the pool, just use one of those.
> 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: 3.5
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-344) Make AdoNetAppender not to stuck
application process
Posted by "Ron Grabowski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13287014#comment-13287014 ]
Ron Grabowski commented on LOG4NET-344:
---------------------------------------
I recommend using this:
https://github.com/lorenzomelato/rhino-commons/blob/master/Rhino.Commons/Logging/AsyncBulkInsertAppender.cs
> 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: 3.5
>
> Attachments: AdoNetAppender.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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-344) Make AdoNetAppender not to stuck
application process
Posted by "Tom Tang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tom Tang updated LOG4NET-344:
-----------------------------
Attachment: AsyncForwardingAppender.cs
Submit the attachment again within license grant checkbox checked.
:)
> 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: 3.5
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-344) Make AdoNetAppender not to stuck
application process
Posted by "Stefan Bodewig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13288475#comment-13288475 ]
Stefan Bodewig commented on LOG4NET-344:
----------------------------------------
BlockingCollection makes this a .NET 4 only option. I'm not suggesting this is bad, but if you knew of a simple substitute for .NET 2.x the appender could be even more useful.
> 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: 3.5
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-344) Make AdoNetAppender not to stuck
application process
Posted by "Tom Tang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13287130#comment-13287130 ]
Tom Tang commented on LOG4NET-344:
----------------------------------
Hi, Ron:
Thanks for this recommendation.
This one is cool for large amount of logging insertion.
Although it uses async way on doing log, but the bulk insertion strategy may not good to be everywhere.
Bulk insertion do table lock for efficiency concern, that one I don't like.
I prefer to do normal insertion within small piece data(buffersize is small) to represent system healthy info ASAP. And thousands of threads or processes could do concurrent accessing by log4net.
As I know, normal data insertion by simple SQL statement wouldn't lock table, but bulk-insertion does.
But that one is still cool, I would like to use for other purpose in future.
Thanks for the recommendation again.
Cheers
> 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: 3.5
>
> Attachments: AdoNetAppender.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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-344) Make AdoNetAppender not to stuck
application process
Posted by "Stefan Bodewig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13288474#comment-13288474 ]
Stefan Bodewig commented on LOG4NET-344:
----------------------------------------
Many thanks Tom!
Either you have forgotten to check the "grant license to ASF" checkbox when uploading your patch or the UI in JIRA has changed. Could you please double check and grant us a license explictly? Sorry for the paperwork.
> 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: 3.5
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-344) Make AdoNetAppender not to stuck
application process
Posted by "Tom Tang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13288480#comment-13288480 ]
Tom Tang commented on LOG4NET-344:
----------------------------------
Stefan Bodewing:
.NET 3.5 has an optional extension package that provide the same class as .NET 4.0. I'm using that extension one.
However this is not difficult to implement a same functionality as BlockingCollection.
If it become a concern, I can provide a new implementation.
> 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: 3.5
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-344) Make AdoNetAppender not to stuck
application process
Posted by "Tom Tang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tom Tang updated LOG4NET-344:
-----------------------------
Attachment: (was: AsyncForwardingAppender.cs)
> 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: 3.5
>
> Attachments: AdoNetAppender.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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira