date:20121104

On 4 November 2012 02:44, john.tiger john.tigernas...@gmail.com wrote:
 a few questions so far:
 1) where does cors_enable=true get set  - tried to do sudo ./configure
 --cors_enable  that didn't work

Thanks for giving this a whirl! I suspect you may be the first pilot
user so really appreciate all those Y U NO WORK questions. Keep'em
coming please!!

http://wiki.apache.org/couchdb/CORS#Enabling_CORS

Your local.ini file will be something like
/usr/local/etc/couchdb/local.ini depending on OS  how you installed
couchdb. It's the same file you'll have set bind_address = 0.0.0.0 or
similar in. Here's mine:

[httpd]
;port = 5984
;bind_address = 127.0.0.1
bind_address = 0.0.0.0
enable_cors = true

I think that's all you're going to need.

 2) ini file ?  is that a windows thing ?  - also would be helpful to have an
 example of that

See wiki url above, let me know if that's sufficient.

 3) using autoconf gave the following:

Aargh. Yuck. autoconf fun.

I'm guessing you need a new auto* version. Not sure how you'd need to
upgrade, reply back with your OS/platform and hopefully somebody can
help you from here.

 configure.ac:22: error: possibly undefined macro: AM_CONFIG_HEADER

A+
Dave

Re: cors branch testing

cors_enable=true is a setting in default or local.ini not a configure argument.

- benoît

On Sun, Nov 4, 2012 at 2:44 AM, john.tiger john.tigernas...@gmail.com wrote:
 a few questions so far:
 1) where does cors_enable=true get set  - tried to do sudo ./configure
 --cors_enable  that didn't work
 2) ini file ?  is that a windows thing ?  - also would be helpful to have an
 example of that
 3) using autoconf gave the following:
 configure.ac:22: error: possibly undefined macro: AM_CONFIG_HEADER
   If this token and others are legitimate, please use m4_pattern_allow.
   See the Autoconf documentation.
 configure.ac:25: error: possibly undefined macro: AM_INIT_AUTOMAKE
 configure.ac:28: error: possibly undefined macro: AC_ENABLE_SHARED
 configure.ac:29: error: possibly undefined macro: AC_DISABLE_STATIC
 configure.ac:33: error: possibly undefined macro: AC_PROG_LIBTOOL
 configure.ac:61: error: possibly undefined macro: AC_DEFINE
 configure.ac:207: error: possibly undefined macro: AM_CONDITIONAL
 configure.ac:302: error: possibly undefined macro: AC_MSG_WARN
 configure.ac:334: error: possibly undefined macro: AC_CHECK_ICU
 configure.ac:352: error: possibly undefined macro: AC_CHECK_CURL

Re: CORS support


On 11/04/2012 01:34 AM, Simon Metson wrote:

Hi John,

we are trying it today - delayed by not realizing we needed to run
autoconf (should be in docs)

It is, in the DEVELOPERS file (which took me a while to notice, too).


okay and with @randall's suggestion ./bootstrap seemed to work okay - 
but still not sure where to enable cors in config - just don't see it 
anywhere

Re: cors branch testing


On 11/04/2012 06:09 AM, Benoit Chesneau wrote:

cors_enable=true is a setting in default or local.ini not a configure argument.


okay, got it, ignore my reply to Simon - will continue on.  we'll test 
with the default for all cross domains - then would like to figure out 
from your instructions on limiting to maybe a certain domain.  for 
example - if we are running a html 5/jquery app on either default (no 
port) or on a certain port say 8080 - and if couch is on standard 5984 
should the allowed port be 8080 or 5984 ?

[jira] [Created] (COUCHDB-1589) Support +json convention in media types

2012-11-04 Thread Mark Baker (JIRA)

Mark Baker created COUCHDB-1589:
---

 Summary: Support +json convention in media types
 Key: COUCHDB-1589
 URL: https://issues.apache.org/jira/browse/COUCHDB-1589
 Project: CouchDB
  Issue Type: Improvement
Affects Versions: 1.1.1
Reporter: Mark Baker
Priority: Minor


The use of the +json suffix in media types is being standardized in 
http://tools.ietf.org/html/draft-ietf-appsawg-media-type-suffix-regs

It would be nice if Couch supported the use of those types instead of rejecting 
non application/json content. Doing this properly would suggest that the media 
type would have to be remembered per document so that it can be returned on a 
GET. I don't foresee any other problems with this change. 

I was only able to verify this in versions prior to 1.2 so apologies if it's 
already been added for 1.2.

--
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: Futon.Next - Streaming Results

2012-11-04 Thread Simon Metson

Hi Ryan,
 One question I have is with the use of Backbone and streaming responses.
 Can it's collection models be set to work with a streaming source? We would
 somehow have to hook into its url handling and also render partial
 templates on each 'row' object received. Anyone have some suggestions on
 how to proceed to do that?
 

There are a number of options, and they can be done on a per collection basis. 
You'd just override the collections fetch method and hook in the streaming 
there, I think.
Cheers
Simon

Re: cors branch testing


On 11/04/2012 06:09 AM, Benoit Chesneau wrote:

cors_enable=true is a setting in default or local.ini not a configure argument.

- benoît

On Sun, Nov 4, 2012 at 2:44 AM, john.tiger john.tigernas...@gmail.com wrote:

a few questions so far:
1) where does cors_enable=true get set  - tried to do sudo ./configure
--cors_enable  that didn't work
2) ini file ?  is that a windows thing ?  - also would be helpful to have an
example of that
3) using autoconf gave the following:
configure.ac:22: error: possibly undefined macro: AM_CONFIG_HEADER
   If this token and others are legitimate, please use m4_pattern_allow.
   See the Autoconf documentation.
