I found that after a failed log entry (JdbcAppender) in mysql (I believe 5.0 but I'm not sure), mysql does in fact write the entry, but an error must be returned at some point because it's not removed from the buffer. This happened after writing non-ascii characters to the field, or after exceeding the 255 character limit I had set on the field. I fixed this by moving "removes.add(logEvent);" to be BEFORE the execute(sql); statement, which ensures it will always get removed, even if an error occurs. Since this is not necessarily the desired behavior for all apps, I would recommend exposing this as a setting on the class, controlled via some variable like "removeFromBufferOnError" or something more creative. This is my first posting to a jakarta project -- thanks for all the hard work that makes our lives easier!
I'm not a log4j developer, but happened to be looking at this at work. It seems to me that chiefly MySQL is at fault here if it is indeed throwing an error and yet still writing it to the db. It seems that log4j could solve this by changing the execute() method to be in charge of adding to the removes.add(..) call, and then having a setAutoCommit in there so that a rollback is performed if an Exception is thrown (and the removes.add(...) is not done). This change of responsibility might be bad for subclasses; so the other option would be to change execute() to take a Connection parameter and put flushBuffer() in charge of the Connection.
Please provide sample code demonstrating the behaviour described.