accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-2581) Create service in Master to assign replication work
Date Wed, 28 May 2014 05:10:01 GMT

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

ASF subversion and git services commented on ACCUMULO-2581:
-----------------------------------------------------------

Commit 34da6fe9bddbebbc19feb2d12f53edcb743a5733 in accumulo's branch refs/heads/ACCUMULO-378
from [~elserj]
[ https://git-wip-us.apache.org/repos/asf?p=accumulo.git;h=34da6fe ]

ACCUMULO-2581 Revisit the WorkAssigner impls to make some proper OO hierarchy.

The SequentialWorkAssigner is nice, and does what it's meant to, but it's
not nearly as fast as can be done with multiple tservers. It's probably a
good idea to keep a sequential and unordered work assigner in good working order


> Create service in Master to assign replication work
> ---------------------------------------------------
>
>                 Key: ACCUMULO-2581
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-2581
>             Project: Accumulo
>          Issue Type: Sub-task
>          Components: replication
>            Reporter: Josh Elser
>            Assignee: Josh Elser
>
> We likely want the Master to handle the coordination of reading the records of what data
needs to be replicated to the slave(s). We do not have the Master to perform the actual replication,
but to delegate out the tasks to the tservers in the master cluster, and simple track the
progress, success and failure of each "replication act". This will allow for a much more scalable
implementation.
> This service should be able to grow and shrink as replication requests increase/decrease
(but yet retain configurable upper and lower bounds). It likely requires its own Thrift service
to manage the variety of responses that might come from an attempt to replicate data (failure,
success, partial success, etc).
> This service would be the only process that removes replication entries from the persisted
store (table).



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

Mime
View raw message