[ https://issues.apache.org/jira/browse/KAFKA-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13955761#comment-13955761 ]
Guozhang Wang edited comment on KAFKA-1350 at 3/31/14 9:51 PM: --------------------------------------------------------------- Hi Joel, I think we are on the same page as for your first question, if we use getLogger(), the logger API itself will always evaluate the string.format; but as long as we use the Logging as Neha's patch did, it will call-by-name and hence effectively do lazy evaluation. For the second question, since my test code reset count to 0, it would either be 1 or 2 for any cases, right? was (Author: guozhang): Hi Joel, I think we are on the same page as for your first question, if we use getLogger(), the logger API itself will always evaluate the string.format; but as long as we use the Logging as Neha's patch did, it will call-by-name and hence effectively do lazy evaluation. For the second question, since my test code reset count to 0, it would either be 1 or 0 for any cases, right? > Fix excessive state change logging > ---------------------------------- > > Key: KAFKA-1350 > URL: https://issues.apache.org/jira/browse/KAFKA-1350 > Project: Kafka > Issue Type: Bug > Affects Versions: 0.8.1 > Reporter: Joel Koshy > Assignee: Neha Narkhede > Priority: Blocker > Fix For: 0.8.1.1 > > Attachments: KAFKA-1350.patch, KAFKA-1350_2014-03-29_23:28:07.patch > > > I can provide steps to reproduce this issue. The state change logger needs > to be guarded (to check if trace logging is turned on or not). > The delete topic patch significantly increased the amount of logging that we > do both on the controller. This results in higher latencies in state > transitions and can slow down the controller (as well as the broker). This > slow-down was how we ran into KAFKA-1342. -- This message was sent by Atlassian JIRA (v6.2#6252)