[ 
https://issues.apache.org/jira/browse/ACCUMULO-2974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14052147#comment-14052147
 ] 

Josh Elser edited comment on ACCUMULO-2974 at 7/4/14 4:18 AM:
--------------------------------------------------------------

No worries, [~busbey], I just re-pro'ed it pretty easily. It actually appears 
to be an issue with a delete merge (e.g. deleterows in the shell) on a table 
that has relative paths from 1.5.

Edit: oops, I don't think having splits or not is relevant.


was (Author: elserj):
No worries, [~busbey], I just re-pro'ed it pretty easily. It actually appears 
to be an issue with a delete merge (e.g. deleterows in the shell) on a table 
with no splits that has relative paths from 1.5.

> Unable to assign single tablet table migrated to 1.6.0
> ------------------------------------------------------
>
>                 Key: ACCUMULO-2974
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-2974
>             Project: Accumulo
>          Issue Type: Bug
>          Components: master
>    Affects Versions: 1.6.0
>            Reporter: John Vines
>            Assignee: Josh Elser
>            Priority: Blocker
>             Fix For: 1.6.1, 1.7.0
>
>         Attachments: 
> 0001-ACCUMULO-2974-Include-the-table-id-when-constructing.patch, 
> badMetaScan.png, goodMetaScan.png, stackTrace.png
>
>
> Sorry for the screen caps, no copy/paste from machines.
> Background- several tables migrated from 1.5.1 to 1.6.0. Only one of which 
> was a single tablet. Upon starting, we noticed that that single table was not 
> loading and the master was reporting an unassigned tablet. Had a stack trace 
> in the monitor (attached).
> Also attached is a a metadata scan of the table in question (ID: 12). I was 
> able to get a functional copy of the table by offlining 12 and cloning it. It 
> functioned without issues. Attached is a copy of it's metadata scan as well 
> (ID: 9o)
> The stack trace leads me to it being a specific issue with the contents of 
> srv:dir, and the only difference is the relative vs. absolute file names. 
> This cluster was not changed to multiple namenodes and 
> ../tables/default_tablet does not exist. There are other tables which still 
> use the relative naming scheme, and the system does not seem to be having 
> issues with them.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to