You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Pero Atanasov (JIRA)" <ji...@apache.org> on 2014/12/12 23:52:13 UTC

[jira] [Created] (AMQ-5488) Broker should not log IOExceptions from TransportConnection class on WARN level when shutting down

Pero Atanasov created AMQ-5488:
----------------------------------

             Summary: Broker should not log IOExceptions from TransportConnection class on WARN level when shutting down
                 Key: AMQ-5488
                 URL: https://issues.apache.org/jira/browse/AMQ-5488
             Project: ActiveMQ
          Issue Type: Bug
          Components: Broker
    Affects Versions: 5.10.0
            Reporter: Pero Atanasov
            Priority: Minor


If the broker is in the process of shutting down, then prior function calls into the persistence adapter layer could result in and bubble back up with an IOException due to the fact that the broker is shutting down. Currently, such TransportConnection IOException(s) are handled and logged on the WARN level when actually they are harmless as the broker is shutting down. For one such example, please consider the following code blocks from  activemq-5.10.0:

activemq\activemq-broker\src\main\java\org\apache\activemq\broker\TransportConnection.java

Lines 933 - 937

try {
     broker.preProcessDispatch(messageDispatch);
} catch (RuntimeException convertToIO) {
     throw new IOException(convertToIO);
}

When this block throws the IOException, it is caught and further thrown from 

Lines 941 - 951

} catch (IOException e) {
     if (messageDispatch != null) {
          TransmitCallback sub = messageDispatch.getTransmitCallback();
           broker.postProcessDispatch(messageDispatch);
           if (sub != null) {
                sub.onFailure();
           }
           messageDispatch = null;
           throw e;
     }
}

When this block throws the exception, it is further caught and serviced by

Lines 989 - 995

} catch (IOException e) {
     if (dispatchStopped.compareAndSet(false, true)) {
          dispatchStoppedLatch.countDown();
     }
     serviceExceptionAsync(e);
     return false;
}

Lines 267 - 276 (serviceExceptionAsync) create a new "Async Exception Handler" thread which will invoke serviceException

Lines 287 - 289

if (e instanceof IOException) {
     serviceTransportException((IOException) e);
}

This will evaluate to true and hence serviceTransportException is invoked

Lines 242 - 246

if (TRANSPORTLOG.isDebugEnabled()) {
     TRANSPORTLOG.debug(this + " failed: " + e, e);
} else if (TRANSPORTLOG.isWarnEnabled() && !expected(e)) {
     TRANSPORTLOG.warn(this + " failed: " + e);
}

If debug is enabled, then it is OK for all IOExceptions to be logged. However, in the "else if" case, it is not considered if this TransportConnection IOException is being handled while the broker is shutting down. The suggestion is to consider the value of this.broker.getBrokerService().isStopping() as part of the expected(e) call to limit the amount of benign WARN messages that can show up in the log and cause confusion as the broker is shutting down.

A patch for this fix will be provided.





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)