Answers bellow
On Wed, May 19, 2010 at 8:35 PM, Adam Kocoloski <kocol...@apache.org> wrote:
> Grr, I tried to send this earlier today but just got a delivery failure
> notification. Oh well, here's the re-send
>
> I'm also having those failures frequently :(
> > Nice work Filipe. This has been on the roadmap for a long time. I have
> a couple of questions:
>
Thanks.
> >
> > 1) Does the patch insert the ID of the _local checkpoint doc into the
> _replicator doc? I think that would be pretty useful.
>
No it doesn't. But there's no need actually. See the responses for 2nd and
3rd questions bellow.
> >
> > 2) Multiple identical replications running makes me very uneasy. Does
> the patch also break the behavior of /_replicate in that respect?
>
It doesn't break /_replicate. The replication gen_server will have the ID of
the replication document, and not the one we calculate when using _replicate
(an md5 of an erlang term composed by the replication properties).
About multiple identical replications: yes, it's possible. This happens if 2
rep docs, with same source and target but different IDs, are added to the
replicator DB. This can be prevented by using the checkpoints with IDs based
on the md5 of the rep properties. If I do this, i'll make the replicator add
the _local doc ID to the rep doc (as you ask in #1).
I saw this one coming, but wanted to start with a very simple solution.
> >
> > 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).
> >
> > I'm not sure I fully understand the max_dbs_open concern. If you're
> hitting all_dbs_active errors, that means a) you must have at least
> max_dbs_open concurrent requests for different DBs running, or b) there's a
> bug in the ref counting code. If it's a), that's a sign to increase the
> max_dbs_open limit.
>
There's no bug in the ref counting code.
Actually Randall just explained it in his reply.
Delayed commits for e.g., sets max_open_dbs to 5, then creates 10 DBs and
expects to get {error, all_dbs_active} when creating DB number 6. If the
replicator DB is open, it will get the error when creating DB 5 instead.
Just that.
I felt like cheating if I just changed delayed_commits.js and stats.js. So I
did that _replicator_db branch where I do the infinite lru hack for testing.
> >
> > An infinite LRU timestamp for system DBs seems like a decent thing to do,
> but in this case is it being used to hide a bug? Best,
> >
> > Adam
>
Thanks for the feedback.
I'll be updating the branch in the next few days.
>> Filipe David Manana,
> >> fdman...@gmail.com
> >>
> >> "Reasonable men adapt themselves to the world.
> >> Unreasonable men adapt the world to themselves.
> >> That's why all progress depends on unreasonable men."
> >
>
> >> --
--
Filipe David Manana,
fdman...@gmail.com
"Reasonable men adapt themselves to the world.
Unreasonable men adapt the world to themselves.
That's why all progress depends on unreasonable men."
