There are occasional reports on IRC about replication tasks that 'hang' or become 'defunct'. That is, the replication tasks are still showing in _active_tasks but updates aren't getting copied over.
This occurs principally when one end is restarted and the other end doesn't notice. If this enhancement aims to manage replication tasks, should it also include checks for zombie replication tasks? On Wed, May 19, 2010 at 10:32 PM, J Chris Anderson <jch...@apache.org> wrote: > > On May 19, 2010, at 2:17 PM, Randall Leeds wrote: > >> On Wed, May 19, 2010 at 13:06, Filipe David Manana <fdman...@gmail.com> >> wrote: >>> Answers bellow >>> >>> On Wed, May 19, 2010 at 8:35 PM, Adam Kocoloski <kocol...@apache.org> wrote: >>>>> >>>>> 3) Is the checkpoint ID generation algorithm backwards-compatible? Or >>>> will users who upgrade restart all replications from scratch? >>>> >>> >>> Well, the checkpoint IDs will be "_local/" + repDocId. So, they are >>> basically user generated. Checkpoints will still remain in the source and >>> target DBs (I don't write them to the _replicator DB). >> >> So if I create a _replicator doc with an ID corresponding to an >> old-style replication ID it'll use the same checkpoints? >> >> I can't remember, is it possible to change the doc_id with an _update >> handler? I haven't looked at your code yet to see what paths it takes, >> but if it's an erlang handler in the .ini I'm sure we could hack this. >> Basically, I'm thinking to make _replicator a lot like the _replicate >> from an API standpoint. Disable PUT but have POST to _replicator >> create the doc with the rep id as we used to calculate it. >> >> In fact, why name it _replicator at all??? We already have a POST to >> _replicate that returns the id. This API looks a lot like the document >> API, we just create a gen_server instead of a document. But if we're >> careful couldn't we transparently turn the _replicate endpoint into >> the _replicator DB under the hood and users don't even have to know >> the difference (unless they need/want to)? >> >> -Randall > > > > [retry after a delivery failure from gmail. maybe something is up with Apache > servers?] > > The main goals as I see them are: > > 1) replications continue even when the server restarts > 2) it is easy to write replication manager couchapps > > I think having the standard database API for these documents (even if it is > admin only) will be a good way to allow people to use the existing toolkit to > query and create replications. > > Of course it'd be nice to be backwards compatible with the existing > replication API. > > Chris
