You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@accumulo.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2015/12/08 20:21:11 UTC

[jira] [Commented] (ACCUMULO-2883) Add API method(s) that support fetching currently assigned locations for tablets

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

ASF GitHub Bot commented on ACCUMULO-2883:
------------------------------------------

Github user keith-turner commented on the pull request:

    https://github.com/apache/accumulo/pull/53#issuecomment-162987572
  
    I was able to get geowave working with these changes ( [my branch](https://github.com/keith-turner/geowave/tree/use_locator_api)). Was able to successfully run the geowave test BasicMapReduceIT that @rfecher told me about in the geowave chat room.
    
    I'm happy with this PR and will push soon.


> Add API method(s) that support fetching currently assigned locations for tablets
> --------------------------------------------------------------------------------
>
>                 Key: ACCUMULO-2883
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-2883
>             Project: Accumulo
>          Issue Type: New Feature
>          Components: client
>            Reporter: Josh Elser
>            Assignee: Keith Turner
>             Fix For: 1.8.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
(v6.3.4#6332)