On Mon, Nov 5, 2012 at 7:48 AM, Dustin Sallings <[email protected]> wrote:
> Benoit Chesneau <[email protected]>
> writes:
>
>>> 1. My home couchdb server (by hostname, only available from inside my
>>> house)
>>> 2. My work couchdb server (by hostname, available inside and outside,
>>> but the IP addresses are different in each location).
>>> 3. Iriscouch (by hostname, available everywhere on the same address)
>>>
>>> In all three cases, it can stop replication, but will resume again if
>>> I restart.
>>>
>> Most of these cases already work if you are using the new _replicator api.
>
> If you're referring to the replicator DB, then yes, that's the way
> I set up all my replications, and why it starts back up when I restart.
>
>>> Under what circumstances do you consider "stop replicating after
>>> sleep, but start again if the user restarts CouchDB" good behavior?
>>
>> - local replications should always restart.
>> - replication with remote should restart only if the remote didn't
>> change and my network didn't change.
>>
>> In other cases I need to rely on a mecanism to validate that I can
>> continue the replication. In that case I agree it can be automated and
>> we have different solution to do it. But that should never be a
>> default mecanism imo.
>
> Let's assume what you're saying is OK and that the real bug here is
> that it *does* restart when I kill and restart CouchDB...
Any log in couch? Does it simply stop the replication?
>
> The one that I notice the most is an application that collects data in
> my house that replicates to my laptop. The *only* time this can
> possibly work is when my laptop is on my home LAN. That means, for it
> to start properly, it has to be connected to my home LAN before I ever
> see anything.
>
> Then I go somewhere else. Let's assume the somewhere else has a
> host named "menudo" (which is the unfortunate hostname of the machine in
> my house running CouchDB). Because I'm on a different network, the
> replicator decides it's probably not the menudo I'm looking for, so it
> ceases replication.
>
> When I go back home, shouldn't it start back up?
At this point the replication should be stopped because it retried
too many time on your other network. I am not sure anyway that it is
desirable to restart it from the old replication doc at least without
checking that the remote is the remote.
>
> Doesn't this whole thing get a lot more simple and inline with what
> any reasonable user might expect if you just say, "configured
> replications run as configured"?
I agree, that it is interresting to have such features and i know at
least 2 projects proposing layers to handle that. Imo that is
requiring a small change in the the replicator client to check the
remote and eventually associate a remote id to an replication id and
change have a mapping [remote id, {Host, Port}] that is change after a
conversation with the remote node. That is this part that should be
switchable so for people that want it they could eventually check
against a node id . The logic depends on the application policy imo.
- benoît
