[
https://issues.apache.org/jira/browse/AMQ-6581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839777#comment-15839777
]
Christopher L. Shannon commented on AMQ-6581:
---------------------------------------------
It's always tough to pick the right log level for some messages as the level
really depends on the use case. In the case of expired messages, sometimes
they are expected and other times it might indicate a larger issue that needs
troubleshooting as in your case.
It seems like logging expired messages at level WARN is too high to me even
though, generally speaking, most messages would probably be expired on the
broker side before dispatch so this scenario shouldn't happen too often. Would
the INFO level be acceptable in your use case?
> Change log level from DEBUG to WARN in ActiveMQMessageConsumer.dequeue(long
> timeout)
> ------------------------------------------------------------------------------------
>
> Key: AMQ-6581
> URL: https://issues.apache.org/jira/browse/AMQ-6581
> Project: ActiveMQ
> Issue Type: Improvement
> Components: JMS client
> Affects Versions: 5.x
> Environment: Camel 'from' endpoint for ActiveMQ component on Linux
> servers (ActiveMQ consumer client)
> Reporter: Richard O'Sullivan
> Priority: Minor
> Labels: easyfix
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Change the log level from DEBUG to WARN in the consumeExpiredMessage block of
> the dequeue(long timeout) method of the ActiveMQMessageConsumer class in the
> org.apache.activemq package.
> Currently, the consumeExpiredMessage block logs "{} received expired message:
> {}" at the DEBUG level when a message is picked from the queue and found to
> be expired. Other than the DEBUG log entry, the message is quietly consumed.
> In a Camel context, the message is not forwarded to the Camel route and the
> message appears to be lost because it is common practice to LOG at INFO or
> above in production environments.
> Proposed, change consumeExpiredMessage to WARN when a message is consumed and
> dropped.
> Rationale: Although, the disposition of expired messages should be an
> occasional occurrence, the expiration may become systematic when a NTP daemon
> fails to operate properly. (This is a real world case that caused a week long
> outage and is the reason for this request). Changing the level to WARN will
> reduce the diagnosis time significantly. When the producer and consumer are
> on different servers and are communicating with a broker over a network, the
> WARN message on the consumer will provide quick evidence that the message
> successfully crossed the network but was consumed (dropped) by the
> consumeExpiredMessage block.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