configure.ac:25: error: possibly undefined macro: AM_INIT_AUTOMAKE
configure.ac:28: error: possibly undefined macro: AC_ENABLE_SHARED
configure.ac:29: error: possibly undefined macro: AC_DISABLE_STATIC
configure.ac:33: error: possibly undefined macro: AC_PROG_LIBTOOL
configure.ac:61: error: possibly undefined macro: AC_DEFINE
configure.ac:207: error: possibly undefined macro: AM_CONDITIONAL
configure.ac:302: error: possibly undefined macro: AC_MSG_WARN
configure.ac:334: error: possibly undefined macro: AC_CHECK_ICU
configure.ac:352: error: possibly undefined macro: AC_CHECK_CURL



okay, from @randall, used ./bootstrap to create configure file. sudo 
./configure, then sudo make and sudo make install ran okay except for:


gzip -9  README  README.gz
fatal: ambiguous argument '6c976bd..HEAD': unknown revision or path not 
in the working tree.

Use '--' to separate paths from revisions

but this might have to do with libs in this linuxmint 12.04 (ubuntu 
12.04 based) - oh, how I wish i could install debian unstable on this 
macbook 2.1 (:


re @dch - also in this vendor mix,  the ini files are under /etc/couchdb

do not see any cors_enable in either default or local ini - easy enough 
to add but want to be sure if it should already be in the ini files in 
this build or that I don't have the right ini files - meanwhile we'll 
just add and continue testing.

Re: cors branch testing

On Sun, Nov 4, 2012 at 4:07 PM, john.tiger john.tigernas...@gmail.com wrote:

 do not see any cors_enable in either default or local ini - easy enough to
 add but want to be sure if it should already be in the ini files in this
 build or that I don't have the right ini files - meanwhile we'll just add
 and continue testing.

Are you using the correct branch ? It should be there after the bootstrap.

- benoît

Re: Source code layout

What do you think about this proposal ? I would like to start some
work around soon.

On Thu, Nov 1, 2012 at 4:02 PM, Benoit Chesneau bchesn...@gmail.com wrote:



 On Thu, Nov 1, 2012 at 12:39 PM, Adam Kocoloski kocol...@apache.org wrote:

 I see.  So the enhanced layout is something we would do to better organize
 couch_core.  Aside from that you're still talking about following the
 general layout that you've used with rcouch, right?

 Adam


 still undecided if it's better to have a core composed of multiple apps in
 the repo or one app but nested folders in src like the inets thing, but yes.

 - benoît

Re: Futon.Next Proof of Concept

On 4 November 2012 11:12, Simon Metson si...@cloudant.com wrote:
 Hi,


 On Saturday, 3 November 2012 at 18:17, Benoit Chesneau wrote:

 btw, we only talked of futon as a couchapp. but with the coming CORS
 feature (pushed this week in a branch) it could also be on the fs which can
 be interesting sometimes.

 The code in the fork allows both; it will compile into share/www/ to be 
 served as futon is now or can be pushed as a couchapp (thanks Garren!).

Yay Garren!!

[jira] [Assigned] (COUCHDB-1582) OpenSSL Deprecation of SSLv2

2012-11-04 Thread Dave Cottlehuber (JIRA)


 [ 
https://issues.apache.org/jira/browse/COUCHDB-1582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dave Cottlehuber reassigned COUCHDB-1582:
-

Assignee: Dave Cottlehuber

 OpenSSL Deprecation of SSLv2
 

 Key: COUCHDB-1582
 URL: https://issues.apache.org/jira/browse/COUCHDB-1582
 Project: CouchDB
  Issue Type: Bug
  Components: Infrastructure
Affects Versions: 1.2
 Environment: Ubuntu 12.04 and CouchDB 1.2 - might be ok with 2.0 Beta 
 but not tested.
Reporter: Ed Young
Assignee: Dave Cottlehuber
Priority: Critical

 /opt/bitnami/common/lib/libcurl.so: undefined reference to 
 `SSLv2_client_method'
 collect2: ld returned 1 exit status
 make[4]: *** [couchjs] Error 1
 make[4]: Leaving directory `/data/couchdb_source/couchdb/src/couchdb/priv'
 make[3]: *** [all-recursive] Error 1
 make[3]: Leaving directory `/data/couchdb_source/couchdb/src/couchdb'
 make[2]: *** [all-recursive] Error 1
 make[2]: Leaving directory `/data/couchdb_source/couchdb/src'
 make[1]: *** [all-recursive] Error 1
 make[1]: Leaving directory `/data/couchdb_source/couchdb'
 make: *** [all] Error 2
 Support for SSLv2 was removed as of OpenSSL 1.x.x (RFC 6176) which ships with 
 Ubuntu 12.04.
 Potential solutions:
 1. Patch installation;
 2. Degrade OpenSSL version.

--
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: Futon.Next Proof of Concept

2012-11-04 Thread Russell Branca

On Sat, Nov 3, 2012 at 11:23 AM, Noah Slater nsla...@apache.org wrote:
 On 3 November 2012 17:31, Simon Metson si...@cloudant.com wrote:


 It's just code, I don't have a huge preference to where it sits, and I'd
 like for it to end up in CouchDB land (assuming people like it). If I were
 a committer it'd be in a branch today.


 Cool. Well, you should be a committer then. Because when this lands, I'll
 sure has hell be wanting to make you one then, in any case. I'd like to see
 a show of hands of who else is planning to hack on this, and whether
 committership  feature branch proposal would be a help or a hinderance to
 them working on this and having fun. If there's a small core group and
 you're all +0 (or stronger) on it, I'll try to make it happen. People who
 are very new to our community might be able to contribute will PRs against
 the feature branch in our Github mirror, for the time being, no?

 --
 NS

I don't have a particular preference for location of the code, but I
do want to avoid getting locked behind a PR for every change, so my
current preference is retaining it on the cloudant labs organization.


-Russell

Re: cors branch testing


On 11/04/2012 08:19 AM, Benoit Chesneau wrote:

On Sun, Nov 4, 2012 at 4:07 PM, john.tiger john.tigernas...@gmail.com wrote:


do not see any cors_enable in either default or local ini - easy enough to
add but want to be sure if it should already be in the ini files in this
build or that I don't have the right ini files - meanwhile we'll just add
and continue testing.


Are you using the correct branch ? It should be there after the bootstrap.


yes, in the right branch - the branch /etc folder has default.ini with 
the cors_enabled line - so apparently the bootstrap is not overwriting 
the system /etc/couchdb/default.ini file  or this happened in make 
install - not sure - ran both with sudo so should not be a permission thing







- benoît

[jira] [Commented] (COUCHDB-1536) Integrate Docs into Release Process

2012-11-04 Thread Dave Cottlehuber (JIRA)


[ 
https://issues.apache.org/jira/browse/COUCHDB-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13490269#comment-13490269
 ] 

Dave Cottlehuber commented on COUCHDB-1536:
---

Point taken, but can you add a --without-docs flag for configure? Or at least a 
--without-pdf-for-lazy-windows-packagers ?

My 0.02c, more  more people build directly from git tag checkouts (it's not 
just one solitary windows packager), especially while we are working on a new 
release branch. If possible building from git shouldn't require all tools for 
building an ASF release.


 Integrate Docs into Release Process
 ---

 Key: COUCHDB-1536
 URL: https://issues.apache.org/jira/browse/COUCHDB-1536
 Project: CouchDB
  Issue Type: Improvement
  Components: Documentation
Affects Versions: 1.3
Reporter: Dave Cottlehuber
Assignee: Noah Slater
  Labels: docs,, make
 Fix For: 1.3


 List of outstanding tasks for integrating documentation into CouchDB build 
 chain:
 - create DNS CNAME docs - couchdb.readthedocs.org 
 - add that to quicklinks on main site
 - extend makefile to: check for sphinx-build in PATH,  do the right thing in 
 make dist
 - check if that works in VPATH build
 - update wiki /Documentation as required

--
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

[jira] [Updated] (COUCHDB-1536) Integrate Docs into Release Process

2012-11-04 Thread Dave Cottlehuber (JIRA)


 [ 
https://issues.apache.org/jira/browse/COUCHDB-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dave Cottlehuber updated COUCHDB-1536:
--

Priority: Blocker  (was: Major)

 Integrate Docs into Release Process
 ---

 Key: COUCHDB-1536
 URL: https://issues.apache.org/jira/browse/COUCHDB-1536
 Project: CouchDB
  Issue Type: Improvement
  Components: Documentation
Affects Versions: 1.3
Reporter: Dave Cottlehuber
Assignee: Noah Slater
Priority: Blocker
  Labels: docs,, make
 Fix For: 1.3


 List of outstanding tasks for integrating documentation into CouchDB build 
 chain:
 - create DNS CNAME docs - couchdb.readthedocs.org 
 - add that to quicklinks on main site
 - extend makefile to: check for sphinx-build in PATH,  do the right thing in 
 make dist
 - check if that works in VPATH build
 - update wiki /Documentation as required

--
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

[jira] [Commented] (COUCHDB-1536) Integrate Docs into Release Process


[ 
https://issues.apache.org/jira/browse/COUCHDB-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13490274#comment-13490274
 ] 

Benoit Chesneau commented on COUCHDB-1536:
--

do we really need to provide a PDF build  ?

 Integrate Docs into Release Process
 ---

 Key: COUCHDB-1536
 URL: https://issues.apache.org/jira/browse/COUCHDB-1536
 Project: CouchDB
  Issue Type: Improvement
  Components: Documentation
Affects Versions: 1.3
Reporter: Dave Cottlehuber
Assignee: Noah Slater
Priority: Blocker
  Labels: docs,, make
 Fix For: 1.3


 List of outstanding tasks for integrating documentation into CouchDB build 
 chain:
 - create DNS CNAME docs - couchdb.readthedocs.org 
 - add that to quicklinks on main site
 - extend makefile to: check for sphinx-build in PATH,  do the right thing in 
 make dist
 - check if that works in VPATH build
 - update wiki /Documentation as required

--
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

[jira] [Created] (COUCHDB-1590) man pages

Benoit Chesneau created COUCHDB-1590:


 Summary: man pages
 Key: COUCHDB-1590
 URL: https://issues.apache.org/jira/browse/COUCHDB-1590
 Project: CouchDB
  Issue Type: Improvement
  Components: Documentation
Affects Versions: 1.4
Reporter: Benoit Chesneau


It would be interresting to provides man pages about couchdb commands and API. 
At least it can be useful in some admin environments.

--
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

[jira] [Commented] (COUCHDB-431) cors - aka Cross-Origin Resource Sharing support


[ 
https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13490277#comment-13490277
 ] 

Benoit Chesneau commented on COUCHDB-431:
-

bump. Any reviews are welcome.

 cors - aka Cross-Origin Resource Sharing  support
 -

 Key: COUCHDB-431
 URL: https://issues.apache.org/jira/browse/COUCHDB-431
 Project: CouchDB
  Issue Type: New Feature
  Components: HTTP Interface
Affects Versions: 0.9
Reporter: James Burke
Assignee: Benoit Chesneau
Priority: Blocker
 Fix For: 1.3

 Attachments: 0001-cors-support.-should-fix-COUCHDB-431-2.patch, 
 0001-cors-support.-should-fix-COUCHDB-431.patch, 
 0001-cors-support.-should-fix-COUCHDB-431.patch, 
 0001-cors-support.-should-fix-COUCHDB-431.patch, 
 0001-cors-support.-should-fix-COUCHDB-431.patch, 
 A_0001-Generalize-computing-the-appropriate-headers-for-any.patch, 
 A_0002-Send-server-headers-for-externals-responses.patch, 
 A_0003-Usably-correct-w3c-CORS-headers-for-valid-requests.patch, 
 A_0004-Respond-to-CORS-preflight-checks-HTTP-OPTIONS.patch, cors.html, 
 cors_test.html, test_cors2-1.tgz, test_cors2.tgz


 Historically, browsers have been restricted to making XMLHttpRequests (XHRs) 
 to the same origin (domain) as the web page making the request. However, the 
 latest browsers now support cross-domain requests by implementing the Access 
 Control spec from the W3C:
 http://dev.w3.org/2006/waf/access-control/
 In order to keep older servers safe that assume browsers only do same-domain 
 requests, the Access Control spec requires the server to opt-in to allow 
 cross domain requests by the use of special HTTP headers and supporting some 
 pre-flight HTTP calls.
 Why should CouchDB support this: in larger, high traffic site, it is common 
 to serve the static UI files from a separate, differently scaled server 
 complex than the data access/API server layer. Also, there are some API 
 services that are meant to be centrally hosted, but allow API consumers to 
 use the API from different domains. In these cases, the UI in the browser 
 would need to do cross domain requests to access CouchDB servers that act as 
 the API/data access server layer.
 JSONP is not enough in these cases since it is limited to GET requests, so no 
 POSTing or PUTing of documents.
 Some information from Firefox's perspective (functionality available as of 
 Firefox 3.5):
 https://developer.mozilla.org/en/HTTP_access_control
 And information on Safari/Webkit (functionality in latest WebKit and Safari 
 4):
 http://developer.apple.com/safari/library/documentation/AppleApplications/Conceptual/SafariJSProgTopics/Articles/XHR.html
 IE 8 also uses the Access Control spec, but the requests have to go through 
 their XDomainRequest object (XDR):
 http://msdn.microsoft.com/en-us/library/cc288060%28VS.85%29.aspx
 and I thought IE8 only allowed GET or POST requests through their XDR.
 But as far as CouchDB is concerned, implementing the Access Control headers 
 should be enough, and hopefully IE 9 will allow normal xdomain requests via 
 XHR.

--
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

[jira] [Commented] (COUCHDB-1259) Replication ID is not stable if local server has a dynamic port number

[
https://issues.apache.org/jira/browse/COUCHDB-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13490279#comment-13490279
]

Benoit Chesneau commented on COUCHDB-1259:
--

I was reading the comment, and not sure it's a probem. Irt's expected in a p2p
world and master-master replication that the node at the end could change. What
doesn't changes are the data inside the dbs. Imo tthis is the role of the
application to handle port,ips, dns changes. Not couchdb. In short I would
close this issue as a wontfix.

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

[jira] [Commented] (COUCHDB-1536) Integrate Docs into Release Process

2012-11-04 Thread Alexander Shorin (JIRA)


[ 
https://issues.apache.org/jira/browse/COUCHDB-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13490282#comment-13490282
 ] 

Alexander Shorin commented on COUCHDB-1536:
---

Following my experience, to provide really good PDF build there is need to 
review docs very careful for each changes since sphinx-rst2pdf doesn't respect 
any typography rules and at least you'll get a big problems with page breaking 
(e.g. section header at the end of page,  split code block for two pages etc.). 
To fix this, there is need to setup special latex page breakers markers and 
check that they breaks page correctly before build release PDF version. If you 
want to get PDF docs as just a fact without caring about result quality - 
that's ok to go with default state. If you still care about and want to provide 
nice and readable PDF docs - that's another non-trivial task to carry on, 
sometimes not compatible with formats.

 Integrate Docs into Release Process
 ---

 Key: COUCHDB-1536
 URL: https://issues.apache.org/jira/browse/COUCHDB-1536
 Project: CouchDB
  Issue Type: Improvement
  Components: Documentation
Affects Versions: 1.3
Reporter: Dave Cottlehuber
Assignee: Noah Slater
Priority: Blocker
  Labels: docs,, make
 Fix For: 1.3


 List of outstanding tasks for integrating documentation into CouchDB build 
 chain:
 - create DNS CNAME docs - couchdb.readthedocs.org 
 - add that to quicklinks on main site
 - extend makefile to: check for sphinx-build in PATH,  do the right thing in 
 make dist
 - check if that works in VPATH build
 - update wiki /Documentation as required

--
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

[jira] [Commented] (COUCHDB-1346) CouchDB hangs during start of view indexing


[ 
https://issues.apache.org/jira/browse/COUCHDB-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13490283#comment-13490283
 ] 

Benoit Chesneau commented on COUCHDB-1346:
--

@davisp since couch_index know who is waiting for the index couldn't we use 
that information for such purpose?

 CouchDB hangs during start of view indexing
 ---

 Key: COUCHDB-1346
 URL: https://issues.apache.org/jira/browse/COUCHDB-1346
 Project: CouchDB
  Issue Type: Bug
  Components: View Server Support
Affects Versions: 1.3
 Environment: Windows 7 Enterprise only, not able to replicate on Mac 
 OS X.
 Erlang R14B03 + crypto patches.
 Mozilla Javascript 1.8.5
Reporter: Dave Cottlehuber
Assignee: Dave Cottlehuber
Priority: Blocker
  Labels: Windows
 Fix For: 1.3


 [info] [0.20499.0] Opening index for db: test_suite_db idx: 
 f4421bf4e9c9bf2acb3db91bca9e9adc sig: d5c87ad33242b181f86be2139cbccd96
 [info] [0.20504.0] Starting index update for db: test_suite_db idx: 
 f4421bf4e9c9bf2acb3db91bca9e9adc
 [info] [0.20334.0] 172.16.40.1 - - POST /test_suite_db/_temp_view 500
 [info] [0.20513.0] 172.16.40.1 - - GET 
 /_utils/couch_tests.html?script/couch_tests.js 200
 [info] [0.20514.0] 172.16.40.1 - - GET /_utils/index.html 200
 [info] [0.20060.0] 172.16.40.1 - - DELETE /test_suite_db_a/ 200
 [info] [0.20407.0] 172.16.40.1 - - GET /test_suite_reports/ 404
 [info] [0.20058.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
 [info] [0.20071.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
 [info] [0.20069.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
 [info] [0.20484.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
 [info] [0.20364.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
 [info] [0.20062.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
 [info] [0.20388.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
 [info] [0.20345.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
 [info] [0.20072.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
 [info] [0.20059.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
 [info] [0.20061.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
 [info] [0.20472.0] 172.16.40.1 - - DELETE /test_suite_db/ 200
 [error] [0.20050.0] ** Generic server couch_index_server terminating 
 ** Last message in was {'$gen_cast',{reset_indexes,test_suite_db}}
 ** When Server state == {st,../var/lib/couchdb}
 ** Reason for termination == 
 ** {{case_clause,{error,eacces}},
 [{couch_file,'-nuke_dir/2-fun-0-',3},
  {lists,foreach,2},
  {couch_file,nuke_dir,2},
  {couch_index_server,handle_cast,2},
  {gen_server,handle_msg,5},
  {proc_lib,init_p_do_apply,3}]}
 =ERROR REPORT 23-Nov-2011::21:17:14 ===
 ** Generic server couch_index_server terminating 
 ** Last message in was {'$gen_cast',{reset_indexes,test_suite_db}}
 ** When Server state == {st,../var/lib/couchdb}
 ** Reason for termination == 
 ** {{case_clause,{error,eacces}},
 [{couch_file,'-nuke_dir/2-fun-0-',3},
  {lists,foreach,2},
  {couch_file,nuke_dir,2},
  {couch_index_server,handle_cast,2},
  {gen_server,handle_msg,5},
  {proc_lib,init_p_do_apply,3}]}
 [error] [0.20050.0] {error_report,0.19957.0,
   {0.20050.0,crash_report,
[[{initial_call,
  {couch_index_server,init,['Argument__1']}},
  {pid,0.20050.0},
  {registered_name,couch_index_server},
  {error_info,
  {exit,
  {{case_clause,{error,eacces}},
   [{couch_file,'-nuke_dir/2-fun-0-',3},
{lists,foreach,2},
{couch_file,nuke_dir,2},
{couch_index_server,handle_cast,2},
{gen_server,handle_msg,5},
{proc_lib,init_p_do_apply,3}]},
  [{gen_server,terminate,6},
   {proc_lib,init_p_do_apply,3}]}},
  {ancestors,
  [couch_secondary_services,couch_server_sup,
   0.19958.0]},
  {messages,
  [{'$gen_cast',
   
 {reset_indexes,test_suite_db_a}}]},
  {links,[0.20051.0,0.20026.0]},
  {dictionary,[]},
  {trap_exit,true},
  {status,running},
  {heap_size,1597},

Re: Futon.Next Proof of Concept

On 4 November 2012 19:39, Russell Branca chewbra...@gmail.com wrote:
 NS

 I don't have a particular preference for location of the code, but I
 do want to avoid getting locked behind a PR for every change, so my
 current preference is retaining it on the cloudant labs organization.


 -Russell

Hi Russell,

I'm sure I don't follow this anymore, is this then a community project
or a cloudant one? Your preference implies the latter, however I'm
hoping it's the former.

A+
Dave

[jira] [Commented] (COUCHDB-1590) man pages

2012-11-04 Thread Alexander Shorin (JIRA)


[ 
https://issues.apache.org/jira/browse/COUCHDB-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13490287#comment-13490287
 ] 

Alexander Shorin commented on COUCHDB-1590:
---

By default sphinx is able to generate man pages from rst files via `make man` 
command. However, need to check that this cmd still works with Noah modified 
conf.py and make files...

 man pages
 -

 Key: COUCHDB-1590
 URL: https://issues.apache.org/jira/browse/COUCHDB-1590
 Project: CouchDB
  Issue Type: Improvement
  Components: Documentation
Affects Versions: 1.4
Reporter: Benoit Chesneau

 It would be interresting to provides man pages about couchdb commands and 
 API. At least it can be useful in some admin environments.

--
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: Futon.Next Proof of Concept

2012-11-04 Thread Russell Branca

On Sun, Nov 4, 2012 at 11:58 AM, Dave Cottlehuber d...@jsonified.com wrote:
 On 4 November 2012 19:39, Russell Branca chewbra...@gmail.com wrote:
 NS

 I don't have a particular preference for location of the code, but I
 do want to avoid getting locked behind a PR for every change, so my
 current preference is retaining it on the cloudant labs organization.


 -Russell

 Hi Russell,

 I'm sure I don't follow this anymore, is this then a community project
 or a cloudant one? Your preference implies the latter, however I'm
 hoping it's the former.

 A+
 Dave

I wasn't trying to imply anything at all. Code needs to go somewhere,
and my concern is about turn around time on PRs. Simon lives in a
different part of the world from me, so coordinating pull requests
isn't practical. Basically I'll be working out of whereever I have a
commit bit to. So if that means working out of the cloudant labs
server and submitting pull requests to the apache repo, then that's
fine. I wasn't trying to imply this was a community project or a
cloudant one, but rather stated my preference to a repo I already have
access to and where we've been working from so far.


-Russell

Re: Futon.Next Proof of Concept

2012-11-04 Thread Jan Lehnardt

On 04.11.2012, at 20:58, Dave Cottlehuber d...@jsonified.com wrote:

 On 4 November 2012 19:39, Russell Branca chewbra...@gmail.com wrote:
 NS
 
 I don't have a particular preference for location of the code, but I
 do want to avoid getting locked behind a PR for every change, so my
 current preference is retaining it on the cloudant labs organization.
 
 
 -Russell
 
 Hi Russell,
 
 I'm sure I don't follow this anymore, is this then a community project
 or a cloudant one? Your preference implies the latter, however I'm
 hoping it's the former.

I don't think the location of the CouchDB repo inside the Cloudant Git

Re: Futon.Next Proof of Concept

2012-11-04 Thread Jan Lehnardt


On 04.11.2012, at 20:58, Dave Cottlehuber d...@jsonified.com wrote:

 On 4 November 2012 19:39, Russell Branca chewbra...@gmail.com wrote:
 NS
 
 I don't have a particular preference for location of the code, but I
 do want to avoid getting locked behind a PR for every change, so my
 current preference is retaining it on the cloudant labs organization.
 
 
 -Russell
 
 Hi Russell,
 
 I'm sure I don't follow this anymore, is this then a community project
 or a cloudant one? Your preference implies the latter, however I'm
 hoping it's the former.

I don't think the location of the clone of the CouchDB repo inside the Cloudant 
GitHub organisation is an indication of whether this is a community effort or 
not. The beauty of git is that it doesn't matter where the code lives. The 
community developing Futon.Next is still very much us.

Cheers
Jan
--

Re: cors branch testing

2012-11-04 Thread Randall Leeds

I believe the default configuration of make install will install in
/usr/local. If you have files in /etc (instead of /usr/local/etc), then It
sounds like there is a system-installed couchdb package.

One way to test is to run make dev and then you can launch CouchDB from
the source tree without installing by running ./utils/run. Make sure any
system-wide couchdb is stopped. The configuration files will be in
etc/couchdb in the source tree after building.


On Sun, Nov 4, 2012 at 11:09 AM, john.tiger john.tigernas...@gmail.comwrote:

 On 11/04/2012 08:19 AM, Benoit Chesneau wrote:

 On Sun, Nov 4, 2012 at 4:07 PM, john.tiger john.tigernas...@gmail.com
 wrote:

  do not see any cors_enable in either default or local ini - easy enough
 to
 add but want to be sure if it should already be in the ini files in this
 build or that I don't have the right ini files - meanwhile we'll just add
 and continue testing.

  Are you using the correct branch ? It should be there after the
 bootstrap.


 yes, in the right branch - the branch /etc folder has default.ini with the
 cors_enabled line - so apparently the bootstrap is not overwriting the
 system /etc/couchdb/default.ini file  or this happened in make install -
 not sure - ran both with sudo so should not be a permission thing





 - benoīt

Re: cors branch testing

2012-11-04 Thread Jan Lehnardt

On 04.11.2012, at 21:41, Randall Leeds randall.le...@gmail.com wrote:

 I believe the default configuration of make install will install in
 /usr/local. If you have files in /etc (instead of /usr/local/etc), then It
 sounds like there is a system-installed couchdb package.
 
 One way to test is to run make dev and then you can launch CouchDB from
 the source tree without installing by running ./utils/run. Make sure any
 system-wide couchdb is stopped. The configuration files will be in
 etc/couchdb in the source tree after building.

Note that when running make dev, which is definitely recommended, that the 
respective .ini files are etc/couchdb/default_dev.ini  local_dev.ini

Cheers
Jan
--



 
 
 On Sun, Nov 4, 2012 at 11:09 AM, john.tiger john.tigernas...@gmail.comwrote:
 
 On 11/04/2012 08:19 AM, Benoit Chesneau wrote:
 
 On Sun, Nov 4, 2012 at 4:07 PM, john.tiger john.tigernas...@gmail.com
 wrote:
 
 do not see any cors_enable in either default or local ini - easy enough
 to
 add but want to be sure if it should already be in the ini files in this
 build or that I don't have the right ini files - meanwhile we'll just add
 and continue testing.
 
 Are you using the correct branch ? It should be there after the
 bootstrap.
 
 yes, in the right branch - the branch /etc folder has default.ini with the
 cors_enabled line - so apparently the bootstrap is not overwriting the
 system /etc/couchdb/default.ini file  or this happened in make install -
 not sure - ran both with sudo so should not be a permission thing
 
 
 
 
 
 - benoīt

Re: Futon.Next Proof of Concept

2012-11-04 Thread Octavian Damiean

Indeed, we can just PR to the Cloudant repo.

On Sun, Nov 4, 2012 at 9:26 PM, Jan Lehnardt j...@php.net wrote:


 On 04.11.2012, at 20:58, Dave Cottlehuber d...@jsonified.com wrote:

  On 4 November 2012 19:39, Russell Branca chewbra...@gmail.com wrote:
  NS
 
  I don't have a particular preference for location of the code, but I
  do want to avoid getting locked behind a PR for every change, so my
  current preference is retaining it on the cloudant labs organization.
 
 
  -Russell
 
  Hi Russell,
 
  I'm sure I don't follow this anymore, is this then a community project
  or a cloudant one? Your preference implies the latter, however I'm
  hoping it's the former.

 I don't think the location of the clone of the CouchDB repo inside the
 Cloudant GitHub organisation is an indication of whether this is a
 community effort or not. The beauty of git is that it doesn't matter where
 the code lives. The community developing Futon.Next is still very much us.

 Cheers
 Jan
 --

Re: cors branch testing

@ randall, oh, good catch - there is a system installed package - will 
stop it - in fact, will delete it (this is a test machine and only want 
to run couch with cors on it).  onward and upward.


On 11/04/2012 01:57 PM, Jan Lehnardt wrote:

On 04.11.2012, at 21:41, Randall Leeds randall.le...@gmail.com wrote:


I believe the default configuration of make install will install in
/usr/local. If you have files in /etc (instead of /usr/local/etc), then It
sounds like there is a system-installed couchdb package.

One way to test is to run make dev and then you can launch CouchDB from
the source tree without installing by running ./utils/run. Make sure any
system-wide couchdb is stopped. The configuration files will be in
etc/couchdb in the source tree after building.

Note that when running make dev, which is definitely recommended, that the 
respective .ini files are etc/couchdb/default_dev.ini  local_dev.ini

Cheers
Jan
--





On Sun, Nov 4, 2012 at 11:09 AM, john.tiger john.tigernas...@gmail.comwrote:


On 11/04/2012 08:19 AM, Benoit Chesneau wrote:


On Sun, Nov 4, 2012 at 4:07 PM, john.tiger john.tigernas...@gmail.com
wrote:

do not see any cors_enable in either default or local ini - easy enough

to
add but want to be sure if it should already be in the ini files in this
build or that I don't have the right ini files - meanwhile we'll just add
and continue testing.

Are you using the correct branch ? It should be there after the

bootstrap.

yes, in the right branch - the branch /etc folder has default.ini with the
cors_enabled line - so apparently the bootstrap is not overwriting the
system /etc/couchdb/default.ini file  or this happened in make install -
not sure - ran both with sudo so should not be a permission thing






- benoīt

[jira] [Commented] (COUCHDB-1259) Replication ID is not stable if local server has a dynamic port number


[ 
https://issues.apache.org/jira/browse/COUCHDB-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13490352#comment-13490352
 ] 

Jens Alfke commented on COUCHDB-1259:
-

Benoit: I think you're misunderstanding the issue. This isn't something about 
P2P. It's just that if the local CouchDB is not *listening* on a fixed port 
number, then replications made by that server to/from another server aren't 
handled efficiently ... even though the local server's port number has nothing 
at all to do with the replication (since it's the one making the connections.)

In a real P2P case, this change makes even more sense, because the addresses of 
the servers are unimportant -- as you said, it's the databases and their data 
that are the important thing. A UUID helps identify those.

 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

[jira] [Commented] (COUCHDB-1259) Replication ID is not stable if local server has a dynamic port number

[
https://issues.apache.org/jira/browse/COUCHDB-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13490424#comment-13490424
]

Benoit Chesneau commented on COUCHDB-1259:
--

I don't. The replication is fundamentally a peer to peer protocol. or master to
master. whatever.

It is and should be expected that a node can disappear for many reasons.
Relying on a server id is one of the possibilities to restart automatically a
replication, other would use other parameters based on the ip and the location,
etc... It is the responsibility of the application to know that. As a protocol
the replication shouldn't force this way imo. As a client the replicator
shouldn't too. It is already doing the best effort imo: ie restarting for the
same ip, port and properties of the replication.

As a side note, this is one of the reason the 0 port could be used here instead
of letting your *application* fix a port. 0 won't change. And you could rely
with the *application* on a unique property in the replication properties.

Replication ID is not stable if local server has a dynamic port number
--

Attachments: couchdb-1259.patch, couchdb-1259.patch

[jira] [Commented] (COUCHDB-1259) Replication ID is not stable if local server has a dynamic port number

[
https://issues.apache.org/jira/browse/COUCHDB-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13490427#comment-13490427
]

Jens Alfke commented on COUCHDB-1259:
-

It is the responsibility of the application to know that. As a protocol the
replication shouldn't force this way imo.

Then how does the application do this? I haven't seen any API for it.

Also, I don't see how this has anything to do with the case of a leaf node
running a server that happens to have a dynamic port assignment. The port this
node is running on has absolutely nothing to do with the replication. In the
(now obsolete) case of Couchbase Mobile, the server doesn't even accept
external requests, so its port number is purely an internal affair.

I still have a feeling that we're talking about completely different things.
But I can't really figure out what your point is...

Replication ID is not stable if local server has a dynamic port number
--

Attachments: couchdb-1259.patch, couchdb-1259.patch

[jira] [Commented] (COUCHDB-1259) Replication ID is not stable if local server has a dynamic port number

[
https://issues.apache.org/jira/browse/COUCHDB-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13490433#comment-13490433
]

Benoit Chesneau commented on COUCHDB-1259:
--

We don't speak about different things. We are expecting different behaviours
however.

If you have a dynamic port assignment then how knows the other node the new
port ? There are no other way than a ping-pong here. Ping-Pong that can be done
in different manner. To know this new port you will have to update the
replicator doc. Or the replication client could check on an adress table etc...
In any case there will be a dialog that can be different across applications.
And this is the point, this part is generally the logic of the application or
the routing policy. A server id can be use as an adress point but some could
decide to use other parameters to associate this replication id to a node.

Maybe instead of relying on a fixed node id, we could however introduce an
arbitrary remote id. This remote ID would be associated by default to an host
, port. The layer assigning this address id to the host/port could be
switchable, so the application or user could introduce easily its own routing
policy. Which could be relying on a server id ? Eventually if there is an
interrest like we do for the auth handlers or uuid generators, we could have
different implementations shipped with couchdb. One for example relying on a
server id.

btw your example with couchbase mobile is generally solved by using the
replication in pull mode only. So here it is relying on a fixed address to
replicate. A central node is then used as a meeting point for all the data
coming from other nodes and the replication is filtered per nodes.

Replication ID is not stable if local server has a dynamic port number
--

Attachments: couchdb-1259.patch, couchdb-1259.patch

[jira] [Commented] (COUCHDB-1259) Replication ID is not stable if local server has a dynamic port number

[
https://issues.apache.org/jira/browse/COUCHDB-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13490441#comment-13490441
]

Jens Alfke commented on COUCHDB-1259:
-

btw your example with couchbase mobile is generally solved by using the
replication in pull mode only. So here it is relying on a fixed address to
replicate.

*sigh* No, that is exactly the situation I was describing. The mobile client is
the only one initiating replication; it pulls from the central (fixed-address)
server, and pushes changes to it. So the mobile device's IP address and port
are irrelevant, right? Except that the replication state document stored in
_local has an ID based on several things _including_ the local server's address
and port number. So the effect is that, every time the app launches, all the
replication state gets lost/invalidated, and it has to start over again the
next time it replicates.

TouchDB doesn't have this problem because I didn't write it with this design
flaw :) Instead every local database has a UUID as suggested here, and that's
used as part of the key.

Replication ID is not stable if local server has a dynamic port number
--

Attachments: couchdb-1259.patch, couchdb-1259.patch

[jira] [Commented] (COUCHDB-1259) Replication ID is not stable if local server has a dynamic port number

[
https://issues.apache.org/jira/browse/COUCHDB-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13490444#comment-13490444
]

Benoit Chesneau commented on COUCHDB-1259:
--

Except if you are using either the same port on each devices (which is
generally what does an application) or the ephemeral port 0 which is also the
same then for reach replication. Also in that case you will also have to handle
the full address change and security implications. Relying on a unique ids to
continue the replication may be a design flaw or at least a non expected/wanted
behaviour. What will prevents an hostile node to connect back to your node with
the same id? How do you invalidate it?

I am pretty sure anyway we should let to the application or final user the
choice of the routing policy. I will have a patch for that later in the day.

Replication ID is not stable if local server has a dynamic port number
--

Attachments: couchdb-1259.patch, couchdb-1259.patch

[jira] [Commented] (COUCHDB-1259) Replication ID is not stable if local server has a dynamic port number

[
https://issues.apache.org/jira/browse/COUCHDB-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13490448#comment-13490448
]

Jens Alfke commented on COUCHDB-1259:
-

It seems like overkill to get the IANA to assign a fixed port number to an app
that doesn't even listen on any external interfaces! The only use of that port
is (was) over the loopback interface to let the application communicate with
CouchDB.

Passing zero for the port in the config file didn't make the problem go away.
Apparently the replicator bases the ID on the actual random port number in use,
not on the fixed 0 from the config.

What will prevents an hostile node to connect back to your node with the same
id?

Hello, are you listening at all to what I'm writing? I've already said several
times that the app does not accept incoming connections at all. It only makes
outgoing connections to replicate.

And in general: obviously in any real P2P app there would be actual security
measures in place to authenticate connections, most likely by using both server
and client SSL certs and verifying their public keys. Once the connection is
made, _then_ database IDs can be used to restore the state of a replication.

Replication ID is not stable if local server has a dynamic port number
--

Attachments: couchdb-1259.patch, couchdb-1259.patch

[jira] [Commented] (COUCHDB-1259) Replication ID is not stable if local server has a dynamic port number

[
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
--

Attachments: couchdb-1259.patch, couchdb-1259.patch

Re: [jira] [Commented] (COUCHDB-1259) Replication ID is not stable if local server has a dynamic port number

2012-11-04 Thread Dale Harvey

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
--

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

[jira] [Commented] (COUCHDB-1259) Replication ID is not stable if local server has a dynamic port number

2012-11-04 Thread Dustin Sallings (JIRA)


[ 
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:
--

If this is true, it explains why someone pointed me to this bug for the two 
issues I've been experiencing with replication:

1. My permanent replication sessions die almost every single day and come back 
after I restart CouchDB.
2. Sometimes I end up with more than one replication running for the same 
configured replica.

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.

 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

2012-11-04 Thread Dustin Sallings

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

2012-11-04 Thread Dustin Sallings

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

2012-11-04 Thread Dustin Sallings

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: wiki main page needs to be ported to website one page

On 5 November 2012 03:24, john.tiger john.tigernas...@gmail.com wrote:
 building from source is always a good refresher in using the documentation -
 in my case, it meant going to the web site.   Er, sorry, the web site really
 sucks, really bad.  Cant' find anything. The one page idea is actually nice
 but the content is totally useless.

 But I did manage to find the wiki - the main wiki page is excellent - it's
 exactly what the web site should be.  btw the install instructions on the
 wiki for linux are very good and easy to follow - kudos to whoever wrote it.
 One addition might be a reminder to remove any system package that might be
 installed (some of us need that) - and maybe a note about the dev test

 I saw some discussion re the one page but wasn't following it.  Are there
 plans to port the main wiki page over to the web site ?  is someone already
 doing that or does it need help ? or does someone actually think the website
 is good as is ?

Hi John,

I'd thought post 1.3 of slowly migrating much of the wiki content into
.rst format and the source tree. A lot of the wiki info is related to
older versions, having it stored in git means:

- we can remove the non-current information
- make it available through the website as a link to 0.11.0 or whatever

And yes, it does need help.

The one-page website is ideal as a sales story but we should make it
simpler / easier to find other stuff.

Building from source is one of those things that is a massive hurdle
the first few times you try it, then embarassingly obvious later on,
so one forgets what is important.  Even just adding your roadblocks
into a jira ticket will help enormously in reminding us what needs to
be fixed.

A+
Dave

[jira] [Commented] (COUCHDB-1591) CouchDB crashes on startup on OS X with a space in the an added .ini path


[ 
https://issues.apache.org/jira/browse/COUCHDB-1591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13490489#comment-13490489
 ] 

Benoit Chesneau commented on COUCHDB-1591:
--

I made some tests and the problem isn't in Erlang but in the couch shell 
script. 

$start_argument get:`/Users/benoitc/work/couchdb/etc/couchdb/default_dev.ini 
/Users/benoitc/work/couchdb/etc/couchdb/local_dev.ini ~/Library/Application'

and couch:

 [/Users/benoitc/work/couchdb/etc/couchdb/default_dev.ini,
  /Users/benoitc/work/couchdb/etc/couchdb/local_dev.ini,
  /Users/benoitc/Library/Application]

After passing $@ to the  `parse_script_option_list` function and then getopt 
allows me to run the following command:

   ./utils/run -a '~/Library/Application\ Support/test.ini'

Note the ' in the string. Then on the erlang side the lists of ini is:

  [/Users/benoitc/work/couchdb/etc/couchdb/default_dev.ini,
  /Users/benoitc/work/couchdb/etc/couchdb/local_dev.ini,
  /Users/benoitc/Library/Application Support/test.ini]

 CouchDB crashes on startup on OS X with a space in the an added .ini path
 -

 Key: COUCHDB-1591
 URL: https://issues.apache.org/jira/browse/COUCHDB-1591
 Project: CouchDB
  Issue Type: Bug
  Components: Database Core
Affects Versions: 1.2, 1.3
Reporter: Benoit Chesneau
Priority: Blocker

 Passing a path with a space in it doesn't work .
 Ticket created after ml discussion here:
 http://mail-archives.apache.org/mod_mbox/couchdb-user/201211.mbox/browser

--
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 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