> On Mar 14, 2016, at 2:11 AM, [email protected] wrote: > > On 2016-03-14 13:40, Adam Kocoloski wrote: > >>>> My current solution watches the global _changes feed and fires up a >>>> continuous replication to an off-site server whenever it sees a change. If >>>> it doesn't see a change from a database for 10 minutes, it kills that >>>> replication. This means I only have ~150 active replications running on >>>> average at any given time. >>> How about instead of using continuous replications and killing them, >>> use non-continuous replications based on _db_updates? They end >>> automatically and should use fewer resources then. >>> Best >>> Jan >>> -- >> In my opinion this is actually a design we should adopt for CouchDB’s >> own replication manager. Keeping all those _changes listeners running >> is needlessly expensive now that we have _db_updates. >> Adam > > I like Jan's solution, and I'm going to try and use it for a project, but it > can't be the only solution, at least for one of my cases. In this case I work > with devices behind NAT that need to pull data from updated remote databases > with reasonably low latency. > > The source database can't start a push replication on _db_updates, because it > can't find the target database behind NAT. "Pull" replications have to be > started by the target database (the NATted device), which doesn't know > whether the source database is updated unless it's on a continuous > replication.
I’m missing something here Javier. A pull replication mediated on the target server should still be able to remotely hit _db_updates on the source, shouldn’t it? I do realize that there’s a potential permissions issue here, when the replication is executed with sufficient privileges to read from the source database but not enough to hit _db_updates. > Thanks for the high quality, high signal/noise list, btw. I don't usually say > anything because I don't think I have anything to add, but I always read with > interest. Agreed! I don’t get to spend as much time on CouchDB as I’d like, but I believe we’ve established a nice balance between Pull Requests, JIRA and dev@ that allows people to participate at whatever level makes the most sense. Cheers, Adam
