[
https://issues.apache.org/jira/browse/ARTEMIS-2385?focusedWorklogId=262366&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-262366
]
ASF GitHub Bot logged work on ARTEMIS-2385:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 18/Jun/19 15:06
Start Date: 18/Jun/19 15:06
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on pull request #2714:
ARTEMIS-2385 Log header for rejecting message with too large header
URL: https://github.com/apache/activemq-artemis/pull/2714#discussion_r294874700
##########
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/persistence/impl/journal/JournalStorageManager.java
##########
@@ -556,6 +556,12 @@ public LargeServerMessage createLargeMessage(final long
id, final Message messag
final int messageEncodeSize = largeMessage.getEncodeSize();
if (messageEncodeSize > maxRecordSize) {
+ if (logger.isDebugEnabled()) {
+ logger.debug("Message header too large for " + largeMessage);
+ } else {
+ logger.warn("Message with id " + largeMessage.getMessageID()
+ " has a header too large. Set log level to debug to log the message header.");
Review comment:
two things:
- the logger.warn should always be called, no matter what.
- Can you use a Logger with an ID here?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 262366)
Time Spent: 20m (was: 10m)
> Log header for rejecting message with too large header
> ------------------------------------------------------
>
> Key: ARTEMIS-2385
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2385
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Reporter: Domenico Bruscino
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The usage scenario I am thinking about; broker admins see many of these
> rejections but no way to trace it back to the application that is sending the
> offending message(s) to the broker. I have seen this scenario a few times,
> where broker admins had issues identifying which applications were
> responsible for these messages; so any data to help identify the offending
> message would be very useful.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
