Return-Path: X-Original-To: apmail-helix-user-archive@minotaur.apache.org Delivered-To: apmail-helix-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 332F8112DA for ; Fri, 19 Sep 2014 20:53:22 +0000 (UTC) Received: (qmail 23057 invoked by uid 500); 19 Sep 2014 20:53:21 -0000 Delivered-To: apmail-helix-user-archive@helix.apache.org Received: (qmail 23013 invoked by uid 500); 19 Sep 2014 20:53:21 -0000 Mailing-List: contact user-help@helix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@helix.apache.org Delivered-To: mailing list user@helix.apache.org Received: (qmail 23003 invoked by uid 99); 19 Sep 2014 20:53:21 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Sep 2014 20:53:21 +0000 X-ASF-Spam-Status: No, hits=-0.1 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of prvs=332ba4879=zzhang@linkedin.com designates 69.28.149.81 as permitted sender) Received: from [69.28.149.81] (HELO esv4-mav05.corp.linkedin.com) (69.28.149.81) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Sep 2014 20:53:17 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1411159997; x=1442695997; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=cEZWJmNJ+XfcAxrvHd0S/YeOiEfzW/X29XTmjngsdVQ=; b=vnfatpEjKPkSRGLQA/8vJSFLGAmYyMLwOV7atCq4Jmd/nSY9KYYcZ5+n FbvrZZs5zG0OOvJoRGO/q8rn0qQdBmy5YTkaz84tiu+YhthhrPa8Auhvo Ke/G8TUvQmkqjXoaTGcWxSfHP2tTFQwCJRkAb6GzhpgoSfk1Oq4edi4yA A=; X-IronPort-AV: E=Sophos;i="5.04,557,1406617200"; d="scan'208,217";a="142195252" Received: from ESV4-MB02.linkedin.biz ([fe80::8093:3d15:3c8e:a479]) by ESV4-HT02.linkedin.biz ([::1]) with mapi id 14.03.0195.001; Fri, 19 Sep 2014 13:52:56 -0700 From: Zhen Zhang To: "user@helix.apache.org" Subject: RE: Dropping resources does not clean up EXTERNALVIEW Thread-Topic: Dropping resources does not clean up EXTERNALVIEW Thread-Index: AQHP05iuEklPXhbBzUWbKG/bYV0ZIZwHi4eAgAHPk4D//5NA2Q== Date: Fri, 19 Sep 2014 20:52:56 +0000 Message-ID: <23CA11DC8830BA44A37C6B44B14D013C7DF70839@ESV4-MB02.linkedin.biz> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.250] Content-Type: multipart/alternative; boundary="_000_23CA11DC8830BA44A37C6B44B14D013C7DF70839ESV4MB02linkedi_" MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org --_000_23CA11DC8830BA44A37C6B44B14D013C7DF70839ESV4MB02linkedi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Varun, This bug should be fixed in 0.6.3. TestDrop#testBasic is a basic test case = for this and it's passing in 0.6.3. Could you please provide more details a= bout your case, like what ideal state mode you are using and how you drop t= he resource. Thanks, Zhen ________________________________ From: Varun Sharma [varun@pinterest.com] Sent: Friday, September 19, 2014 1:15 PM To: user@helix.apache.org Subject: Re: Dropping resources does not clean up EXTERNALVIEW I am using helix 0.6.3 - does that have this bug ? On Thu, Sep 18, 2014 at 4:36 PM, Zhen Zhang > wrote: Hi Varun, which version are you using? We fixed this problem both in trunk = and 0.6.x branch: 0.6.x: https://git-wip-us.apache.org/repos/asf?p=3Dhelix.git;a=3Dcommit;h=3Df3b2c4= f66acc700467cf99c7b28be1e494d724d7 trunk: https://git-wip-us.apache.org/repos/asf?p=3Dhelix.git;a=3Dcommit;h=3Db470ab= aba8727fc5534bc8dc00b3f4a3cd9076e8 Thanks, Zhen From: Varun Sharma > Reply-To: "user@helix.apache.org" > Date: Thursday, September 18, 2014 4:31 PM To: "user@helix.apache.org" > Subject: Dropping resources does not clean up EXTERNALVIEW I have been dropping resources. However, it seems that the EXTERNALVIEW fol= der is not cleaning up. Lots of empty resources are accumulating over there= . The znode contains empty "listFields" and "mapFields". How do I ensure that EXTERNALVIEW is also cleaned up when a resource is dro= pped. Thanks Varun --_000_23CA11DC8830BA44A37C6B44B14D013C7DF70839ESV4MB02linkedi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Varun,

This bug should be fixed in 0.6.3. TestDrop#testBasic is a basic test case = for this and it's passing in 0.6.3. Could you please provide more details a= bout your case, like what ideal state mode you are using and how you drop t= he resource.

Thanks,
Zhen


From: Varun Sharma [varun@pinterest.com]<= br> Sent: Friday, September 19, 2014 1:15 PM
To: user@helix.apache.org
Subject: Re: Dropping resources does not clean up EXTERNALVIEW

I am using helix 0.6.3 - does that have this bug ?

On Thu, Sep 18, 2014 at 4:36 PM, Zhen Zhang <zzhang@linkedi= n.com> wrote:
Hi Varun, which version are you using? We fixed this problem both in t= runk and 0.6.x branch:

0.6.x:

trunk:

Thanks,
Zhen

From: Varun Sharma <varun@pinterest.com> Reply-To: "user@helix.apache.org" <= ;user@helix.apac= he.org>
Date: Thursday, September 18, 2014 = 4:31 PM
To: "user@helix.apache.org" <user@helix.apache.org= >
Subject: Dropping resources does no= t clean up EXTERNALVIEW

I have been dropping resources. However, it seems that the= EXTERNALVIEW folder is not cleaning up. Lots of empty resources are accumu= lating over there. The znode contains empty "listFields" and &quo= t;mapFields".

How do I ensure that EXTERNALVIEW is also cleaned up when a resource i= s dropped.

Thanks
Varun

--_000_23CA11DC8830BA44A37C6B44B14D013C7DF70839ESV4MB02linkedi_--