Re: [jira] [Commented] (COUCHDB-1259) Replication ID is not stable if local server has a dynamic port number
it is working again . Someone fixed the jira conf.
On Tue, Nov 6, 2012 at 4:40 PM, Jan Lehnardt j...@apache.org wrote:
On Nov 5, 2012, at 08:54 , Benoit Chesneau bchesn...@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 bchesn...@gmail.com wrote:
On Mon, Nov 5, 2012 at 7:48 AM, Dustin Sallings dus...@spy.net wrote:
Benoit Chesneau bchesn...@gmail.com
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
Re: [jira] [Commented] (COUCHDB-1259) Replication ID is not stable if local server has a dynamic port number
Benoit, could you explain a bit more what you mean by the issue related to
the coordinated node.
I feel that TLS is the real security. I also favor using the _replicator
document ID as the checkpoint ID (it makes it impossible to have two
identical replications with different names, and I think this is good). I
would support the ability to specify the checkpoint ID, in any case, as I
believe Benoit is right that applications may want or needer finer control
over routing and checkpoints.
On Mon, Nov 5, 2012 at 3:06 PM, Benoit Chesneau (JIRA) j...@apache.orgwrote:
[
https://issues.apache.org/jira/browse/COUCHDB-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13491019#comment-13491019]
Benoit Chesneau commented on COUCHDB-1259:
--
There is a potential security issue using a remote node id like in the
second part of the patch. Local to local there is none.
I am + 1 for fixing the issue related to the coodinated node.
Replication ID is not stable if local server has a dynamic port number
--
Key: COUCHDB-1259
URL: https://issues.apache.org/jira/browse/COUCHDB-1259
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.1
Reporter: Jens Alfke
Assignee: Robert Newson
Priority: Blocker
Fix For: 1.3
Attachments: couchdb-1259.patch, couchdb-1259.patch
I noticed that when Couchbase Mobile running on iOS replicates to/from a
remote server (on iriscouch in this case), the replication has to fetch the
full _changes feed every time it starts. Filipe helped me track down the
problem -- the replication ID is coming out different every time. The
reason for this is that the local port number, which is one of the inputs
to the hash that generates the replication ID, is randomly assigned by the
OS. (I.e. it uses a port number of 0 when opening its listener socket.)
This is because there could be multiple apps using Couchbase Mobile running
on the same device and we can't have their ports colliding.
The underlying problem is that CouchDB is attempting to generate a
unique ID for a particular pair of {source, destination} databases, but
it's basing it on attributes that aren't fundamental to the database and
can change, like the hostname or port number.
One solution, proposed by Filipe and me, is to assign each database (or
each server?) a random UUID when it's created, and use that to generate
replication IDs.
Another solution, proposed by Damien, is to have CouchDB let the client
work out the replication ID on its own, and set it as a property in the
replication document (or the JSON body of a _replicate request.) This is
even more flexible and will handle tricky scenarios like full P2P
replication where there may be no low-level way to uniquely identify the
remote database being synced with.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Commented] (COUCHDB-1259) Replication ID is not stable if local server has a dynamic port number
On Thu, Nov 8, 2012 at 7:19 PM, Randall Leeds randall.le...@gmail.com wrote:
Benoit, could you explain a bit more what you mean by the issue related to
the coordinated node.
I was referrering to the scenario where a couchdb node acts as a
replication gateway only (where source and remotes are different nodes
than the one coordinating the replication).
I feel that TLS is the real security. I also favor using the _replicator
document ID as the checkpoint ID (it makes it impossible to have two
identical replications with different names, and I think this is good). I
would support the ability to specify the checkpoint ID, in any case, as I
believe Benoit is right that applications may want or needer finer control
over routing and checkpoints.
+1
On Mon, Nov 5, 2012 at 3:06 PM, Benoit Chesneau (JIRA) j...@apache.orgwrote:
[
https://issues.apache.org/jira/browse/COUCHDB-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13491019#comment-13491019]
Benoit Chesneau commented on COUCHDB-1259:
--
There is a potential security issue using a remote node id like in the
second part of the patch. Local to local there is none.
I am + 1 for fixing the issue related to the coodinated node.
Replication ID is not stable if local server has a dynamic port number
--
Key: COUCHDB-1259
URL: https://issues.apache.org/jira/browse/COUCHDB-1259
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.1
Reporter: Jens Alfke
Assignee: Robert Newson
Priority: Blocker
Fix For: 1.3
Attachments: couchdb-1259.patch, couchdb-1259.patch
I noticed that when Couchbase Mobile running on iOS replicates to/from a
remote server (on iriscouch in this case), the replication has to fetch the
full _changes feed every time it starts. Filipe helped me track down the
problem -- the replication ID is coming out different every time. The
reason for this is that the local port number, which is one of the inputs
to the hash that generates the replication ID, is randomly assigned by the
OS. (I.e. it uses a port number of 0 when opening its listener socket.)
This is because there could be multiple apps using Couchbase Mobile running
on the same device and we can't have their ports colliding.
The underlying problem is that CouchDB is attempting to generate a
unique ID for a particular pair of {source, destination} databases, but
it's basing it on attributes that aren't fundamental to the database and
can change, like the hostname or port number.
One solution, proposed by Filipe and me, is to assign each database (or
each server?) a random UUID when it's created, and use that to generate
replication IDs.
Another solution, proposed by Damien, is to have CouchDB let the client
work out the replication ID on its own, and set it as a property in the
replication document (or the JSON body of a _replicate request.) This is
even more flexible and will handle tricky scenarios like full P2P
replication where there may be no low-level way to uniquely identify the
remote database being synced with.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Commented] (COUCHDB-1259) Replication ID is not stable if local server has a dynamic port number
On Nov 5, 2012, at 08:54 , Benoit Chesneau bchesn...@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 bchesn...@gmail.com wrote:
On Mon, Nov 5, 2012 at 7:48 AM, Dustin Sallings dus...@spy.net wrote:
Benoit Chesneau bchesn...@gmail.com
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
Re: [jira] [Commented] (COUCHDB-1259) Replication ID is not stable if local server has a dynamic port number
On Nov 5, 2012 10:25 AM, Robert Newson (JIRA) j...@apache.org wrote:
[
https://issues.apache.org/jira/browse/COUCHDB-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13490527#comment-13490527]
Robert Newson commented on COUCHDB-1259:
Benoit, are you vetoing this change? If so, please include a reason why
improving the hit rate for replication checkpoints should not be included
in our next release.
how does it improve the hit rate? how is it related to this ticket?
Everyone else, please comment on the patch itself, I want feedback on 1)
the quality and correctness of the patch and 2) whether, when using UUID,
whether it is correct to use UUID instead of the {Scheme, UserInfo, UUID,
Path} tuple that I've chosen as I would prefer to simply use the UUID if
it's correct to do so for clarity.
https://github.com/apache/couchdb/pull/35
Replication ID is not stable if local server has a dynamic port number
--
Key: COUCHDB-1259
URL: https://issues.apache.org/jira/browse/COUCHDB-1259
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.1
Reporter: Jens Alfke
Assignee: Robert Newson
Priority: Blocker
Fix For: 1.3
Attachments: couchdb-1259.patch, couchdb-1259.patch
I noticed that when Couchbase Mobile running on iOS replicates to/from
a remote server (on iriscouch in this case), the replication has to fetch
the full _changes feed every time it starts. Filipe helped me track down
the problem -- the replication ID is coming out different every time. The
reason for this is that the local port number, which is one of the inputs
to the hash that generates the replication ID, is randomly assigned by the
OS. (I.e. it uses a port number of 0 when opening its listener socket.)
This is because there could be multiple apps using Couchbase Mobile running
on the same device and we can't have their ports colliding.
The underlying problem is that CouchDB is attempting to generate a
unique ID for a particular pair of {source, destination} databases, but
it's basing it on attributes that aren't fundamental to the database and
can change, like the hostname or port number.
One solution, proposed by Filipe and me, is to assign each database (or
each server?) a random UUID when it's created, and use that to generate
replication IDs.
Another solution, proposed by Damien, is to have CouchDB let the client
work out the replication ID on its own, and set it as a property in the
replication document (or the JSON body of a _replicate request.) This is
even more flexible and will handle tricky scenarios like full P2P
replication where there may be no low-level way to uniquely identify the
remote database being synced with.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Commented] (COUCHDB-1259) Replication ID is not stable if local server has a dynamic port number
i will once i find a device that can do it. in the meantime can we fix jira
so it can accept again the responses by mails? This is now on my priority
list.
benoit
On Nov 5, 2012 10:32 AM, Robert Newson rnew...@apache.org wrote:
please reply on the ticket.
On 5 November 2012 09:27, Benoit Chesneau bchesn...@gmail.com wrote:
On Nov 5, 2012 10:25 AM, Robert Newson (JIRA) j...@apache.org wrote:
[
https://issues.apache.org/jira/browse/COUCHDB-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13490527#comment-13490527
]
Robert Newson commented on COUCHDB-1259:
Benoit, are you vetoing this change? If so, please include a reason why
improving the hit rate for replication checkpoints should not be included
in our next release.
how does it improve the hit rate? how is it related to this ticket?
Everyone else, please comment on the patch itself, I want feedback on
1)
the quality and correctness of the patch and 2) whether, when using UUID,
whether it is correct to use UUID instead of the {Scheme, UserInfo, UUID,
Path} tuple that I've chosen as I would prefer to simply use the UUID if
it's correct to do so for clarity.
https://github.com/apache/couchdb/pull/35
Replication ID is not stable if local server has a dynamic port
number
--
Key: COUCHDB-1259
URL:
https://issues.apache.org/jira/browse/COUCHDB-1259
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.1
Reporter: Jens Alfke
Assignee: Robert Newson
Priority: Blocker
Fix For: 1.3
Attachments: couchdb-1259.patch, couchdb-1259.patch
I noticed that when Couchbase Mobile running on iOS replicates
to/from
a remote server (on iriscouch in this case), the replication has to fetch
the full _changes feed every time it starts. Filipe helped me track down
the problem -- the replication ID is coming out different every time. The
reason for this is that the local port number, which is one of the inputs
to the hash that generates the replication ID, is randomly assigned by
the
OS. (I.e. it uses a port number of 0 when opening its listener socket.)
This is because there could be multiple apps using Couchbase Mobile
running
on the same device and we can't have their ports colliding.
The underlying problem is that CouchDB is attempting to generate a
unique ID for a particular pair of {source, destination} databases, but
it's basing it on attributes that aren't fundamental to the database and
can change, like the hostname or port number.
One solution, proposed by Filipe and me, is to assign each database
(or
each server?) a random UUID when it's created, and use that to generate
replication IDs.
Another solution, proposed by Damien, is to have CouchDB let the
client
work out the replication ID on its own, and set it as a property in the
replication document (or the JSON body of a _replicate request.) This is
even more flexible and will handle tricky scenarios like full P2P
replication where there may be no low-level way to uniquely identify the
remote database being synced with.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] [Commented] (COUCHDB-1259) Replication ID is not stable if local server has a dynamic port number
Benoit
This problem has nothing to do with any application, its a bug in CouchDB
with a simple fix
On 4 November 2012 20:43, Benoit Chesneau (JIRA) j...@apache.org wrote:
[
https://issues.apache.org/jira/browse/COUCHDB-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13490449#comment-13490449]
Benoit Chesneau commented on COUCHDB-1259:
--
Hello are you understanding that this isn't only about your
application? Some may have different uses. And different routing policy.
And this is not the role of couchdb to fix them.
Replication ID is not stable if local server has a dynamic port number
--
Key: COUCHDB-1259
URL: https://issues.apache.org/jira/browse/COUCHDB-1259
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.1
Reporter: Jens Alfke
Assignee: Robert Newson
Priority: Blocker
Fix For: 1.3
Attachments: couchdb-1259.patch, couchdb-1259.patch
I noticed that when Couchbase Mobile running on iOS replicates to/from a
remote server (on iriscouch in this case), the replication has to fetch the
full _changes feed every time it starts. Filipe helped me track down the
problem -- the replication ID is coming out different every time. The
reason for this is that the local port number, which is one of the inputs
to the hash that generates the replication ID, is randomly assigned by the
OS. (I.e. it uses a port number of 0 when opening its listener socket.)
This is because there could be multiple apps using Couchbase Mobile running
on the same device and we can't have their ports colliding.
The underlying problem is that CouchDB is attempting to generate a
unique ID for a particular pair of {source, destination} databases, but
it's basing it on attributes that aren't fundamental to the database and
can change, like the hostname or port number.
One solution, proposed by Filipe and me, is to assign each database (or
each server?) a random UUID when it's created, and use that to generate
replication IDs.
Another solution, proposed by Damien, is to have CouchDB let the client
work out the replication ID on its own, and set it as a property in the
replication document (or the JSON body of a _replicate request.) This is
even more flexible and will handle tricky scenarios like full P2P
replication where there may be no low-level way to uniquely identify the
remote database being synced with.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Commented] (COUCHDB-1259) Replication ID is not stable if local server has a dynamic port number
Ok, I will do it again. This isn't a bug but a question of what do you expect.
I think it is expected in some cases that the replication won't
restart if the address change. Or it should be a application design
not something by default in couch.
On Mon, Nov 5, 2012 at 5:48 AM, Dale Harvey d...@arandomurl.com wrote:
Benoit
This problem has nothing to do with any application, its a bug in CouchDB
with a simple fix
On 4 November 2012 20:43, Benoit Chesneau (JIRA) j...@apache.org wrote:
[
https://issues.apache.org/jira/browse/COUCHDB-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13490449#comment-13490449]
Benoit Chesneau commented on COUCHDB-1259:
--
Hello are you understanding that this isn't only about your
application? Some may have different uses. And different routing policy.
And this is not the role of couchdb to fix them.
Replication ID is not stable if local server has a dynamic port number
--
Key: COUCHDB-1259
URL: https://issues.apache.org/jira/browse/COUCHDB-1259
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.1
Reporter: Jens Alfke
Assignee: Robert Newson
Priority: Blocker
Fix For: 1.3
Attachments: couchdb-1259.patch, couchdb-1259.patch
I noticed that when Couchbase Mobile running on iOS replicates to/from a
remote server (on iriscouch in this case), the replication has to fetch the
full _changes feed every time it starts. Filipe helped me track down the
problem -- the replication ID is coming out different every time. The
reason for this is that the local port number, which is one of the inputs
to the hash that generates the replication ID, is randomly assigned by the
OS. (I.e. it uses a port number of 0 when opening its listener socket.)
This is because there could be multiple apps using Couchbase Mobile running
on the same device and we can't have their ports colliding.
The underlying problem is that CouchDB is attempting to generate a
unique ID for a particular pair of {source, destination} databases, but
it's basing it on attributes that aren't fundamental to the database and
can change, like the hostname or port number.
One solution, proposed by Filipe and me, is to assign each database (or
each server?) a random UUID when it's created, and use that to generate
replication IDs.
Another solution, proposed by Damien, is to have CouchDB let the client
work out the replication ID on its own, and set it as a property in the
replication document (or the JSON body of a _replicate request.) This is
even more flexible and will handle tricky scenarios like full P2P
replication where there may be no low-level way to uniquely identify the
remote database being synced with.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Commented] (COUCHDB-1259) Replication ID is not stable if local server has a dynamic port number
On Mon, Nov 5, 2012 at 6:31 AM, Dustin Sallings (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/COUCHDB-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13490465#comment-13490465 ] Dustin Sallings commented on COUCHDB-1259: -- Note: My local address changes at least twice a day when I go into the office. The other end of my replication doesn't. It's hard to argue that this behavior is desirable. i am with my laptop in an office. Start a replication with a remote node. my laptop get an ip/port from dhcp, the remote has an ip / address. I'm moving in another office. connect to the dhcp. there is also a remote node with same ip/adress port than the first one but for confidentiality i shouldn't replicate to it. It is expected that the replication stop at this point. This scenario is more obvious if we take the example of someone gong from one stair to the other using the wifi. - benoit
Re: [jira] [Commented] (COUCHDB-1259) Replication ID is not stable if local server has a dynamic port number
Benoit Chesneau bchesn...@gmail.com writes: i am with my laptop in an office. Start a replication with a remote node. my laptop get an ip/port from dhcp, the remote has an ip / address. I'm moving in another office. connect to the dhcp. there is also a remote node with same ip/adress port than the first one but for confidentiality i shouldn't replicate to it. It is expected that the replication stop at this point. This scenario is more obvious if we take the example of someone gong from one stair to the other using the wifi. IMO, it makes more sense to optimize for the case where people don't create two servers with the same name and/or IP address in two different networks a single user is likely to connect to, but where the two servers have different replication policies that should be handled implicitly and SSL/TLS is not used to confirm the correct server is in place. Mysteriously running either two or zero replicas on my laptop for a single configured backend would *almost* be excusable with your justifications if it didn't fix itself when I restarted CouchDB. -- dustin
Re: [jira] [Commented] (COUCHDB-1259) Replication ID is not stable if local server has a dynamic port number
On Mon, Nov 5, 2012 at 7:08 AM, Dustin Sallings dus...@spy.net wrote: Benoit Chesneau bchesn...@gmail.com writes: i am with my laptop in an office. Start a replication with a remote node. my laptop get an ip/port from dhcp, the remote has an ip / address. I'm moving in another office. connect to the dhcp. there is also a remote node with same ip/adress port than the first one but for confidentiality i shouldn't replicate to it. It is expected that the replication stop at this point. This scenario is more obvious if we take the example of someone gong from one stair to the other using the wifi. IMO, it makes more sense to optimize for the case where people don't create two servers with the same name and/or IP address in two different networks a single user is likely to connect to, but where the two servers have different replication policies that should be handled implicitly and SSL/TLS is not used to confirm the correct server is in place. Mysteriously running either two or zero replicas on my laptop for a single configured backend would *almost* be excusable with your justifications if it didn't fix itself when I restarted CouchDB. -- dustin Just ask around you how many people aren't changing the default port of couchdb and pur their servers in usual ip ranges you expect from a server. Imo a port change is a significant event. - benoit
Re: [jira] [Commented] (COUCHDB-1259) Replication ID is not stable if local server has a dynamic port number
Benoit Chesneau bchesn...@gmail.com writes: Just ask around you how many people aren't changing the default port of couchdb and pur their servers in usual ip ranges you expect from a server. Imo a port change is a significant event. I am completely failing to understand what you're saying. This fails for me on my laptop for three cases: 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. Under what circumstances do you consider stop replicating after sleep, but start again if the user restarts CouchDB good behavior? -- dustin
Re: [jira] [Commented] (COUCHDB-1259) Replication ID is not stable if local server has a dynamic port number
On Mon, Nov 5, 2012 at 7:27 AM, Dustin Sallings dus...@spy.net wrote: Benoit Chesneau bchesn...@gmail.com writes: Just ask around you how many people aren't changing the default port of couchdb and pur their servers in usual ip ranges you expect from a server. Imo a port change is a significant event. I am completely failing to understand what you're saying. This fails for me on my laptop for three cases: 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. 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. - benoît
Re: [jira] [Commented] (COUCHDB-1259) Replication ID is not stable if local server has a dynamic port number
Benoit Chesneau bchesn...@gmail.com 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... 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? 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? -- dustin
Re: [jira] [Commented] (COUCHDB-1259) Replication ID is not stable if local server has a dynamic port number
On Mon, Nov 5, 2012 at 7:48 AM, Dustin Sallings dus...@spy.net wrote:
Benoit Chesneau bchesn...@gmail.com
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
Re: [jira] [Commented] (COUCHDB-1259) Replication ID is not stable if local server has a dynamic port number
btw sound like jira isn't handling mails now so we should continue
this discussion on the ticket.
On Mon, Nov 5, 2012 at 8:53 AM, Benoit Chesneau bchesn...@gmail.com wrote:
On Mon, Nov 5, 2012 at 7:48 AM, Dustin Sallings dus...@spy.net wrote:
Benoit Chesneau bchesn...@gmail.com
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
