accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (ACCUMULO-2974) Unable to assign single tablet table migrated to 1.6.0
Date Fri, 04 Jul 2014 04:34:34 GMT

     [ https://issues.apache.org/jira/browse/ACCUMULO-2974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Josh Elser updated ACCUMULO-2974:
---------------------------------

    Resolution: Fixed
        Status: Resolved  (was: Patch Available)

All unit and integration tests passed with new patch, new unit tests added which ensures proper
paths are sent to VolumeManager and verified by hand that deleterows on a table with relative
paths in 1.6 actually works.

> 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
>
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> 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)

Mime
View raw message