Return-Path: X-Original-To: apmail-accumulo-user-archive@www.apache.org Delivered-To: apmail-accumulo-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 338301107A for ; Mon, 2 Jun 2014 02:17:36 +0000 (UTC) Received: (qmail 45144 invoked by uid 500); 2 Jun 2014 02:17:36 -0000 Delivered-To: apmail-accumulo-user-archive@accumulo.apache.org Received: (qmail 45092 invoked by uid 500); 2 Jun 2014 02:17:36 -0000 Mailing-List: contact user-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@accumulo.apache.org Delivered-To: mailing list user@accumulo.apache.org Received: (qmail 45084 invoked by uid 99); 2 Jun 2014 02:17:36 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Jun 2014 02:17:36 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of busbey@cloudera.com designates 209.85.192.45 as permitted sender) Received: from [209.85.192.45] (HELO mail-qg0-f45.google.com) (209.85.192.45) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Jun 2014 02:17:31 +0000 Received: by mail-qg0-f45.google.com with SMTP id z60so9772103qgd.18 for ; Sun, 01 Jun 2014 19:17:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=sIZHwWZH39pdLaFx/K74Sasj2AD0Kb3E/X2J4vxS7hM=; b=fW0OjDiHg/d+Dy9n2iqGx7FbSUir60ZDI9M3qgApimzTyWm/8KCzYHb7sVm6+WrIZC 7xwhzZ+9sSxWnfKRpiKqrcjvsVnlXdEX7kBsz6Ay8O032dJicIJ5GuKtQeALtHdzuiJQ D0u56PbwQF7dOdEz2yfoVis5ZNtDFHyYuiFN1r3hAbTyS11Nrv4mdX7kUaXaytUYm3VM ATCrSRzKVY2cxpG83bBlHRwi9eoLF2WBjMBzsOoy+q9r8oMupNxqH/s/2Jwf0LAM9skN HLiQ+WjMiDXLMdI3ERazJqFwC/PSS/AdpfdAikNRRteNxcIDGfX9E69EyUF65XbdbVFZ hViw== X-Gm-Message-State: ALoCoQnVdI8f5Oz8s7AKLoBKFZ0zF2OHsVI59atVfOmd7qyo7ZvIO65Dk/e930UulI5k/j3r1Fnj X-Received: by 10.224.29.211 with SMTP id r19mr18812400qac.47.1401675430826; Sun, 01 Jun 2014 19:17:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.64.72 with HTTP; Sun, 1 Jun 2014 19:16:49 -0700 (PDT) In-Reply-To: References: <24070BEF0A3F684489AA943FD3439EF20AC05871EE@CARRXM06.drn.mil.au> From: Sean Busbey Date: Sun, 1 Jun 2014 21:16:49 -0500 Message-ID: Subject: Re: Droptable hanging [SEC=UNOFFICIAL] To: Accumulo User List Content-Type: multipart/alternative; boundary=047d7bdc85c6252ce504fad0febd X-Virus-Checked: Checked by ClamAV on apache.org --047d7bdc85c6252ce504fad0febd Content-Type: text/plain; charset=UTF-8 Be careful taking the table offline if you have other tables still active. Presuming this table was active (and that's why the unloading tablets it taking awhile) you might run into ACCUMULO-2694. That would keep other tables from balancing while you wait for the delete. https://issues.apache.org/jira/browse/ACCUMULO-2694 Matt, how many tablets are in this table? Are you concerned about the time it takes to delete or just the warning in the shell? FWIW, once you've issued a table delete, you can force exit the shell instance and the delete will continue asynchronously. If you need to recreate the table, doing a rename+delete will let the delete proceed while you create the new table. On Sun, Jun 1, 2014 at 6:40 PM, Josh Elser wrote: > I believe that the master will wait for all of the tablets for that table > to become unassigned before it will delete it. This tends to be the > underlying cause of table ops that want to hang. For example, a bunch of > minor compactions that need to finish would also prevent unloading those > tablets. > > I'm not sure if it would help (or if it would even work :P), but you could > try to offline the table first. > > Hypothetically, you could delete the files and references in the metadata > table, but that would be rather manual. Its possible it would work though. > You may also have to do some cleanup in ZK too. > > But, the underlying question is still: why is the table not getting > deleted? > > Can you share stacktraces from tserver(s) hosting tablets for the table > you're trying to delete (along with the usual version info)? Are there > queued/running compactions for that table? > On Jun 1, 2014 5:56 PM, "Dickson, Matt MR" > wrote: > >> *UNOFFICIAL* >> When dropping a table the shell hangs with "thread 'shell' stuck on IO to >> *ipaddress* (0) for at least ...ms >> >> Is there a way to drop the table other than via the shell? eg can the >> hdfs rfiles all be deleted under /accumulo/tables/*id*/... and then >> remove all references to the table in the !METADATA table. Or are there >> other references to the table that need removing? >> > -- Sean --047d7bdc85c6252ce504fad0febd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Be careful taking the table offline if you have other tabl= es still active. Presuming this table was active (and that's why the un= loading tablets it taking awhile) you might run into ACCUMULO-2694. That wo= uld keep other tables from balancing while you wait for the delete.

<= br>
Matt, how many tablets are in this table?

Are you concerned about the time it takes to delete or just the warnin= g in the shell?

FWIW, once you've issued a tab= le delete, you can force exit the shell instance and the delete will contin= ue asynchronously. If you need to recreate the table, doing a rename+delete= will let the delete proceed while you create the new table.


On Sun,= Jun 1, 2014 at 6:40 PM, Josh Elser <josh.elser@gmail.com> wrote:

I believe that the master wil= l wait for all of the tablets for that table to become unassigned before it= will delete it. This tends to be the underlying cause of table ops that wa= nt to hang. For example, a bunch of minor compactions that need to finish w= ould also prevent unloading those tablets.=C2=A0

I'm not sure if it would help (or if it would even work = :P), but you could try to offline the table first.

Hypothetically, you could delete the files and references in= the metadata table, but that would be rather manual. Its possible it would= work though. You may also have to do some cleanup in ZK too.

But, the underlying question is still: why is the table not = getting deleted?

Can you share stacktraces from tserver(s) hosting tablets fo= r the table you're trying to delete (along with the usual version info)= ? Are there queued/running compactions for that table?

On Jun 1, 2014 5:56 PM, "Dickson, Matt MR&q= uot; <m= att.dickson@defence.gov.au> wrote:

UNOFFICIAL

When dropping a=20 table the shell hangs with "thread 'shell' stuck on IO to = ipaddress (0)=20 for at least ...ms
=C2=A0
Is there a way to=20 drop the table other than via the shell?=C2=A0 eg can the hdfs rfiles all b= e=20 deleted under /accumulo/tables/id/...=C2=A0 and then remove all=20 references to the table in the !METADATA table.=C2=A0 Or are there other=20 references to the table that need removing?



--
=
Sean
--047d7bdc85c6252ce504fad0febd--