activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pero Atanasov (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (AMQ-5488) Broker should not log IOExceptions from TransportConnection class on WARN level when shutting down
Date Fri, 12 Dec 2014 23:10:13 GMT

     [ https://issues.apache.org/jira/browse/AMQ-5488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Pero Atanasov updated AMQ-5488:
-------------------------------
    Labels:   (was: patch)

> 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
>         Attachments: AMQ5488.patch
>
>
> 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)

Mime
View raw message