Return-Path: X-Original-To: apmail-kafka-dev-archive@www.apache.org Delivered-To: apmail-kafka-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 2A6B3F94B for ; Wed, 3 Apr 2013 22:09:16 +0000 (UTC) Received: (qmail 14629 invoked by uid 500); 3 Apr 2013 22:09:16 -0000 Delivered-To: apmail-kafka-dev-archive@kafka.apache.org Received: (qmail 14600 invoked by uid 500); 3 Apr 2013 22:09:16 -0000 Mailing-List: contact dev-help@kafka.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@kafka.apache.org Delivered-To: mailing list dev@kafka.apache.org Received: (qmail 14590 invoked by uid 99); 3 Apr 2013 22:09:15 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Apr 2013 22:09:15 +0000 Date: Wed, 3 Apr 2013 22:09:15 +0000 (UTC) From: "Swapnil Ghike (JIRA)" To: dev@kafka.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (KAFKA-330) Add delete topic support MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/KAFKA-330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13621397#comment-13621397 ] Swapnil Ghike commented on KAFKA-330: ------------------------------------- Replying to a few comments, will follow up with changes according to others: On the controller side: 1. I think that the delete topics command will not take too long to complete, in any case it won't take any longer than Preferred Replica Election command. Both commands write to /admin zk path and trigger listeners that may send send some requests and update some zk paths. I believed that the reason for relinquishing the lock in ReassignPartitions listeners after every partition reassignment was that the controller waits for the new replicas to join the ISR, which could take long. 2. Hence I think that we should not relinquish the lock between deletion of two topics. 3. So maybe we don't need to use two separate zk paths? If we rerun the DeleteTopicsCommand, it should complain that the topics are absent in zookeeper if the topics were successfully deleted. On the broker side: 4. LogManager: 1. deleteLogs() indeed removes the logs from allLogs. 2. delete() is invoked on every individual log. 3. Yes, following up on this. 5. Log: 1. The lock is acquired by all these functions, but I will double check if it needs to be acquired at the top level for our purpose. 3. Well, log.delete() takes care of deleting the individual segments. Will make modifications to Log*, hopefully they will address all your comments. > Add delete topic support > ------------------------- > > Key: KAFKA-330 > URL: https://issues.apache.org/jira/browse/KAFKA-330 > Project: Kafka > Issue Type: Bug > Components: controller, log, replication > Affects Versions: 0.8 > Reporter: Neha Narkhede > Assignee: Swapnil Ghike > Priority: Blocker > Labels: features, kafka-0.8, p2, project > Fix For: 0.8 > > Attachments: kafka-330-v1.patch > > > One proposal of this API is here - https://cwiki.apache.org/confluence/display/KAFKA/Kafka+replication+detailed+design+V2#KafkareplicationdetaileddesignV2-Deletetopic -- 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