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

Jay Kreps updated KAFKA-371:
----------------------------

    Attachment: KAFKA-371-0.8-v2.patch

Neha can you sanity check this? Here are the changes:

- Remove some unneeded getter getServerConfig
- Rename getTopicIterator to topics()
- Simplify getLogIterator() and rename to allLogs()
- Remove awaitStartup latch and awaitStartup latch acquisition. The comment on 
startup() says it registers in zookeeper, but this doesn't seem to be true
- Remove getLogPool. createLog checks correctness of creation, and fails if it 
fails. getLog returns null if the log doesn't exist, as per the contract. 
getOrCreateLog will fail when createLog fails. I think this is more sensible, 
and elimantes the getter
- Remove the word "Map" from things of type Map
- MS should be Ms by our usual conventions
- Remove helper getLogRetentionMSMap

I think the latch was there because log manager was somehow doing zk 
registration (according to comments). But I don't see that code there at all 
now, and logManager shouldn't be talking to zk, so i think it got cleaned up. 
So now theoretically we shouldn't need that and the weird ordering where we 
take requests before log manager is initiatialized but then block should not be 
needed. 

Also, I removed the EasyMock verification on logmanager (I think all it does is 
check that the config was fetched), which I don't think is useful? But EasyMock 
is kind of a blackbox to me.
                
> Creating topic of empty string puts broker in a bad state
> ---------------------------------------------------------
>
>                 Key: KAFKA-371
>                 URL: https://issues.apache.org/jira/browse/KAFKA-371
>             Project: Kafka
>          Issue Type: Bug
>    Affects Versions: 0.6, 0.7
>            Reporter: Martin Kleppmann
>            Assignee: Jay Kreps
>             Fix For: 0.8
>
>         Attachments: KAFKA-371-0.7.1.patch, KAFKA-371-0.8-v2.patch, 
> KAFKA-371-0.8.patch
>
>
> Using the Java client library, I accidentally published a message where the 
> topic name was the empty string. This put the broker in a bad state where 
> publishing became impossible, and the following exception was logged 10-20 
> times per second:
> 2012-06-21 00:41:30,324 [kafka-processor-3] ERROR kafka.network.Processor  - 
> Closing socket for /127.0.0.1 because of er
> ror
> kafka.common.InvalidTopicException: topic name can't be empty
>         at kafka.log.LogManager.getOrCreateLog(LogManager.scala:165)
>         at 
> kafka.server.KafkaRequestHandlers.kafka$server$KafkaRequestHandlers$$handleProducerRequest(KafkaRequestHandle
> rs.scala:75)
>         at 
> kafka.server.KafkaRequestHandlers.handleProducerRequest(KafkaRequestHandlers.scala:58)
>         at 
> kafka.server.KafkaRequestHandlers$$anonfun$handlerFor$1.apply(KafkaRequestHandlers.scala:43)
>         at 
> kafka.server.KafkaRequestHandlers$$anonfun$handlerFor$1.apply(KafkaRequestHandlers.scala:43)
>         at kafka.network.Processor.handle(SocketServer.scala:289)
>         at kafka.network.Processor.read(SocketServer.scala:312)
>         at kafka.network.Processor.run(SocketServer.scala:207)
>         at java.lang.Thread.run(Thread.java:679)
> Restarting Kafka did not help. I had to manually clear out the bad state in 
> Zookeeper to resolve the problem.
> The broker should not accept a message that would put it in such a bad state.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to