ADO.Net Appender is not writing all the records to the table in a high 
load/user scenario.It stops writing to the table untill i restart my app 
servers.Also sometimes, it drops few records and writes the rest of the records.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

                 Key: LOG4NET-288
                 URL: https://issues.apache.org/jira/browse/LOG4NET-288
             Project: Log4net
          Issue Type: Bug
          Components: Appenders
    Affects Versions: 1.2.9
         Environment: Windows 2008 server , IIS7.0 web site, Sql Server 2008 
DB, ASP.net 2.0, .Net 3.0
            Reporter: Chetan Appannagari
            Priority: Blocker


We are using ADO.net appender to write audit records to the a table. Being an 
Audit table, all the actions performed by the user are recorded to this table 
along with the User's information like username,account information etc. In 
production environment we have close to 900-1000 users CONCURRENTLY accessing 
the system Monday - Sunday. Since every action of each user if tracked to Audit 
table, we have close to 50,000-200,000 records created every dya in this table.

The problem is, in between, the ADO.Net appender is not writing all the records 
to the table. It drops a few records and writes the rest. And 
sometimes(happenned 3-4 times in production), it just stops writing to the 
table, untill we restart the app servers( IISRESET command). So basically 2 
problems.

Currently in PRODUCTION we haven't set reconnectOnError  = "true" in the 
web.config file. We will be setting this in our next PROD build. Will this 
solve the 2nd Issue(just stops writing to table)?.

We will enable internal debugging in the config file as well in the next PROD 
build. Will this let us know the exact reason why we are having these issues?

Has this sort of problem been reported earlier?

This is a highly critical issue. If we do not get answers to these quickly we 
may have to look at other options, which i personally don't want to do.









--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to