[
https://issues.apache.org/jira/browse/KAFKA-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13725351#comment-13725351
]
Jun Rao commented on KAFKA-649:
-------------------------------
Thanks for patch v3.
30. KafkaApi.readMessageSets(): We don't know how we hit the exception. So a
stacktrace could be useful.
31. BoundedByteBufferReceive.byteBufferAllocate(): This is the case that we
don't know who the caller is. So a stacktrace could be useful.
32. MirrorMakerThread: It's probably better to prefix the log indentation with
the thread name.
33. SimpleConsumer: We should log the message of the exception. We just don't
need to show the stack trace.
34. About capitalize the first letters. This is a good change. However, it
should probably be done in trunk since trunk is where we want to do non-trivial
code cleanup. Could you file a separate jira to tract that?
> Cleanup log4j logging
> ---------------------
>
> Key: KAFKA-649
> URL: https://issues.apache.org/jira/browse/KAFKA-649
> Project: Kafka
> Issue Type: Improvement
> Affects Versions: 0.8
> Reporter: Jay Kreps
> Assignee: Jun Rao
> Priority: Blocker
> Attachments: kafka-649_extra.patch, kafka-649.patch,
> KAFKA-649.v3.patch
>
>
> Review the logs and do the following:
> 1. Fix confusing or duplicative messages
> 2. Assess that messages are at the right level (TRACE/DEBUG/INFO/WARN/ERROR)
> It would also be nice to add a log4j logger for the request logging (i.e. the
> access log) and another for the controller state change log, since these
> really have their own use cases.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
