Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of bchesneau@gmail.com designates
 209.85.223.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <C13D6357-FF98-4E23-8B24-8DA9BDFC63E6@apache.org>
References: 
 <1220942000.7101.1314138329138.JavaMail.tomcat@hel.zones.apache.org>
	<1204283570.67667.1352093474335.JavaMail.jiratomcat@arcas>
	<CAJNb-9opt52OqRvc5bU5WsHA7xOz07x3z05YgFZk=xJx2sHxNA@mail.gmail.com>
	<m2txt48tuk.fsf@spy.net>
	<CAJNb-9omrygpR-vFrzANOr=_PSSK8vfstV3xUApXCQdWeG51tQ@mail.gmail.com>
	<m2pq3s8sz7.fsf@spy.net>
	<CAJNb-9p41BNesZw0Gjmjk75XD_Va5=PxCWbc0Agrm15yK_qa4A@mail.gmail.com>
	<m2hap48rzu.fsf@spy.net>
	<CAJNb-9q3Hv1an5zM0rh0crG5OFiwx6AxHxn3ou1JFv+bJ0nxrw@mail.gmail.com>
	<CAJNb-9qp7s9=f5hV-O9Fi5z-rLUvT1bYjL=2eSAeyCy4XPsHyQ@mail.gmail.com>
	<C13D6357-FF98-4E23-8B24-8DA9BDFC63E6@apache.org>
Date: Thu, 8 Nov 2012 17:44:49 +0100
Message-ID: 
 <CAJNb-9pTqD=yO8UZXyNYbL980Q4ZXOtV=noeMGe3Vu7AsARp1g@mail.gmail.com>
Subject: Re: [jira] [Commented] (COUCHDB-1259) Replication ID is not stable if
 local server has a dynamic port number
From: Benoit Chesneau <bchesneau@gmail.com>
To: "dev@couchdb.apache.org" <dev@couchdb.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

it is working again . Someone fixed the jira conf.

On Tue, Nov 6, 2012 at 4:40 PM, Jan Lehnardt <jan@apache.org> wrote:
>
> On Nov 5, 2012, at 08:54 , Benoit Chesneau <bchesneau@gmail.com> wrote:
>
>> btw sound like jira isn't handling mails now so we should continue
>> this discussion on the ticket.
>
> It never has, to my knowledge.
>
> IIRC it works with GitHub Issues/Pull Requests, but not here. Would be
> a great feature though.
>
> Cheers
> Jan
> --
>
>>
>> On Mon, Nov 5, 2012 at 8:53 AM, Benoit Chesneau <bchesneau@gmail.com> wr=
ote:
>>> On Mon, Nov 5, 2012 at 7:48 AM, Dustin Sallings <dustin@spy.net> wrote:
>>>> Benoit Chesneau <bchesneau@gmail.com>
>>>> writes:
>>>>
>>>>>> 1. My home couchdb server (by hostname, only available from inside m=
y
>>>>>>    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 i=
f
>>>>>> 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 an=
d
>>>>> 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=EEt
>