You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by bu...@apache.org on 2005/12/14 12:50:15 UTC

DO NOT REPLY [Bug 37904] New: - AsynchAppender wait for ever when buffer is full

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=37904>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37904

           Summary: AsynchAppender wait for ever when buffer is full
           Product: Log4j
           Version: 1.2
          Platform: Other
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Appender
        AssignedTo: log4j-dev@logging.apache.org
        ReportedBy: jan.kronquist@jayway.se


When the BoundedFIFO is full the AsynchAppender will wait for ever for the
Dispatcher to remove an element from the buffer. This might seem reasonable as
this will not happen very often, but the following problem occurred in our
production environment:

We wanted to send a mail for certain exceptions. However, the SMTP server was
incorrectly configured which caused the Dispatcher thread to hang for several
minutes for each event. The buffer quickly filled up and then the AsynchAppender
also waited several minutes until all exceptions had been processed.

This was quite difficult to debug since the server seemed to work fine and only
slowed down a while after the error occurred and the file logging worked fine.
We did not realize that the fact that we did not get the email was related to
the server slowing down or hanging. As the server only hang during a couple of
minutes it took a while until we managed to get a thread dump.

The purpose of using AsynchAppender is to avoid blocking the current thread,
therefore I think that the AsynchAppender should handle the buffer full
situation better.

Two different solution proposals:
1) Log something when the buffer is full. This will make this condition easier
to find and will probably only occur in exceptional cases.
2) Limit the time to wait on the buffer. Log and give up when this limit is
exceeded. This will have some extra overhead, but the server will not be blocked
because of incorrect configuration. The timeout should be possible to configure.  

1) Log something when the buffer is full:
      while (bf.isFull()) {
        try {
          LogLog.warn("AsynchAppender buffer is full!!");
          bf.wait();

2) Limit the time to wait on the buffer: 
      long before = System.currentTimeMillis();
      while (bf.isFull()) {
        try {
          //LogLog.debug("Waiting for free space in buffer, "+bf.length());
          bf.wait(this.bufferTimeout);
          if (System.currentTimeMillis()-before >= this.bufferTimeout) {
             LogLog.error("AsynchAppender failed to log event within specified
timeout. event=" + event);
	     return;
          }


(The same problem exists in 1.3)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org