[
https://issues.apache.org/jira/browse/ACCUMULO-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13581346#comment-13581346
]
Keith Turner commented on ACCUMULO-1018:
----------------------------------------
bq. However, the (MultiTable)BatchWriter throws a MutationsRejectedException
that has the KeyExtent->ErrorCode pairings (as John pointed out) but I do not
see an effective way map KeyExtent.tableId to a tableName (that the client
would probably prefer) since the MRE doesn't have access to the instance. Any
ideas?
I looked around the code to see where else KeyExtent was used in the public
API. o.a.a.c.client.admin.ActiveScan and ActiveCompaction expose KeyExtent to
the user. Howerver these classes also provide getTable() methods which return
the table name. The implementation of these methods use code that is not part
of the public API.
The javadoc for MRE.getAuthorizationFailures() could point users to
TableOperations.tableIdMap(). However, this map is not readily usable, because
its keyed on table name. So I guess basically we need an easy way for users to
map table ids to table names thats in the public API. If this existed, then
the javadoc for MRE could point to it. Maybe add something to TableOperations
that returns a map keyed on table id? I looked for a built in java util in
Collections that would invert a map and did not see anything. If there was a
simple way to invert the map, then we would not need to add anything to the
public API, just add some javadoc pointing out this inversion util.
Another possibility is adding a convenience method "String
getTableName(Instance i)" to KeyExtent. This addresses the issue at hand, but
I think a more general solution in TableOperations would be better.
> Client does not give informative message when user can not read table
> ---------------------------------------------------------------------
>
> Key: ACCUMULO-1018
> URL: https://issues.apache.org/jira/browse/ACCUMULO-1018
> Project: Accumulo
> Issue Type: Bug
> Components: client
> Affects Versions: 1.4.0
> Reporter: Keith Turner
> Assignee: Billie Rinaldi
> Fix For: 1.6.0
>
>
> Saw this in 1.4, not sure if its an issue in later versions.
> Assume a user has an application that is reading from many tables and does
> not have permission to read from one table. In this case the exception does
> not tell them which table they can not read from. If not familiar with the
> application, it can take a while to track this issue down on a system with
> many tables.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
