accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-2883) Add API method(s) that support fetching currently assigned locations for tablets
Date Thu, 06 Nov 2014 18:46:33 GMT


Josh Elser commented on ACCUMULO-2883:

[~afuchs], no, that's a good way to approach it. Thanks.

Generally, I was thinking to the larger problem that has been mentioned from time to time
about inadvertent "leakage". One case I was thinking about before was logging of KeyExtents
for things like assignments, compactions, merges, etc. Trying to work through in my head if
there's any practical change that we could make to prevent this. I also just remembered that
users already have the ability to fetch splits for a table :)

It seems like it can be summarized as: if you have access to the Java API, you're going to
be able to extract "information" one way or another. At the same time, there's the common
"phrase" that security is never solved by a single component but the interaction of many moving

> Add API method(s) that support fetching currently assigned locations for tablets
> --------------------------------------------------------------------------------
>                 Key: ACCUMULO-2883
>                 URL:
>             Project: Accumulo
>          Issue Type: Sub-task
>          Components: client
>            Reporter: Josh Elser
>             Fix For: 1.7.0
> TabletLocator already exists, but isn't officially a part of the "public API" and is
clunky for users to invoke. In trying to co-locate external processes with the tabletservers
that are hosting some data, it would be nice to have some means that users can invoke that
will return them these assignments.
> Memory concerns are an issue for tables with many splits (e.g. avoiding creating a Set
of 100k tablet locations for a table), but we also want to provide the ability to ask pointed
questions. Likely building something that accepts a Range (or Collection<Range>) would
be best.

This message was sent by Atlassian JIRA

View raw message