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 <[email protected]> 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" <[email protected]> > 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
