You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Filipe David Manana <fd...@gmail.com> on 2010/05/19 11:31:04 UTC
_replicator DB
Dear all,
I've been working on the _replicator DB along with Chris. Some of you have
already heard about this DB in the mailing list, IRC, or whatever. Its
purpose:
- replications can be started by adding a replication document to the
replicator DB _replicator (its name can be configured in the .ini files)
- replication documents are basically the same JSON structures that we
currently use when POSTing to _replicate/ (and we can give them an
arbitrary id)
- to cancel a replication, we simply delete the replication document
- after the replication is started, the replicator adds the field "state" to
the replication document with value "triggered"
- when the replication finishes (for non continuous replications), the
replication sets the doc's "state" field to "completed"
- if an error occurs during a replication, the corresponding replication
document will have the "state" field set to "error"
- after detecting that an error was found, the replication is restarted
after some time (10s for now, but maybe it should be configurable)
- after a server restart/crash, CouchDB will remember replications and will
restart them (this is specially useful for continuous replications)
- in the replication document we can define a "user_ctx" property, which
defines the user name and/or role(s) under which the replication will
execute
Some restrictions regarding the _replicator DB:
- only server admins can add and delete replication documents
- only the replicator itself can update replication documents - this is to
avoid having race conditions between the replicator and server admins trying
to update replication documents
- the above point implies that to change a replication you have to add a new
replication document
All this restrictions are in replicator DB design doc -
http://github.com/fdmanana/couchdb/blob/replicator_db/src/couchdb/couch_def_js_funs.hrl<http://github.com/fdmanana/couchdb/blob/_replicator_db/src/couchdb/couch_def_js_funs.hrl>
The code is fully working and is located at:
http://github.com/fdmanana/couchdb/tree/replicator_db
It includes a comprehensive JavaScript test case.
Feel free to try it and give your feedback. There are still some TODOs as
comments in the code, so it's still subject to changes.
For people more involved with CouchDB internals and development:
That branch breaks the stats.js test and, occasionally, the
delayed_commits.js tests.
It breaks stats.js because:
- internally CouchDB uses the _changes API to be aware of the
addition/update/deletion of replication documents to/from the _replicator
DB. The _changes implementation constantly opens and closes the DB (opens
are triggered by a gen_event). This affects the stats open_databases and
open_os_files.
It breaks delayed_commits.js occasionally because:
- by listening to _replicator DB changes an extra file descriptor is used
which affects the max_open_dbs config parameter. This parameter is related
to the max number of user opened DBs. This causes the error {error,
all_dbs_active} (from couch_server.erl) during the execution of
delayed_commits.js (as well as stats.js).
I also have another branch that fixes these issues in a "dirty" way:
http://github.com/fdmanana/couchdb/tree/_replicator_db (has a big comment
in couch_server.erl explaining the hack)
Basically it doesn't increment stats for the _replicator DB and bypasses the
max_open_dbs when opening _replicator DB as well as doesn't allow it to be
closed in favour of a user requested DB (like it assigned it a +infinite LRU
time to this DB).
Sometimes (although very rarely) I also get the all_dbs_active error when
the authentication handlers are executing (because they open the _users DB).
This is not originated by my _replicator DB code at all, since I get it with
trunk as well.
I would also like to collect feedback about what to do regarding this 2
issues, specially max_open_dbs. Somehow I feel that no matter how many user
DBs are open, it should always be possible to open the _replicator DB
internally (and the _users DB).
cheers
--
Filipe David Manana,
fdmanana@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."
Re: _replicator DB
Posted by Filipe David Manana <fd...@gmail.com>.
On Wed, May 19, 2010 at 10:47 AM, Sebastian Cohnen <
sebastiancohnen@googlemail.com> wrote:
> This sounds very awesome to me!
>
>
Thanks Sesbastian.
> One question though: You just need to add a document to the _replicator DB
> and don't have to "wait" for long-running replications to finish?
>
No, the replication will start immediately (as soon as _changes knows that
the document was added). Two identical replications may take place if you
use the same source and target in 2 different replication documents (docs
with different IDs).
--
>
Filipe David Manana,
fdmanana@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."
Re: _replicator DB
Posted by Sebastian Cohnen <se...@googlemail.com>.
This sounds very awesome to me!
One question though: You just need to add a document to the _replicator DB and don't have to "wait" for long-running replications to finish?
On 19.05.2010, at 11:31, Filipe David Manana wrote:
> Dear all,
>
> I've been working on the _replicator DB along with Chris. Some of you have
> already heard about this DB in the mailing list, IRC, or whatever. Its
> purpose:
>
> - replications can be started by adding a replication document to the
> replicator DB _replicator (its name can be configured in the .ini files)
>
> - replication documents are basically the same JSON structures that we
> currently use when POSTing to _replicate/ (and we can give them an
> arbitrary id)
>
> - to cancel a replication, we simply delete the replication document
>
> - after the replication is started, the replicator adds the field "state" to
> the replication document with value "triggered"
>
> - when the replication finishes (for non continuous replications), the
> replication sets the doc's "state" field to "completed"
>
> - if an error occurs during a replication, the corresponding replication
> document will have the "state" field set to "error"
>
> - after detecting that an error was found, the replication is restarted
> after some time (10s for now, but maybe it should be configurable)
>
> - after a server restart/crash, CouchDB will remember replications and will
> restart them (this is specially useful for continuous replications)
>
> - in the replication document we can define a "user_ctx" property, which
> defines the user name and/or role(s) under which the replication will
> execute
>
>
>
> Some restrictions regarding the _replicator DB:
>
> - only server admins can add and delete replication documents
>
> - only the replicator itself can update replication documents - this is to
> avoid having race conditions between the replicator and server admins trying
> to update replication documents
>
> - the above point implies that to change a replication you have to add a new
> replication document
>
> All this restrictions are in replicator DB design doc -
> http://github.com/fdmanana/couchdb/blob/replicator_db/src/couchdb/couch_def_js_funs.hrl<http://github.com/fdmanana/couchdb/blob/_replicator_db/src/couchdb/couch_def_js_funs.hrl>
>
>
> The code is fully working and is located at:
> http://github.com/fdmanana/couchdb/tree/replicator_db
>
> It includes a comprehensive JavaScript test case.
>
> Feel free to try it and give your feedback. There are still some TODOs as
> comments in the code, so it's still subject to changes.
>
>
> For people more involved with CouchDB internals and development:
>
> That branch breaks the stats.js test and, occasionally, the
> delayed_commits.js tests.
>
> It breaks stats.js because:
>
> - internally CouchDB uses the _changes API to be aware of the
> addition/update/deletion of replication documents to/from the _replicator
> DB. The _changes implementation constantly opens and closes the DB (opens
> are triggered by a gen_event). This affects the stats open_databases and
> open_os_files.
>
> It breaks delayed_commits.js occasionally because:
>
> - by listening to _replicator DB changes an extra file descriptor is used
> which affects the max_open_dbs config parameter. This parameter is related
> to the max number of user opened DBs. This causes the error {error,
> all_dbs_active} (from couch_server.erl) during the execution of
> delayed_commits.js (as well as stats.js).
>
> I also have another branch that fixes these issues in a "dirty" way:
> http://github.com/fdmanana/couchdb/tree/_replicator_db (has a big comment
> in couch_server.erl explaining the hack)
>
> Basically it doesn't increment stats for the _replicator DB and bypasses the
> max_open_dbs when opening _replicator DB as well as doesn't allow it to be
> closed in favour of a user requested DB (like it assigned it a +infinite LRU
> time to this DB).
>
> Sometimes (although very rarely) I also get the all_dbs_active error when
> the authentication handlers are executing (because they open the _users DB).
> This is not originated by my _replicator DB code at all, since I get it with
> trunk as well.
>
> I would also like to collect feedback about what to do regarding this 2
> issues, specially max_open_dbs. Somehow I feel that no matter how many user
> DBs are open, it should always be possible to open the _replicator DB
> internally (and the _users DB).
>
>
> cheers
>
>
> --
> Filipe David Manana,
> fdmanana@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."
Re: _replicator DB
Posted by Filipe David Manana <fd...@gmail.com>.
On Fri, May 28, 2010 at 1:26 AM, J Chris Anderson <jc...@gmail.com> wrote:
>
>
> hmm, 3rd time I've tried to send this...
>
I also get most of my @dev mails dropped. There's clearly an irritating
issue with the mail server.
>
> I've been working on the test cases for the replicator db, to remove wait()
> from the test. I think this will make them more robust as well.
>
I do agree. The test suite takes about 40 ~ 50 seconds in my machines.
>
> Instead of waiting, I wrote functions to check a replication doc for state
> == "complete" or another, to wait for the update_seq of two databases to
> match.
>
> There are a couple of places where I had to leave wait() in. These are in
> spots with assertions that a particular replication *did stop* when a
> document is deleted. So you have to wait and then see if the docs are there
> or not. I can't think of way to test for this, otherwise. (Unless maybe
> active_tasks is accurate enough to use in these assertions.)
>
Particularly, I have to do a wait() (of at least 500ms) after the server is
restarted in my machine.
Yeah, testing that a replication was stopped through deletion of the
corresponding replication document is just that: delete document, wait a
bit, add new document to source, and finally verify that the document was
not replicated to the target DB.
> I plan to dig into the meat of the patch soon but wanted to start with the
> tests.
>
> The commit is here:
>
> http://github.com/jchris/couchdb/tree/fdm/nrd
>
> Thanks for all the hard work, Filipe, and everyone who's giving feedback.
Thanks for looking into this and the improvement of the test suite.
>
> Chris
>
>
Re: _replicator DB
Posted by J Chris Anderson <jc...@gmail.com>.
On May 25, 2010, at 2:50 AM, Filipe David Manana wrote:
> Hi all,
>
> I've reworked on some implementation details. Namely, the replication
> gen_servers now have an ID that is no longer based on the replication
> document ID but instead in the md5 of the replication properties (source,
> target, etc, like it is done currently when we post to _replicate). This
> avoids having identical replications going on at the expense of a bit more
> complex code.
>
> From the user point of view, everything is pretty much the same as I
> announced before. The only few differences are:
>
> - when a replication is started by adding a replication document to the
> _replicator DB, the replicator besides adding the field "state" with value
> "triggered" to the replication document, also adds the field
> "replication_id". (with this field's value, we can access the replication
> log/checkpoint documents, as Adam suggested before).
>
> - if the user adds a second document that in fact describes a replication
> already triggered by a previous document (same source, target, etc), this
> second document will not get a "state" field added to it. However the
> replicator adds the "replication_id" field to it. This is nice IMO, since we
> can add a view whose keys are the "replication_id" values
> and see which replication documents are duplicates.
>
> - deleting a duplicated replication document (a document that didn't
> triggered a replication, since a former one already triggered that
> replication) doesn't stop the replication. To stop it, we have to delete the
> document that triggered the replication - we can find it by searching for a
> document with the same "replication_id" and "state" set to "triggered".
>
> For more details, check the JavaScript test suite:
> http://github.com/fdmanana/couchdb/blob/new_replicator_db/share/www/script/test/replicator_db.js
> It's maybe easier to understand _replicator DB by looking at the tests. It's
> very simple from a user's point of view.
>
> The whole patch can be found in a new branch at:
> http://github.com/fdmanana/couchdb/compare/new_replicator_db
>
hmm, 3rd time I've tried to send this...
I've been working on the test cases for the replicator db, to remove wait() from the test. I think this will make them more robust as well.
Instead of waiting, I wrote functions to check a replication doc for state == "complete" or another, to wait for the update_seq of two databases to match.
There are a couple of places where I had to leave wait() in. These are in spots with assertions that a particular replication *did stop* when a document is deleted. So you have to wait and then see if the docs are there or not. I can't think of way to test for this, otherwise. (Unless maybe active_tasks is accurate enough to use in these assertions.)
I plan to dig into the meat of the patch soon but wanted to start with the tests.
The commit is here:
http://github.com/jchris/couchdb/tree/fdm/nrd
Thanks for all the hard work, Filipe, and everyone who's giving feedback.
Chris
> Later on I'll add a patch to a Jira ticket.
>
> cheers
>
>
>
> On Wed, May 19, 2010 at 10:31 AM, Filipe David Manana <fd...@gmail.com>wrote:
>
>> Dear all,
>>
>> I've been working on the _replicator DB along with Chris. Some of you have
>> already heard about this DB in the mailing list, IRC, or whatever. Its
>> purpose:
>>
>> - replications can be started by adding a replication document to the
>> replicator DB _replicator (its name can be configured in the .ini files)
>>
>> - replication documents are basically the same JSON structures that we
>> currently use when POSTing to _replicate/ (and we can give them an
>> arbitrary id)
>>
>> - to cancel a replication, we simply delete the replication document
>>
>> - after the replication is started, the replicator adds the field "state"
>> to the replication document with value "triggered"
>>
>> - when the replication finishes (for non continuous replications), the
>> replication sets the doc's "state" field to "completed"
>>
>> - if an error occurs during a replication, the corresponding replication
>> document will have the "state" field set to "error"
>>
>> - after detecting that an error was found, the replication is restarted
>> after some time (10s for now, but maybe it should be configurable)
>>
>> - after a server restart/crash, CouchDB will remember replications and will
>> restart them (this is specially useful for continuous replications)
>>
>> - in the replication document we can define a "user_ctx" property, which
>> defines the user name and/or role(s) under which the replication will
>> execute
>>
>>
>>
>> Some restrictions regarding the _replicator DB:
>>
>> - only server admins can add and delete replication documents
>>
>> - only the replicator itself can update replication documents - this is to
>> avoid having race conditions between the replicator and server admins trying
>> to update replication documents
>>
>> - the above point implies that to change a replication you have to add a
>> new replication document
>>
>> All this restrictions are in replicator DB design doc -
>> http://github.com/fdmanana/couchdb/blob/replicator_db/src/couchdb/couch_def_js_funs.hrl<http://github.com/fdmanana/couchdb/blob/_replicator_db/src/couchdb/couch_def_js_funs.hrl>
>>
>>
>> The code is fully working and is located at:
>> http://github.com/fdmanana/couchdb/tree/replicator_db
>>
>> It includes a comprehensive JavaScript test case.
>>
>> Feel free to try it and give your feedback. There are still some TODOs as
>> comments in the code, so it's still subject to changes.
>>
>>
>> For people more involved with CouchDB internals and development:
>>
>> That branch breaks the stats.js test and, occasionally, the
>> delayed_commits.js tests.
>>
>> It breaks stats.js because:
>>
>> - internally CouchDB uses the _changes API to be aware of the
>> addition/update/deletion of replication documents to/from the _replicator
>> DB. The _changes implementation constantly opens and closes the DB (opens
>> are triggered by a gen_event). This affects the stats open_databases and
>> open_os_files.
>>
>> It breaks delayed_commits.js occasionally because:
>>
>> - by listening to _replicator DB changes an extra file descriptor is used
>> which affects the max_open_dbs config parameter. This parameter is related
>> to the max number of user opened DBs. This causes the error {error,
>> all_dbs_active} (from couch_server.erl) during the execution of
>> delayed_commits.js (as well as stats.js).
>>
>> I also have another branch that fixes these issues in a "dirty" way:
>> http://github.com/fdmanana/couchdb/tree/_replicator_db (has a big comment
>> in couch_server.erl explaining the hack)
>>
>> Basically it doesn't increment stats for the _replicator DB and bypasses
>> the max_open_dbs when opening _replicator DB as well as doesn't allow it to
>> be closed in favour of a user requested DB (like it assigned it a +infinite
>> LRU time to this DB).
>>
>> Sometimes (although very rarely) I also get the all_dbs_active error when
>> the authentication handlers are executing (because they open the _users DB).
>> This is not originated by my _replicator DB code at all, since I get it with
>> trunk as well.
>>
>> I would also like to collect feedback about what to do regarding this 2
>> issues, specially max_open_dbs. Somehow I feel that no matter how many user
>> DBs are open, it should always be possible to open the _replicator DB
>> internally (and the _users DB).
>>
>>
>> cheers
>>
>>
>> --
>> Filipe David Manana,
>> fdmanana@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,
> fdmanana@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."
Re: _replicator DB
Posted by Filipe David Manana <fd...@gmail.com>.
Hi all,
I've reworked on some implementation details. Namely, the replication
gen_servers now have an ID that is no longer based on the replication
document ID but instead in the md5 of the replication properties (source,
target, etc, like it is done currently when we post to _replicate). This
avoids having identical replications going on at the expense of a bit more
complex code.
>From the user point of view, everything is pretty much the same as I
announced before. The only few differences are:
- when a replication is started by adding a replication document to the
_replicator DB, the replicator besides adding the field "state" with value
"triggered" to the replication document, also adds the field
"replication_id". (with this field's value, we can access the replication
log/checkpoint documents, as Adam suggested before).
- if the user adds a second document that in fact describes a replication
already triggered by a previous document (same source, target, etc), this
second document will not get a "state" field added to it. However the
replicator adds the "replication_id" field to it. This is nice IMO, since we
can add a view whose keys are the "replication_id" values
and see which replication documents are duplicates.
- deleting a duplicated replication document (a document that didn't
triggered a replication, since a former one already triggered that
replication) doesn't stop the replication. To stop it, we have to delete the
document that triggered the replication - we can find it by searching for a
document with the same "replication_id" and "state" set to "triggered".
For more details, check the JavaScript test suite:
http://github.com/fdmanana/couchdb/blob/new_replicator_db/share/www/script/test/replicator_db.js
It's maybe easier to understand _replicator DB by looking at the tests. It's
very simple from a user's point of view.
The whole patch can be found in a new branch at:
http://github.com/fdmanana/couchdb/compare/new_replicator_db
Later on I'll add a patch to a Jira ticket.
cheers
On Wed, May 19, 2010 at 10:31 AM, Filipe David Manana <fd...@gmail.com>wrote:
> Dear all,
>
> I've been working on the _replicator DB along with Chris. Some of you have
> already heard about this DB in the mailing list, IRC, or whatever. Its
> purpose:
>
> - replications can be started by adding a replication document to the
> replicator DB _replicator (its name can be configured in the .ini files)
>
> - replication documents are basically the same JSON structures that we
> currently use when POSTing to _replicate/ (and we can give them an
> arbitrary id)
>
> - to cancel a replication, we simply delete the replication document
>
> - after the replication is started, the replicator adds the field "state"
> to the replication document with value "triggered"
>
> - when the replication finishes (for non continuous replications), the
> replication sets the doc's "state" field to "completed"
>
> - if an error occurs during a replication, the corresponding replication
> document will have the "state" field set to "error"
>
> - after detecting that an error was found, the replication is restarted
> after some time (10s for now, but maybe it should be configurable)
>
> - after a server restart/crash, CouchDB will remember replications and will
> restart them (this is specially useful for continuous replications)
>
> - in the replication document we can define a "user_ctx" property, which
> defines the user name and/or role(s) under which the replication will
> execute
>
>
>
> Some restrictions regarding the _replicator DB:
>
> - only server admins can add and delete replication documents
>
> - only the replicator itself can update replication documents - this is to
> avoid having race conditions between the replicator and server admins trying
> to update replication documents
>
> - the above point implies that to change a replication you have to add a
> new replication document
>
> All this restrictions are in replicator DB design doc -
> http://github.com/fdmanana/couchdb/blob/replicator_db/src/couchdb/couch_def_js_funs.hrl<http://github.com/fdmanana/couchdb/blob/_replicator_db/src/couchdb/couch_def_js_funs.hrl>
>
>
> The code is fully working and is located at:
> http://github.com/fdmanana/couchdb/tree/replicator_db
>
> It includes a comprehensive JavaScript test case.
>
> Feel free to try it and give your feedback. There are still some TODOs as
> comments in the code, so it's still subject to changes.
>
>
> For people more involved with CouchDB internals and development:
>
> That branch breaks the stats.js test and, occasionally, the
> delayed_commits.js tests.
>
> It breaks stats.js because:
>
> - internally CouchDB uses the _changes API to be aware of the
> addition/update/deletion of replication documents to/from the _replicator
> DB. The _changes implementation constantly opens and closes the DB (opens
> are triggered by a gen_event). This affects the stats open_databases and
> open_os_files.
>
> It breaks delayed_commits.js occasionally because:
>
> - by listening to _replicator DB changes an extra file descriptor is used
> which affects the max_open_dbs config parameter. This parameter is related
> to the max number of user opened DBs. This causes the error {error,
> all_dbs_active} (from couch_server.erl) during the execution of
> delayed_commits.js (as well as stats.js).
>
> I also have another branch that fixes these issues in a "dirty" way:
> http://github.com/fdmanana/couchdb/tree/_replicator_db (has a big comment
> in couch_server.erl explaining the hack)
>
> Basically it doesn't increment stats for the _replicator DB and bypasses
> the max_open_dbs when opening _replicator DB as well as doesn't allow it to
> be closed in favour of a user requested DB (like it assigned it a +infinite
> LRU time to this DB).
>
> Sometimes (although very rarely) I also get the all_dbs_active error when
> the authentication handlers are executing (because they open the _users DB).
> This is not originated by my _replicator DB code at all, since I get it with
> trunk as well.
>
> I would also like to collect feedback about what to do regarding this 2
> issues, specially max_open_dbs. Somehow I feel that no matter how many user
> DBs are open, it should always be possible to open the _replicator DB
> internally (and the _users DB).
>
>
> cheers
>
>
> --
> Filipe David Manana,
> fdmanana@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,
fdmanana@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."
Re: _replicator DB
Posted by Randall Leeds <ra...@gmail.com>.
On Wed, May 19, 2010 at 12:35, Adam Kocoloski <ko...@apache.org> wrote:
>> 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.
The way I read it there was no problem with max_dbs_open, just that
the tests which are designed to trigger all_dbs_active and exercise
code around these parts need to be adjusted to accommodate the extra
references and extra active db used for internals. That or the hack
that keeps _replications out of these counts.
-Randall
Re: _replicator DB
Posted by Filipe David Manana <fd...@gmail.com>.
On Wed, May 19, 2010 at 10:17 PM, Randall Leeds <ra...@gmail.com>wrote:
> On Wed, May 19, 2010 at 13:06, Filipe David Manana <fd...@gmail.com>
> wrote:
> > Answers bellow
> >
> > On Wed, May 19, 2010 at 8:35 PM, Adam Kocoloski <ko...@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?
>
Yes.
>
> 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.
>
That's a good observation.
I thought about changing the ID of replication docs with an _update handler,
to make sure they would be the same as the current replication IDs (the md5
of a term_to_binary of a term containing the replication properties). Doing
that in a JavaScript _update handler is not possible, because of the
term_to_binary call and the need of an md5 function.
Also, for allowing users and couchapps to manage replications, it's more
"relaxing" to allow them to choose whatever ID they want to identify a
replication -> I think this is a plus.
Yes, a replication document is basically a JSON object that we currently
POST to _replicate. Only with an "_id" field and a "state" field, everything
else is the same.
>
> 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)?
>
Initially I had code that created a replication document in _replicator DB
when POSTing to _replicate. It turned out to add many ugly logic to
couch_rep.
Is that what you had in your mind?
>
> -Randall
>
--
Filipe David Manana,
fdmanana@gmail.com
Re: _replicator DB
Posted by Robert Newson <ro...@gmail.com>.
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 <jc...@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 <fd...@gmail.com> wrote:
>>> Answers bellow
>>>
>>> On Wed, May 19, 2010 at 8:35 PM, Adam Kocoloski <ko...@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
Re: _replicator DB
Posted by Randall Leeds <ra...@gmail.com>.
On Wed, May 19, 2010 at 14:32, J Chris Anderson <jc...@apache.org> wrote:
>
> 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.
What I was trying to communicate is that the existing replication API
*is* the document API restricted to POST. Add GET and some validations
that don't let you change fields that would alter the replication ID
and BOOM!
Then, detach the replication supervisor and gen_servers from the httpd
api and have them hook straight into changes internally.
Do I make any sense?
Re: _replicator DB
Posted by J Chris Anderson <jc...@apache.org>.
On May 19, 2010, at 2:17 PM, Randall Leeds wrote:
> On Wed, May 19, 2010 at 13:06, Filipe David Manana <fd...@gmail.com> wrote:
>> Answers bellow
>>
>> On Wed, May 19, 2010 at 8:35 PM, Adam Kocoloski <ko...@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
Re: _replicator DB
Posted by Randall Leeds <ra...@gmail.com>.
On Wed, May 19, 2010 at 13:06, Filipe David Manana <fd...@gmail.com> wrote:
> Answers bellow
>
> On Wed, May 19, 2010 at 8:35 PM, Adam Kocoloski <ko...@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
Re: _replicator DB
Posted by Filipe David Manana <fd...@gmail.com>.
Answers bellow
On Wed, May 19, 2010 at 8:35 PM, Adam Kocoloski <ko...@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,
> >> fdmanana@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,
fdmanana@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."
Re: _replicator DB
Posted by Filipe David Manana <fd...@gmail.com>.
On Thu, May 20, 2010 at 4:17 PM, Filipe David Manana <fd...@gmail.com>wrote:
> One question Adam:
>
> On Wed, May 19, 2010 at 8:35 PM, Adam Kocoloski <ko...@apache.org>wrote:
>
>>
>> > 3) Is the checkpoint ID generation algorithm backwards-compatible? Or
>> will users who upgrade restart all replications from scratch?
>> >
>>
>
> To make it backward compatible, it means that independenly of replication
> document IDs, the _local documents would be the the same as before - that
> md5 of term_to_binary over a term composed of replication properties
> (source, target, continuous, etc).
>
> This way 2 replications document that differ only on their ID, would share
> the same replication log _local docs. If both are updating them, we have
> racing conditions, so one of the replication gen_servers will fail.
>
Forget this comment. The replicator is catching doc update conflict
exceptions therefore replicator gen_servers do not crash upon an update
conflict.
I think for now it can be safely ignored.
If this turns out to be bad, I'll revert to a former solution I had - using
the md5 based replication IDs as the gen_server IDs (however it was causing
some issues and needed a bit more code).
cheers
>
> --
> Filipe David Manana,
> fdmanana@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,
fdmanana@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."
Re: _replicator DB
Posted by Filipe David Manana <fd...@gmail.com>.
One question Adam:
On Wed, May 19, 2010 at 8:35 PM, Adam Kocoloski <ko...@apache.org> wrote:
>
> > 3) Is the checkpoint ID generation algorithm backwards-compatible? Or
> will users who upgrade restart all replications from scratch?
> >
>
To make it backward compatible, it means that independenly of replication
document IDs, the _local documents would be the the same as before - that
md5 of term_to_binary over a term composed of replication properties
(source, target, continuous, etc).
This way 2 replications document that differ only on their ID, would share
the same replication log _local docs. If both are updating them, we have
racing conditions, so one of the replication gen_servers will fail.
Remembering now this was the main reason I opted to assign IDs like
"_local/repDocId" to the replication logs, breaking backward compatibility.
Some suggestion?
cheers
--
Filipe David Manana,
fdmanana@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."
Re: _replicator DB
Posted by Adam Kocoloski <ko...@apache.org>.
Grr, I tried to send this earlier today but just got a delivery failure notification. Oh well, here's the re-send
> Nice work Filipe. This has been on the roadmap for a long time. I have a couple of questions:
>
> 1) Does the patch insert the ID of the _local checkpoint doc into the _replicator doc? I think that would be pretty useful.
>
> 2) Multiple identical replications running makes me very uneasy. Does the patch also break the behavior of /_replicate in that respect?
>
> 3) Is the checkpoint ID generation algorithm backwards-compatible? Or will users who upgrade restart all replications from scratch?
>
> 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.
>
> 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
On May 19, 2010, at 10:35 AM, Jan Lehnardt wrote:
> Hi all,
>
> Filipe, great work!
>
> I think separate DBs make sense, but with a different angle.
>
> Say I want to replicate all users to a new instance. I don't want to
> write a replication filter for that.
>
> Replicating replication tasks sounds like a nice meta-CouchDB-
> programming thing I want to explore. People could benchmark
> their clusters by how many levels of replication it can take (think
> recursion :)
>
> I see more "tasks" coming up in the future, say continuous compaction,
> or compaction when certain events happen. For this, a single DB _tasks
> would make sense to keep replication, compaction and whatever other
> tasks we can come up with.
>
> Users are not tasks, so they should be separate. Also, the _users db is
> special cased in our auth-system, I'd rather not intermingle it with items
> that don't need as high security (not saying you shouldn't be able to
> hide tasks, but it is a different thing).
>
> Cheers
> Jan
> --
>
>
> On 19 May 2010, at 16:16, Filipe David Manana wrote:
>
>> I also tend to prefer having two separate DBs. For now, there are 2 specific
>> resources (users and replications) but tomorrow we can have 3, 4, 5, etc.
>>
>> However, a single _system DB would help with the max_open_dbs and _stats :)
>>
>>
>>
>> On Wed, May 19, 2010 at 2:32 PM, Simon Metson <si...@googlemail.com>wrote:
>>
>>> +1
>>>
>>>
>>> On 19 May 2010, at 12:59, Sebastian Cohnen wrote:
>>>
>>> having dedicated endpoints for specific resources sounds more reasonable
>>>> to me, than having a single endpoint for misc stuff. just my 2ct
>>>>
>>>>
>>>> On 19.05.2010, at 13:39, Dirkjan Ochtman wrote:
>>>>
>>>> On Wed, May 19, 2010 at 13:13, Robert Dionne
>>>>> <di...@dionne-associates.com> wrote:
>>>>>
>>>>>> This sounds like a good approach, if I get the gist of it, it makes the
>>>>>> replication state persistent. We also have a _users db now, is this a good
>>>>>> time to think about consolidating and having one _system database ?
>>>>>>
>>>>>
>>>>> I too like the proposal, but I'd also prefer a single _system db
>>>>> rather than a bunch of specific databases.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Dirkjan
>>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Filipe David Manana,
>> fdmanana@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."
>
Re: _replicator DB
Posted by Jan Lehnardt <ja...@apache.org>.
Hi all,
Filipe, great work!
I think separate DBs make sense, but with a different angle.
Say I want to replicate all users to a new instance. I don't want to
write a replication filter for that.
Replicating replication tasks sounds like a nice meta-CouchDB-
programming thing I want to explore. People could benchmark
their clusters by how many levels of replication it can take (think
recursion :)
I see more "tasks" coming up in the future, say continuous compaction,
or compaction when certain events happen. For this, a single DB _tasks
would make sense to keep replication, compaction and whatever other
tasks we can come up with.
Users are not tasks, so they should be separate. Also, the _users db is
special cased in our auth-system, I'd rather not intermingle it with items
that don't need as high security (not saying you shouldn't be able to
hide tasks, but it is a different thing).
Cheers
Jan
--
On 19 May 2010, at 16:16, Filipe David Manana wrote:
> I also tend to prefer having two separate DBs. For now, there are 2 specific
> resources (users and replications) but tomorrow we can have 3, 4, 5, etc.
>
> However, a single _system DB would help with the max_open_dbs and _stats :)
>
>
>
> On Wed, May 19, 2010 at 2:32 PM, Simon Metson <si...@googlemail.com>wrote:
>
>> +1
>>
>>
>> On 19 May 2010, at 12:59, Sebastian Cohnen wrote:
>>
>> having dedicated endpoints for specific resources sounds more reasonable
>>> to me, than having a single endpoint for misc stuff. just my 2ct
>>>
>>>
>>> On 19.05.2010, at 13:39, Dirkjan Ochtman wrote:
>>>
>>> On Wed, May 19, 2010 at 13:13, Robert Dionne
>>>> <di...@dionne-associates.com> wrote:
>>>>
>>>>> This sounds like a good approach, if I get the gist of it, it makes the
>>>>> replication state persistent. We also have a _users db now, is this a good
>>>>> time to think about consolidating and having one _system database ?
>>>>>
>>>>
>>>> I too like the proposal, but I'd also prefer a single _system db
>>>> rather than a bunch of specific databases.
>>>>
>>>> Cheers,
>>>>
>>>> Dirkjan
>>>>
>>>
>>>
>>
>
>
> --
> Filipe David Manana,
> fdmanana@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."
Re: _replicator DB
Posted by Filipe David Manana <fd...@gmail.com>.
I also tend to prefer having two separate DBs. For now, there are 2 specific
resources (users and replications) but tomorrow we can have 3, 4, 5, etc.
However, a single _system DB would help with the max_open_dbs and _stats :)
On Wed, May 19, 2010 at 2:32 PM, Simon Metson <si...@googlemail.com>wrote:
> +1
>
>
> On 19 May 2010, at 12:59, Sebastian Cohnen wrote:
>
> having dedicated endpoints for specific resources sounds more reasonable
>> to me, than having a single endpoint for misc stuff. just my 2ct
>>
>>
>> On 19.05.2010, at 13:39, Dirkjan Ochtman wrote:
>>
>> On Wed, May 19, 2010 at 13:13, Robert Dionne
>>> <di...@dionne-associates.com> wrote:
>>>
>>>> This sounds like a good approach, if I get the gist of it, it makes the
>>>> replication state persistent. We also have a _users db now, is this a good
>>>> time to think about consolidating and having one _system database ?
>>>>
>>>
>>> I too like the proposal, but I'd also prefer a single _system db
>>> rather than a bunch of specific databases.
>>>
>>> Cheers,
>>>
>>> Dirkjan
>>>
>>
>>
>
--
Filipe David Manana,
fdmanana@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."
Re: _replicator DB
Posted by Simon Metson <si...@googlemail.com>.
+1
On 19 May 2010, at 12:59, Sebastian Cohnen wrote:
> having dedicated endpoints for specific resources sounds more
> reasonable to me, than having a single endpoint for misc stuff. just
> my 2ct
>
>
> On 19.05.2010, at 13:39, Dirkjan Ochtman wrote:
>
>> On Wed, May 19, 2010 at 13:13, Robert Dionne
>> <di...@dionne-associates.com> wrote:
>>> This sounds like a good approach, if I get the gist of it, it
>>> makes the replication state persistent. We also have a _users db
>>> now, is this a good time to think about consolidating and having
>>> one _system database ?
>>
>> I too like the proposal, but I'd also prefer a single _system db
>> rather than a bunch of specific databases.
>>
>> Cheers,
>>
>> Dirkjan
>
Re: _replicator DB
Posted by Sebastian Cohnen <se...@googlemail.com>.
having dedicated endpoints for specific resources sounds more reasonable to me, than having a single endpoint for misc stuff. just my 2ct
On 19.05.2010, at 13:39, Dirkjan Ochtman wrote:
> On Wed, May 19, 2010 at 13:13, Robert Dionne
> <di...@dionne-associates.com> wrote:
>> This sounds like a good approach, if I get the gist of it, it makes the replication state persistent. We also have a _users db now, is this a good time to think about consolidating and having one _system database ?
>
> I too like the proposal, but I'd also prefer a single _system db
> rather than a bunch of specific databases.
>
> Cheers,
>
> Dirkjan
Re: _replicator DB
Posted by Dirkjan Ochtman <di...@ochtman.nl>.
On Wed, May 19, 2010 at 13:13, Robert Dionne
<di...@dionne-associates.com> wrote:
> This sounds like a good approach, if I get the gist of it, it makes the replication state persistent. We also have a _users db now, is this a good time to think about consolidating and having one _system database ?
I too like the proposal, but I'd also prefer a single _system db
rather than a bunch of specific databases.
Cheers,
Dirkjan
Re: _replicator DB
Posted by Robert Dionne <di...@dionne-associates.com>.
This sounds like a good approach, if I get the gist of it, it makes the replication state persistent. We also have a _users db now, is this a good time to think about consolidating and having one _system database ?
Good stuff,
Bob
On May 19, 2010, at 5:31 AM, Filipe David Manana wrote:
> Dear all,
>
> I've been working on the _replicator DB along with Chris. Some of you have
> already heard about this DB in the mailing list, IRC, or whatever. Its
> purpose:
>
> - replications can be started by adding a replication document to the
> replicator DB _replicator (its name can be configured in the .ini files)
>
> - replication documents are basically the same JSON structures that we
> currently use when POSTing to _replicate/ (and we can give them an
> arbitrary id)
>
> - to cancel a replication, we simply delete the replication document
>
> - after the replication is started, the replicator adds the field "state" to
> the replication document with value "triggered"
>
> - when the replication finishes (for non continuous replications), the
> replication sets the doc's "state" field to "completed"
>
> - if an error occurs during a replication, the corresponding replication
> document will have the "state" field set to "error"
>
> - after detecting that an error was found, the replication is restarted
> after some time (10s for now, but maybe it should be configurable)
>
> - after a server restart/crash, CouchDB will remember replications and will
> restart them (this is specially useful for continuous replications)
>
> - in the replication document we can define a "user_ctx" property, which
> defines the user name and/or role(s) under which the replication will
> execute
>
>
>
> Some restrictions regarding the _replicator DB:
>
> - only server admins can add and delete replication documents
>
> - only the replicator itself can update replication documents - this is to
> avoid having race conditions between the replicator and server admins trying
> to update replication documents
>
> - the above point implies that to change a replication you have to add a new
> replication document
>
> All this restrictions are in replicator DB design doc -
> http://github.com/fdmanana/couchdb/blob/replicator_db/src/couchdb/couch_def_js_funs.hrl<http://github.com/fdmanana/couchdb/blob/_replicator_db/src/couchdb/couch_def_js_funs.hrl>
>
>
> The code is fully working and is located at:
> http://github.com/fdmanana/couchdb/tree/replicator_db
>
> It includes a comprehensive JavaScript test case.
>
> Feel free to try it and give your feedback. There are still some TODOs as
> comments in the code, so it's still subject to changes.
>
>
> For people more involved with CouchDB internals and development:
>
> That branch breaks the stats.js test and, occasionally, the
> delayed_commits.js tests.
>
> It breaks stats.js because:
>
> - internally CouchDB uses the _changes API to be aware of the
> addition/update/deletion of replication documents to/from the _replicator
> DB. The _changes implementation constantly opens and closes the DB (opens
> are triggered by a gen_event). This affects the stats open_databases and
> open_os_files.
>
> It breaks delayed_commits.js occasionally because:
>
> - by listening to _replicator DB changes an extra file descriptor is used
> which affects the max_open_dbs config parameter. This parameter is related
> to the max number of user opened DBs. This causes the error {error,
> all_dbs_active} (from couch_server.erl) during the execution of
> delayed_commits.js (as well as stats.js).
>
> I also have another branch that fixes these issues in a "dirty" way:
> http://github.com/fdmanana/couchdb/tree/_replicator_db (has a big comment
> in couch_server.erl explaining the hack)
>
> Basically it doesn't increment stats for the _replicator DB and bypasses the
> max_open_dbs when opening _replicator DB as well as doesn't allow it to be
> closed in favour of a user requested DB (like it assigned it a +infinite LRU
> time to this DB).
>
> Sometimes (although very rarely) I also get the all_dbs_active error when
> the authentication handlers are executing (because they open the _users DB).
> This is not originated by my _replicator DB code at all, since I get it with
> trunk as well.
>
> I would also like to collect feedback about what to do regarding this 2
> issues, specially max_open_dbs. Somehow I feel that no matter how many user
> DBs are open, it should always be possible to open the _replicator DB
> internally (and the _users DB).
>
>
> cheers
>
>
> --
> Filipe David Manana,
> fdmanana@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."