Re: Hosting own CouchDB servers, scaling, and failover
On 14 November 2012 00:29, Joey Samonte dyowe...@yahoo.com wrote: Good day, Pardon me for my email, but I was hoping to get some guidance if I wanted to host my own CouchDB servers and how to handle scaling/failover. I'm working for a small company and it seems that Cloudant subscription would be too expensive in the long run. I created an app to allow users to save data locally if offline, and replicate when online. Thank you very much. Regards, Jose Samonte Hi Jose, I've set subsequent replies to user@ as its more appropriate. You'll need to consider whether the perceived costs matches the actual effort you need to expend to keep your servers app up and running yourselves. In particular 7x24 support, bug fixes, robust SSL, scaling, multi-site failover etc etc, learning what you need to know to maintain couchdb. That said, you'll first want to be able to: - build erlang + couchdb + spidermonkey from source use either https://github.com/iriscouch/build-couchdb or refer to wiki http://wiki.apache.org/couchdb/Installation for your platform - implement an SSL layer on top with load balancing and front end proxies e.g. stunnel haproxy nginx apache2 or a custom node proxy there are a couple of discussions on this in the list archives already http://web.archiveorange.com/archive/project/couchdb.apache.org - monitor, manage maintain all of those in production, 7x24. If you do go down this path, we'd love to see what you come up with hopefully get some more information on wiki about the steps required! A+ Dave
Re: Hosting own CouchDB servers, scaling, and failover
Hi Jose, You may also want to take a look at BigCouch: https://github.com/cloudant/bigcouch It might address your needs and the price is right, Bob On Nov 13, 2012, at 6:29 PM, Joey Samonte dyowe...@yahoo.com wrote: Good day, Pardon me for my email, but I was hoping to get some guidance if I wanted to host my own CouchDB servers and how to handle scaling/failover. I'm working for a small company and it seems that Cloudant subscription would be too expensive in the long run. I created an app to allow users to save data locally if offline, and replicate when online. Thank you very much. Regards, Jose Samonte
Re: git commit: Ensure uuid is generated before port is bound
On Nov 14, 2012, at 11:34 , rnew...@apache.org wrote: Updated Branches: refs/heads/1259-stable_replication_ids dbd1e19e0 - ae798352d (forced update) +1 to get this merged into master 1.3.x as is. Cheers Jan -- Ensure uuid is generated before port is bound Project: http://git-wip-us.apache.org/repos/asf/couchdb/repo Commit: http://git-wip-us.apache.org/repos/asf/couchdb/commit/ae798352 Tree: http://git-wip-us.apache.org/repos/asf/couchdb/tree/ae798352 Diff: http://git-wip-us.apache.org/repos/asf/couchdb/diff/ae798352 Branch: refs/heads/1259-stable_replication_ids Commit: ae798352d1aad67355bfee6828d9ddd0546591c4 Parents: 39fe998 Author: Robert Newson rnew...@apache.org Authored: Wed Nov 14 10:31:00 2012 + Committer: Robert Newson rnew...@apache.org Committed: Wed Nov 14 10:34:39 2012 + -- src/couchdb/couch_httpd.erl |4 1 files changed, 4 insertions(+), 0 deletions(-) -- http://git-wip-us.apache.org/repos/asf/couchdb/blob/ae798352/src/couchdb/couch_httpd.erl -- diff --git a/src/couchdb/couch_httpd.erl b/src/couchdb/couch_httpd.erl index 3774b85..ba28ffd 100644 --- a/src/couchdb/couch_httpd.erl +++ b/src/couchdb/couch_httpd.erl @@ -128,6 +128,10 @@ start_link(Name, Options) - set_auth_handlers(), +% ensure uuid is set so that concurrent replications +% get the same value. +couch_server:get_uuid(), + Loop = fun(Req)- case SocketOptions of [] -
couchdb pull request: 1259 stable replication ids
Github user rnewson closed the pull request at: https://github.com/apache/couchdb/pull/35
Re: git commit: Use local UUID instead of local host:port
+1 for 1.3
On Wed, Nov 14, 2012 at 11:07 AM, rnew...@apache.org wrote:
Updated Branches:
refs/heads/1259-stable_replication_ids fd96a01d0 - 39fe99825 (forced
update)
Use local UUID instead of local host:port
Project: http://git-wip-us.apache.org/repos/asf/couchdb/repo
Commit: http://git-wip-us.apache.org/repos/asf/couchdb/commit/39fe9982
Tree: http://git-wip-us.apache.org/repos/asf/couchdb/tree/39fe9982
Diff: http://git-wip-us.apache.org/repos/asf/couchdb/diff/39fe9982
Branch: refs/heads/1259-stable_replication_ids
Commit: 39fe998257a5f29b264c7632c75c2aafc6da5892
Parents: da7636f
Author: Robert Newson rnew...@apache.org
Authored: Wed Nov 14 09:59:50 2012 +
Committer: Robert Newson rnew...@apache.org
Committed: Wed Nov 14 09:59:50 2012 +
--
src/couch_replicator/src/couch_replicator.hrl |2 +-
.../src/couch_replicator_utils.erl |6 ++
2 files changed, 7 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/couchdb/blob/39fe9982/src/couch_replicator/src/couch_replicator.hrl
--
diff --git a/src/couch_replicator/src/couch_replicator.hrl
b/src/couch_replicator/src/couch_replicator.hrl
index 20c0bc3..018aa4b 100644
--- a/src/couch_replicator/src/couch_replicator.hrl
+++ b/src/couch_replicator/src/couch_replicator.hrl
@@ -10,7 +10,7 @@
% License for the specific language governing permissions and limitations
under
% the License.
--define(REP_ID_VERSION, 2).
+-define(REP_ID_VERSION, 3).
-record(rep, {
id,
http://git-wip-us.apache.org/repos/asf/couchdb/blob/39fe9982/src/couch_replicator/src/couch_replicator_utils.erl
--
diff --git a/src/couch_replicator/src/couch_replicator_utils.erl
b/src/couch_replicator/src/couch_replicator_utils.erl
index 4679321..d7778db 100644
--- a/src/couch_replicator/src/couch_replicator_utils.erl
+++ b/src/couch_replicator/src/couch_replicator_utils.erl
@@ -59,6 +59,12 @@ replication_id(#rep{options = Options} = Rep) -
% If a change is made to how replications are identified,
% please add a new clause and increase ?REP_ID_VERSION.
+replication_id(#rep{user_ctx = UserCtx} = Rep, 3) -
+UUID = couch_server:get_uuid(),
+Src = get_rep_endpoint(UserCtx, Rep#rep.source),
+Tgt = get_rep_endpoint(UserCtx, Rep#rep.target),
+maybe_append_filters([UUID, Src, Tgt], Rep);
+
replication_id(#rep{user_ctx = UserCtx} = Rep, 2) -
{ok, HostName} = inet:gethostname(),
Port = case (catch mochiweb_socket_server:get(couch_httpd, port)) of
[jira] [Resolved] (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:all-tabpanel
]
Robert Newson resolved COUCHDB-1259.
Resolution: Fixed
The basic version is committed (where we use UUID instead of the local
hostname:port).
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-1368) multipart/related document body doesn't identify which part is which attachment
[ https://issues.apache.org/jira/browse/COUCHDB-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497106#comment-13497106 ] Jan Lehnardt commented on COUCHDB-1368: --- Fixed in the branch: 1368-fix-multipart-header-parts I’d love a review. multipart/related document body doesn't identify which part is which attachment --- Key: COUCHDB-1368 URL: https://issues.apache.org/jira/browse/COUCHDB-1368 Project: CouchDB Issue Type: Bug Components: HTTP Interface Reporter: Jens Alfke Assignee: Damien Katz Priority: Minor If you GET a document with attachments in multipart/related format (by adding ?attachments=true and setting Accept:multipart/related), the MIME bodies for the attachments have no headers. This makes it difficult to tell which one is which. Damien says they're in the same order that they appear in the document's _attachments object ... which is fine if you're Erlang, because Erlang preserves the order of keys in a JSON object, but no other JSON implementation I know of does that (because they use hashtables instead of linked lists.) The upshot is that any non-Erlang code trying to parse such a response will have to do some by-hand parsing of the JSON data to get the _attachment keys in order. This can be fixed by adding a Content-ID header to each attachment body, whose value is the filename. It would be nice if other standard headers were added too, like Content-Type, Content-Length, Content-Encoding, as this would make it work better with existing MIME multipart libraries. -- 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-1368) multipart/related document body doesn't identify which part is which attachment
[ https://issues.apache.org/jira/browse/COUCHDB-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt updated COUCHDB-1368: -- Assignee: (was: Damien Katz) multipart/related document body doesn't identify which part is which attachment --- Key: COUCHDB-1368 URL: https://issues.apache.org/jira/browse/COUCHDB-1368 Project: CouchDB Issue Type: Bug Components: HTTP Interface Reporter: Jens Alfke Priority: Minor If you GET a document with attachments in multipart/related format (by adding ?attachments=true and setting Accept:multipart/related), the MIME bodies for the attachments have no headers. This makes it difficult to tell which one is which. Damien says they're in the same order that they appear in the document's _attachments object ... which is fine if you're Erlang, because Erlang preserves the order of keys in a JSON object, but no other JSON implementation I know of does that (because they use hashtables instead of linked lists.) The upshot is that any non-Erlang code trying to parse such a response will have to do some by-hand parsing of the JSON data to get the _attachment keys in order. This can be fixed by adding a Content-ID header to each attachment body, whose value is the filename. It would be nice if other standard headers were added too, like Content-Type, Content-Length, Content-Encoding, as this would make it work better with existing MIME multipart libraries. -- 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-1368) multipart/related document body doesn't identify which part is which attachment
[ https://issues.apache.org/jira/browse/COUCHDB-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497240#comment-13497240 ] Jens Alfke commented on COUCHDB-1368: - Where is the branch? I don't see it in the github UI at https://github.com/apache/couchdb . Also, could you post a sample of what the MIME headers look like for an attachment part? multipart/related document body doesn't identify which part is which attachment --- Key: COUCHDB-1368 URL: https://issues.apache.org/jira/browse/COUCHDB-1368 Project: CouchDB Issue Type: Bug Components: HTTP Interface Reporter: Jens Alfke Priority: Minor If you GET a document with attachments in multipart/related format (by adding ?attachments=true and setting Accept:multipart/related), the MIME bodies for the attachments have no headers. This makes it difficult to tell which one is which. Damien says they're in the same order that they appear in the document's _attachments object ... which is fine if you're Erlang, because Erlang preserves the order of keys in a JSON object, but no other JSON implementation I know of does that (because they use hashtables instead of linked lists.) The upshot is that any non-Erlang code trying to parse such a response will have to do some by-hand parsing of the JSON data to get the _attachment keys in order. This can be fixed by adding a Content-ID header to each attachment body, whose value is the filename. It would be nice if other standard headers were added too, like Content-Type, Content-Length, Content-Encoding, as this would make it work better with existing MIME multipart libraries. -- 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-1368) multipart/related document body doesn't identify which part is which attachment
[
https://issues.apache.org/jira/browse/COUCHDB-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497290#comment-13497290
]
Jan Lehnardt commented on COUCHDB-1368:
---
The main CouchDB repo lives here:
https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=summary
Branches are not mirrored to GitHub at this point (sorry), but I pushed it to
my fork:
https://github.com/janl/couchdb/tree/1368-fix-multipart-header-parts.
The commit in question:
https://github.com/janl/couchdb/commit/18971de71c93c3a00e408b3d4eb67be8c695150c
Here’s a request dump:
curl -Nv $COUCH/test/asd?attachments=true -H Accept: multipart/related,*/*;
* About to connect() to 127.0.0.1 port 5984 (#0)
* Trying 127.0.0.1...
* connected
* Connected to 127.0.0.1 (127.0.0.1) port 5984 (#0)
GET /test/asd?attachments=true HTTP/1.1
User-Agent: curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0
OpenSSL/0.9.8r zlib/1.2.5
Host: 127.0.0.1:5984
Accept: multipart/related,*/*;
HTTP/1.1 200 OK
Server: CouchDB/1.3.0a-b9af7ea-git (Erlang OTP/R15B02)
ETag: 9-4310e4b1fcab6822344790d37fb5ddea
Date: Wed, 14 Nov 2012 18:04:57 GMT
Content-Type: multipart/related; boundary=a38b2d614bb2a8d70e31050a0e2e11a5
Content-Length: 493
--a38b2d614bb2a8d70e31050a0e2e11a5
content-type: application/json
{_id:asd,_rev:9-4310e4b1fcab6822344790d37fb5ddea,foo:var,_attachments:{test.txt:{content_type:text/plain,revpos:8,digest:md5-7xbQv30HNBSgLpMDsQTH7A==,length:12,follows:true,encoding:gzip,encoded_length:30}}}
--a38b2d614bb2a8d70e31050a0e2e11a5
Content-ID: test.txt
Content-Type: text/plain
Content-Length: 30
Content-Transfer-Encoding: gzip
K??WHJ,?*.?5?
--a38b2
The closing boundary is off, I seem to have a bug in the main request’s
Content-Length calculation, but this is the direction this is going.
multipart/related document body doesn't identify which part is which
attachment
---
Key: COUCHDB-1368
URL: https://issues.apache.org/jira/browse/COUCHDB-1368
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Reporter: Jens Alfke
Priority: Minor
If you GET a document with attachments in multipart/related format (by adding
?attachments=true and setting Accept:multipart/related), the MIME bodies for
the attachments have no headers. This makes it difficult to tell which one is
which. Damien says they're in the same order that they appear in the
document's _attachments object ... which is fine if you're Erlang, because
Erlang preserves the order of keys in a JSON object, but no other JSON
implementation I know of does that (because they use hashtables instead of
linked lists.)
The upshot is that any non-Erlang code trying to parse such a response will
have to do some by-hand parsing of the JSON data to get the _attachment keys
in order.
This can be fixed by adding a Content-ID header to each attachment body,
whose value is the filename. It would be nice if other standard headers were
added too, like Content-Type, Content-Length, Content-Encoding, as this
would make it work better with existing MIME multipart libraries.
--
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-1368) multipart/related document body doesn't identify which part is which attachment
[ https://issues.apache.org/jira/browse/COUCHDB-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497301#comment-13497301 ] Jan Lehnardt commented on COUCHDB-1368: --- And fixed. I’ve updated the branches. multipart/related document body doesn't identify which part is which attachment --- Key: COUCHDB-1368 URL: https://issues.apache.org/jira/browse/COUCHDB-1368 Project: CouchDB Issue Type: Bug Components: HTTP Interface Reporter: Jens Alfke Priority: Minor If you GET a document with attachments in multipart/related format (by adding ?attachments=true and setting Accept:multipart/related), the MIME bodies for the attachments have no headers. This makes it difficult to tell which one is which. Damien says they're in the same order that they appear in the document's _attachments object ... which is fine if you're Erlang, because Erlang preserves the order of keys in a JSON object, but no other JSON implementation I know of does that (because they use hashtables instead of linked lists.) The upshot is that any non-Erlang code trying to parse such a response will have to do some by-hand parsing of the JSON data to get the _attachment keys in order. This can be fixed by adding a Content-ID header to each attachment body, whose value is the filename. It would be nice if other standard headers were added too, like Content-Type, Content-Length, Content-Encoding, as this would make it work better with existing MIME multipart libraries. -- 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: [REL1.3.0] CouchDB Windows / OS X packages (Progress?)
Hi all, I am unable to make today's meeting so I wanted to give a status update. I've resurrected my work on packaging CouchDB using WiX for Win32. I also have recently written new BigCouch wrappers for rpm and deb and am happy to help get these done up for CouchDB. What I'm looking for is an interested committer (dch? tilgovi?) who is willing to work with me to help get these patches landed on the tree. My goal specifically would be: 1. Get all of the bits necessary to build packages into the repo, possibly using downstream distro bits as a starting point for deb/rpm 2. Ensure that the bits work 3. Consult with our downstream distros for any changes they'd like to see in our repo directly 4. profit, etc. Noah, what is the hard cutoff date for changing the repo? Would there be any leeway to change only things that affect the build process/packaging instead of the code itself? -Joan On Sat, Nov 03, 2012 at 07:04:09PM +, Noah Slater wrote: Hey guys! What's the current status of the build/packaging work? Would LOVE to get some of this done for 1.3! g On 29 October 2012 17:58, Benoit Chesneau bchesn...@gmail.com wrote: i can probably help as well. rcouchx is using a simple makefile but that can be ported to autools imo On Oct 29, 2012 6:51 PM, Noah Slater nsla...@apache.org wrote: Cooll, appreciate that! Hoping to get some of this sorted for 1.3, which is largely dependant on me fixing up these docs. I think our biggest concern right now is the OS X thing. I am not at all happy with it being on Github, but over the moon it exists in the first place. If we could get some movement on this, even if it's just a tiny bit, in the right direction, then I would be overjoyed. On 29 October 2012 15:24, Joan Touzet woh...@gmail.com wrote: Hi Noah, I'm just climbing out of the hole at work today, so I'll be able to look at this tomorrow (Tuesday the 30th). -Joan --- Joan Touzet | jo...@ieee.org | wohali@efnet On 28 October 2012 11:53, Noah Slater nsla...@apache.org wrote: Hey Hans, What changes do we need to make to get this into CouchDB proper? Do you need any assistance? Thanks! On 24 October 2012 23:25, Hans J Schroeder h...@cloudno.de wrote: Hi Noah, At my side the required changes are not yet ready. - Hans On Oct 23, 2012, at 12:26 PM, Noah Slater nsla...@apache.org wrote: Just following up on this. CCing Hans and Joan directly. On 14 October 2012 19:49, Noah Slater nsla...@tumbolia.org wrote: Do you think we can get this AMI ready for the 1.3 release? @Hans, do you wanna take a look at what it would take to fold your work in? I'm sure Dave or myself can answer any questions you run in to. @Joan, how long would the MSI stuff take? On Sun, Oct 14, 2012 at 7:45 PM, Dave Cottlehuber d...@jsonified.com wrote: On 14 October 2012 12:27, Noah Slater nsla...@tumbolia.org wrote: Hey, This is the first of several What's up with releasing 1.3? emails. (See subject prefix!) I wanted to start a discussion around our Windows and OS X packages. At the moment, our OS X package is hosted on Github, which we need to fix. What can we do to get this package into the source, and maybe iterate on it a little? And are there any improvements we can make to our Windows package for this release? Any volunteers to head up these efforts? Anybody who wants to help here is welcome :-) I am mid updating the public AMI I use for test builds, to include an R15B02 OTP instead of the R15B I have. That avoids the need for people to spend ages getting a dev environment set up. @Wohali has some bits to make an MSI package, better than my hacky attempts a year ago. That would be cool. I'm gonna revert to using a newer OpenSSL library if it works out in testing. Nothing else major comes to mind down here. A+ Dave -- NS -- NS -- NS -- NS -- NS -- Joan Touzet | jo...@atypical.net | wohali everywhere else
[jira] [Created] (COUCHDB-1604) update ibrowse to 4.0.1
Jan Lehnardt created COUCHDB-1604: - Summary: update ibrowse to 4.0.1 Key: COUCHDB-1604 URL: https://issues.apache.org/jira/browse/COUCHDB-1604 Project: CouchDB Issue Type: Dependency upgrade Reporter: Jan Lehnardt This update ibrowse to 4.0.1 Branch: 1603-update-ibrowse make check works for me, but this should probably get a more thorough review. Filipe? -- 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-1604) update ibrowse to 4.0.1
[ https://issues.apache.org/jira/browse/COUCHDB-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt updated COUCHDB-1604: -- Description: This update ibrowse to 4.0.1 Branch: 1604-update-ibrowse-4-0-1 make check works for me, but this should probably get a more thorough review. Filipe? was: This update ibrowse to 4.0.1 Branch: 1603-update-ibrowse make check works for me, but this should probably get a more thorough review. Filipe? update ibrowse to 4.0.1 --- Key: COUCHDB-1604 URL: https://issues.apache.org/jira/browse/COUCHDB-1604 Project: CouchDB Issue Type: Dependency upgrade Reporter: Jan Lehnardt This update ibrowse to 4.0.1 Branch: 1604-update-ibrowse-4-0-1 make check works for me, but this should probably get a more thorough review. Filipe? -- 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-1581) Update bundled dependencies
[ https://issues.apache.org/jira/browse/COUCHDB-1581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497360#comment-13497360 ] Jan Lehnardt commented on COUCHDB-1581: --- ibrowse: COUCHDB-1604 Update bundled dependencies --- Key: COUCHDB-1581 URL: https://issues.apache.org/jira/browse/COUCHDB-1581 Project: CouchDB Issue Type: Improvement Reporter: Jan Lehnardt Assignee: Jan Lehnardt Priority: Blocker Fix For: 1.3 We should check which dependencies are due for an update: - ibrowse - mochiweb - jQuery - snappy - erlang-oauth // please add the ones I missed in comments here. -- 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-1581) Update bundled dependencies
[ https://issues.apache.org/jira/browse/COUCHDB-1581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497370#comment-13497370 ] Jan Lehnardt commented on COUCHDB-1581: --- In hindsight, none of these seem blocking for 1.3.x. Happy to merge them into master, though. Update bundled dependencies --- Key: COUCHDB-1581 URL: https://issues.apache.org/jira/browse/COUCHDB-1581 Project: CouchDB Issue Type: Improvement Reporter: Jan Lehnardt Assignee: Jan Lehnardt Priority: Blocker Fix For: 1.3 We should check which dependencies are due for an update: - ibrowse - mochiweb - jQuery - snappy - erlang-oauth // please add the ones I missed in comments here. -- 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-1605) Fail to Add Document to _replicator
Fabrício Dias created COUCHDB-1605:
--
Summary: Fail to Add Document to _replicator
Key: COUCHDB-1605
URL: https://issues.apache.org/jira/browse/COUCHDB-1605
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.2
Environment: uname -a
Linux SPOUOLSRV17 2.6.39-200.32.1.el6uek.x86_64 #1 SMP Wed Sep 26 23:11:38 PDT
2012 x86_64 x86_64 x86_64 GNU/Linux
curl -X GET http://admin:n3ts3rv1c0s@127.0.0.1:5984;
{couchdb:Welcome,version:1.2.0}
### SETUP - JS 1.8.5
yum install -y wget gcc-c++ autoconf213 zip
cd /tmp
wget http://ftp.mozilla.org/pub/mozilla.org/js/js185-1.0.0.tar.gz
tar xvf js185-1.0.0.tar.gz
cd /tmp/js-1.8.5/js/src
autoconf-2.13
./configure
make make install
SETUP - CouchDB
yum install -y gcc autoconf automake make libicu-devel curl-devel erlang
erlang-ibrowse erlang-mochiweb erlang-oauth openssl-devel libtool which
cd /tmp
wget
http://apache.mirror.pop-sc.rnp.br/apache/couchdb/releases/1.2.0/apache-couchdb-1.2.0.tar.gz
tar zxfv apache-couchdb-1.2.0.tar.gz
cd /tmp/apache-couchdb-1.2.0
./configure --prefix=/opt --with-erlang=/usr/lib64/erlang/usr/include
--with-js-lib=/usr/local/lib/ --with-js-include=/usr/local/include/js/
make make install
START - CouchDB
ln -s /opt/etc/rc.d/couchdb /etc/init.d/couchdb;
chkconfig --add couchdb;
chkconfig --level 345 couchdb on;
service couchdb stop;
sleep 3;
service couchdb start;
sleep 3;
curl -X GET http://admin:n3ts3rv1c0s@127.0.0.1:5984/;
{couchdb:Welcome,version:1.2.0}
Reporter: Fabrício Dias
Priority: Critical
# Now I try to create a replica:
[root@ORALNX couchdb]# curl -X GET
http://admin:password@127.0.0.1:5984/syd_global_couchapp;
{db_name:syd_global_couchapp,doc_count:3,doc_del_count:0,update_seq:4,purge_seq:0,compact_running:false,disk_size:2379878,data_size:2358489,instance_start_time:1352921020564400,disk_format_version:6,committed_update_seq:4}
[root@ORALNX couchdb]# curl -X POST
http://admin:password@127.0.0.1:5984/_replicator -H content-type:
application/json -d \
'{
_id:reply1,
source:syd_global_couchapp,
target:syd_global_couchapp_copy,
create_target:true,
continuous:true
}';
{error:{bad_return_value,{os_process_error,{exit_status,127}}},reason:{gen_server,call,
[couch_query_servers,
{get_proc,{doc,\_design/_replicator\,
{7,
[63,207,130,209,42,66,129,178,15,48,222,32,110,
60,239,52,
124,51,106,90,72,50,181,32,225,86,125,33,30,34,
213,185,
115,129,44,182,171,22,108,111,73,61,111,140,98,
211,86,183,
19,237,37,141,211,255,51,86,82,227,32,169,66,
75,147,202,
124,39,146,76,233,174,78,63,55,135,118,148,221,
110,241,51,
141,251,167,195,125,83,96,188,172,13,211,92,
251,86,210,229,
91,250,44,153,238,254,43,46,180,150,45,181,
10,163,207,212]},
{[{\language\,\javascript\},
{\validate_doc_update\,
\
function(newDoc, oldDoc, userCtx) {
function reportError(error_msg) {
log('Error writing document `' + newDoc._id +
'' to the replicator database: ' + error_msg);
throw({forbidden: error_msg});
}
function validateEndpoint(endpoint, fieldName) {
if ((typeof endpoint !== 'string')
((typeof endpoint !== 'object') || (endpoint === null))) {
reportError('The `' + fieldName + '' property must exist' +
' and be either a string or an object.');
}
if (typeof endpoint === 'object') {
if ((typeof endpoint.url !== 'string') || !endpoint.url) {
reportError('The url property must exist in the `' +
fieldName + '' field and must be a non-empty
string.');
}
if ((typeof endpoint.auth !== 'undefined')
((typeof endpoint.auth !== 'object') ||
endpoint.auth === null)) {
reportError('`' + fieldName +
'.auth' must be a non-null object.');
}
if ((typeof endpoint.headers !== 'undefined')
((typeof endpoint.headers !== 'object') ||
endpoint.headers === null)) {
reportError('`' + fieldName +
'.headers' must be a non-null object.');
}
[jira] [Updated] (COUCHDB-1605) Fail to Add Document to _replicator
[
https://issues.apache.org/jira/browse/COUCHDB-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fabrício Dias updated COUCHDB-1605:
---
Environment:
uname -a
Linux ORALNX 2.6.39-200.32.1.el6uek.x86_64 #1 SMP Wed Sep 26 23:11:38 PDT 2012
x86_64 x86_64 x86_64 GNU/Linux
curl -X GET http://admin:password@127.0.0.1:5984;
{couchdb:Welcome,version:1.2.0}
### SETUP - JS 1.8.5
yum install -y wget gcc-c++ autoconf213 zip
cd /tmp
wget http://ftp.mozilla.org/pub/mozilla.org/js/js185-1.0.0.tar.gz
tar xvf js185-1.0.0.tar.gz
cd /tmp/js-1.8.5/js/src
autoconf-2.13
./configure
make make install
SETUP - CouchDB
yum install -y gcc autoconf automake make libicu-devel curl-devel erlang
erlang-ibrowse erlang-mochiweb erlang-oauth openssl-devel libtool which
cd /tmp
wget
http://apache.mirror.pop-sc.rnp.br/apache/couchdb/releases/1.2.0/apache-couchdb-1.2.0.tar.gz
tar zxfv apache-couchdb-1.2.0.tar.gz
cd /tmp/apache-couchdb-1.2.0
./configure --prefix=/opt --with-erlang=/usr/lib64/erlang/usr/include
--with-js-lib=/usr/local/lib/ --with-js-include=/usr/local/include/js/
make make install
START - CouchDB
ln -s /opt/etc/rc.d/couchdb /etc/init.d/couchdb;
chkconfig --add couchdb;
chkconfig --level 345 couchdb on;
service couchdb stop;
sleep 3;
service couchdb start;
sleep 3;
curl -X GET http://admin:password@127.0.0.1:5984/;
{couchdb:Welcome,version:1.2.0}
was:
uname -a
Linux SPOUOLSRV17 2.6.39-200.32.1.el6uek.x86_64 #1 SMP Wed Sep 26 23:11:38 PDT
2012 x86_64 x86_64 x86_64 GNU/Linux
curl -X GET http://admin:n3ts3rv1c0s@127.0.0.1:5984;
{couchdb:Welcome,version:1.2.0}
### SETUP - JS 1.8.5
yum install -y wget gcc-c++ autoconf213 zip
cd /tmp
wget http://ftp.mozilla.org/pub/mozilla.org/js/js185-1.0.0.tar.gz
tar xvf js185-1.0.0.tar.gz
cd /tmp/js-1.8.5/js/src
autoconf-2.13
./configure
make make install
SETUP - CouchDB
yum install -y gcc autoconf automake make libicu-devel curl-devel erlang
erlang-ibrowse erlang-mochiweb erlang-oauth openssl-devel libtool which
cd /tmp
wget
http://apache.mirror.pop-sc.rnp.br/apache/couchdb/releases/1.2.0/apache-couchdb-1.2.0.tar.gz
tar zxfv apache-couchdb-1.2.0.tar.gz
cd /tmp/apache-couchdb-1.2.0
./configure --prefix=/opt --with-erlang=/usr/lib64/erlang/usr/include
--with-js-lib=/usr/local/lib/ --with-js-include=/usr/local/include/js/
make make install
START - CouchDB
ln -s /opt/etc/rc.d/couchdb /etc/init.d/couchdb;
chkconfig --add couchdb;
chkconfig --level 345 couchdb on;
service couchdb stop;
sleep 3;
service couchdb start;
sleep 3;
curl -X GET http://admin:n3ts3rv1c0s@127.0.0.1:5984/;
{couchdb:Welcome,version:1.2.0}
Fail to Add Document to _replicator
---
Key: COUCHDB-1605
URL: https://issues.apache.org/jira/browse/COUCHDB-1605
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.2
Environment: uname -a
Linux ORALNX 2.6.39-200.32.1.el6uek.x86_64 #1 SMP Wed Sep 26 23:11:38 PDT
2012 x86_64 x86_64 x86_64 GNU/Linux
curl -X GET http://admin:password@127.0.0.1:5984;
{couchdb:Welcome,version:1.2.0}
### SETUP - JS 1.8.5
yum install -y wget gcc-c++ autoconf213 zip
cd /tmp
wget http://ftp.mozilla.org/pub/mozilla.org/js/js185-1.0.0.tar.gz
tar xvf js185-1.0.0.tar.gz
cd /tmp/js-1.8.5/js/src
autoconf-2.13
./configure
make make install
SETUP - CouchDB
yum install -y gcc autoconf automake make libicu-devel curl-devel erlang
erlang-ibrowse erlang-mochiweb erlang-oauth openssl-devel libtool which
cd /tmp
wget
http://apache.mirror.pop-sc.rnp.br/apache/couchdb/releases/1.2.0/apache-couchdb-1.2.0.tar.gz
tar zxfv apache-couchdb-1.2.0.tar.gz
cd /tmp/apache-couchdb-1.2.0
./configure --prefix=/opt --with-erlang=/usr/lib64/erlang/usr/include
--with-js-lib=/usr/local/lib/ --with-js-include=/usr/local/include/js/
make make install
START - CouchDB
ln -s /opt/etc/rc.d/couchdb /etc/init.d/couchdb;
chkconfig --add couchdb;
chkconfig --level 345 couchdb on;
service couchdb stop;
sleep 3;
service couchdb start;
sleep 3;
curl -X GET http://admin:password@127.0.0.1:5984/;
{couchdb:Welcome,version:1.2.0}
Reporter: Fabrício Dias
Priority: Critical
# Now I try to create a replica:
[root@ORALNX couchdb]# curl -X GET
http://admin:password@127.0.0.1:5984/syd_global_couchapp;
{db_name:syd_global_couchapp,doc_count:3,doc_del_count:0,update_seq:4,purge_seq:0,compact_running:false,disk_size:2379878,data_size:2358489,instance_start_time:1352921020564400,disk_format_version:6,committed_update_seq:4}
[root@ORALNX couchdb]# curl -X POST
http://admin:password@127.0.0.1:5984/_replicator -H content-type:
application/json -d \
'{
_id:reply1,
source:syd_global_couchapp,
target:syd_global_couchapp_copy,
create_target:true,
continuous:true
}';
[jira] [Commented] (COUCHDB-1605) Fail to Add Document to _replicator
[
https://issues.apache.org/jira/browse/COUCHDB-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497379#comment-13497379
]
Fabrício Dias commented on COUCHDB-1605:
I believe the fault is in the validation of the document _design /
_replicator but I can not identify the exact problem.
Fail to Add Document to _replicator
---
Key: COUCHDB-1605
URL: https://issues.apache.org/jira/browse/COUCHDB-1605
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.2
Environment: uname -a
Linux ORALNX 2.6.39-200.32.1.el6uek.x86_64 #1 SMP Wed Sep 26 23:11:38 PDT
2012 x86_64 x86_64 x86_64 GNU/Linux
curl -X GET http://admin:password@127.0.0.1:5984;
{couchdb:Welcome,version:1.2.0}
### SETUP - JS 1.8.5
yum install -y wget gcc-c++ autoconf213 zip
cd /tmp
wget http://ftp.mozilla.org/pub/mozilla.org/js/js185-1.0.0.tar.gz
tar xvf js185-1.0.0.tar.gz
cd /tmp/js-1.8.5/js/src
autoconf-2.13
./configure
make make install
SETUP - CouchDB
yum install -y gcc autoconf automake make libicu-devel curl-devel erlang
erlang-ibrowse erlang-mochiweb erlang-oauth openssl-devel libtool which
cd /tmp
wget
http://apache.mirror.pop-sc.rnp.br/apache/couchdb/releases/1.2.0/apache-couchdb-1.2.0.tar.gz
tar zxfv apache-couchdb-1.2.0.tar.gz
cd /tmp/apache-couchdb-1.2.0
./configure --prefix=/opt --with-erlang=/usr/lib64/erlang/usr/include
--with-js-lib=/usr/local/lib/ --with-js-include=/usr/local/include/js/
make make install
START - CouchDB
ln -s /opt/etc/rc.d/couchdb /etc/init.d/couchdb;
chkconfig --add couchdb;
chkconfig --level 345 couchdb on;
service couchdb stop;
sleep 3;
service couchdb start;
sleep 3;
curl -X GET http://admin:password@127.0.0.1:5984/;
{couchdb:Welcome,version:1.2.0}
Reporter: Fabrício Dias
Priority: Critical
# Now I try to create a replica:
[root@ORALNX couchdb]# curl -X GET
http://admin:password@127.0.0.1:5984/syd_global_couchapp;
{db_name:syd_global_couchapp,doc_count:3,doc_del_count:0,update_seq:4,purge_seq:0,compact_running:false,disk_size:2379878,data_size:2358489,instance_start_time:1352921020564400,disk_format_version:6,committed_update_seq:4}
[root@ORALNX couchdb]# curl -X POST
http://admin:password@127.0.0.1:5984/_replicator -H content-type:
application/json -d \
'{
_id:reply1,
source:syd_global_couchapp,
target:syd_global_couchapp_copy,
create_target:true,
continuous:true
}';
{error:{bad_return_value,{os_process_error,{exit_status,127}}},reason:{gen_server,call,
[couch_query_servers,
{get_proc,{doc,\_design/_replicator\,
{7,
[63,207,130,209,42,66,129,178,15,48,222,32,110,
60,239,52,
124,51,106,90,72,50,181,32,225,86,125,33,30,34,
213,185,
115,129,44,182,171,22,108,111,73,61,111,140,98,
211,86,183,
19,237,37,141,211,255,51,86,82,227,32,169,66,
75,147,202,
124,39,146,76,233,174,78,63,55,135,118,148,221,
110,241,51,
141,251,167,195,125,83,96,188,172,13,211,92,
251,86,210,229,
91,250,44,153,238,254,43,46,180,150,45,181,
10,163,207,212]},
{[{\language\,\javascript\},
{\validate_doc_update\,
\
function(newDoc, oldDoc, userCtx) {
function reportError(error_msg) {
log('Error writing document `' + newDoc._id +
'' to the replicator database: ' + error_msg);
throw({forbidden: error_msg});
}
function validateEndpoint(endpoint, fieldName) {
if ((typeof endpoint !== 'string')
((typeof endpoint !== 'object') || (endpoint === null))) {
reportError('The `' + fieldName + '' property must exist'
+
' and be either a string or an object.');
}
if (typeof endpoint === 'object') {
if ((typeof endpoint.url !== 'string') || !endpoint.url) {
reportError('The url property must exist in the `' +
fieldName + '' field and must be a non-empty
string.');
}
if ((typeof endpoint.auth !== 'undefined')
((typeof endpoint.auth !== 'object') ||
endpoint.auth === null)) {
reportError('`' +
Re: [HELP] GitHub issues clean-out help wanted!
On Nov 1, 2012, at 02:09 , Dave Cottlehuber d...@jsonified.com wrote: Hi folks, While we run towards 1.3.0 we have some hygiene to take care of: https://github.com/apache/couchdb/pulls Any volunteers to look through these GitHub issues and see where they need to go next? Comments and/or code both welcomed. 3. handle promises correctly in jquery.couch.js [STALLED] https://github.com/apache/couchdb/pull/3 4. support crossdomain.xml files [STALLED] https://github.com/apache/couchdb/pull/4 Merged. Waiting for PR close. 18. fix http header handling in list functions https://github.com/apache/couchdb/pull/18 Just needs a check, tidy up JS tests. Anybody? Merged. Waiting for PR close. 30. fix broken JS callbacks during login https://github.com/apache/couchdb/pull/30 https://github.com/mikeymckay/couchdb/commit/a324c2c96f0fc339d10a30a5e50ddf9a410e00ca Looks like it needs a check + some JS tests. Anybody? Nudged. 32. document id in headers https://github.com/apache/couchdb/pull/32 Looks like it needs a check + some JS tests. Anybody? Merged Closed. 33. how to remove old view files? https://github.com/apache/couchdb/pull/33 Already being dealt with in COUCHDB-1346 34. numerous $.couch fixes https://github.com/apache/couchdb/pull/34 Needs a couple of people to review. Anybody? Nudged, seems to be an accidentally messy PR. 38. extend rewriter to support generic functions https://github.com/apache/couchdb/pull/38 @benoitc @davisp can you comment? Last I heard this looks like a -1 from you both? Folks commented. Looks like a no-go, unless speed concerns are disproven.
Re: [REL1.3.0] CouchDB Windows / OS X packages (Progress?)
On 14 November 2012 19:34, Joan Touzet jo...@atypical.net wrote: Hi all, I am unable to make today's meeting so I wanted to give a status update. I've resurrected my work on packaging CouchDB using WiX for Win32. I also have recently written new BigCouch wrappers for rpm and deb and am happy to help get these done up for CouchDB. What I'm looking for is an interested committer (dch? tilgovi?) who is willing to work with me to help get these patches landed on the tree. My goal specifically would be: 1. Get all of the bits necessary to build packages into the repo, possibly using downstream distro bits as a starting point for deb/rpm 2. Ensure that the bits work 3. Consult with our downstream distros for any changes they'd like to see in our repo directly 4. profit, etc. Noah, what is the hard cutoff date for changing the repo? Would there be any leeway to change only things that affect the build process/packaging instead of the code itself? -Joan On Sat, Nov 03, 2012 at 07:04:09PM +, Noah Slater wrote: Hey guys! What's the current status of the build/packaging work? Would LOVE to get some of this done for 1.3! g On 29 October 2012 17:58, Benoit Chesneau bchesn...@gmail.com wrote: i can probably help as well. rcouchx is using a simple makefile but that can be ported to autools imo On Oct 29, 2012 6:51 PM, Noah Slater nsla...@apache.org wrote: Cooll, appreciate that! Hoping to get some of this sorted for 1.3, which is largely dependant on me fixing up these docs. I think our biggest concern right now is the OS X thing. I am not at all happy with it being on Github, but over the moon it exists in the first place. If we could get some movement on this, even if it's just a tiny bit, in the right direction, then I would be overjoyed. On 29 October 2012 15:24, Joan Touzet woh...@gmail.com wrote: Hi Noah, I'm just climbing out of the hole at work today, so I'll be able to look at this tomorrow (Tuesday the 30th). -Joan --- Joan Touzet | jo...@ieee.org | wohali@efnet On 28 October 2012 11:53, Noah Slater nsla...@apache.org wrote: Hey Hans, What changes do we need to make to get this into CouchDB proper? Do you need any assistance? Thanks! On 24 October 2012 23:25, Hans J Schroeder h...@cloudno.de wrote: Hi Noah, At my side the required changes are not yet ready. - Hans On Oct 23, 2012, at 12:26 PM, Noah Slater nsla...@apache.org wrote: Just following up on this. CCing Hans and Joan directly. On 14 October 2012 19:49, Noah Slater nsla...@tumbolia.org wrote: Do you think we can get this AMI ready for the 1.3 release? @Hans, do you wanna take a look at what it would take to fold your work in? I'm sure Dave or myself can answer any questions you run in to. @Joan, how long would the MSI stuff take? On Sun, Oct 14, 2012 at 7:45 PM, Dave Cottlehuber d...@jsonified.com wrote: On 14 October 2012 12:27, Noah Slater nsla...@tumbolia.org wrote: Hey, This is the first of several What's up with releasing 1.3? emails. (See subject prefix!) I wanted to start a discussion around our Windows and OS X packages. At the moment, our OS X package is hosted on Github, which we need to fix. What can we do to get this package into the source, and maybe iterate on it a little? And are there any improvements we can make to our Windows package for this release? Any volunteers to head up these efforts? Anybody who wants to help here is welcome :-) I am mid updating the public AMI I use for test builds, to include an R15B02 OTP instead of the R15B I have. That avoids the need for people to spend ages getting a dev environment set up. @Wohali has some bits to make an MSI package, better than my hacky attempts a year ago. That would be cool. I'm gonna revert to using a newer OpenSSL library if it works out in testing. Nothing else major comes to mind down here. A+ Dave -- NS -- NS -- NS -- NS -- NS -- Joan Touzet | jo...@atypical.net | wohali everywhere else Woo!! I can't speak for the unix stuff (other than I'll be delighted to help test it) but yup I am up for the windows world. Just point me at it. And give me a day to re-read the WiX book.. Having an MSI as the default package makes sense to me, and I will prepare a nuget package this time around, it seems to be gaining ground: http://chocolatey.org/, should be straightforward. Personally I would prefer to roll 1.3.0 soon (timebound) and then give a period for the new approaches to settle down before they go
[jira] [Assigned] (COUCHDB-1346) CouchDB hangs during start of view indexing
[
https://issues.apache.org/jira/browse/COUCHDB-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Kocoloski reassigned COUCHDB-1346:
---
Assignee: Adam Kocoloski (was: Dave Cottlehuber)
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: Adam Kocoloski
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},
{stack_size,24},
{reductions,12211}],
[{neighbour,
[jira] [Commented] (COUCHDB-1368) multipart/related document body doesn't identify which part is which attachment
[ https://issues.apache.org/jira/browse/COUCHDB-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497418#comment-13497418 ] Jens Alfke commented on COUCHDB-1368: - It turns out Content-ID is not the correct header to use for the filename, because according to RFC2045 sec.7, Content-ID values must be generated to be world-unique. (I didn't know this when writing up this issue, but discovered it later on while implementing MIME support for TouchDB. I should have updated this issue too; sorry!) The most appropriate header to use seems to be Content-Disposition (RFC1806): Content-Disposition: attachment; filename=test.txt This is what TouchDB generates, and what it will recognize in incoming MIME documents. multipart/related document body doesn't identify which part is which attachment --- Key: COUCHDB-1368 URL: https://issues.apache.org/jira/browse/COUCHDB-1368 Project: CouchDB Issue Type: Bug Components: HTTP Interface Reporter: Jens Alfke Priority: Minor If you GET a document with attachments in multipart/related format (by adding ?attachments=true and setting Accept:multipart/related), the MIME bodies for the attachments have no headers. This makes it difficult to tell which one is which. Damien says they're in the same order that they appear in the document's _attachments object ... which is fine if you're Erlang, because Erlang preserves the order of keys in a JSON object, but no other JSON implementation I know of does that (because they use hashtables instead of linked lists.) The upshot is that any non-Erlang code trying to parse such a response will have to do some by-hand parsing of the JSON data to get the _attachment keys in order. This can be fixed by adding a Content-ID header to each attachment body, whose value is the filename. It would be nice if other standard headers were added too, like Content-Type, Content-Length, Content-Encoding, as this would make it work better with existing MIME multipart libraries. -- 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-1368) multipart/related document body doesn't identify which part is which attachment
[ https://issues.apache.org/jira/browse/COUCHDB-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497445#comment-13497445 ] Jan Lehnardt commented on COUCHDB-1368: --- oopsn, I updated the branches accordingly. I only glanced at the spec for the format, not the header names, sorry about that! Either way though, I’d like a bit more thorough testing on this one, especially with all combinations of compressed, non compressed, binary and plain text attachments with compressed transfer encodings and without, just to make sure it is all correct. Is that something you can help with? (I know I asked that the last time and then nothing happened, but here we already have the fix, mostly, the other one turned to be a bit more hairy than I could handle with my time then :) multipart/related document body doesn't identify which part is which attachment --- Key: COUCHDB-1368 URL: https://issues.apache.org/jira/browse/COUCHDB-1368 Project: CouchDB Issue Type: Bug Components: HTTP Interface Reporter: Jens Alfke Priority: Minor If you GET a document with attachments in multipart/related format (by adding ?attachments=true and setting Accept:multipart/related), the MIME bodies for the attachments have no headers. This makes it difficult to tell which one is which. Damien says they're in the same order that they appear in the document's _attachments object ... which is fine if you're Erlang, because Erlang preserves the order of keys in a JSON object, but no other JSON implementation I know of does that (because they use hashtables instead of linked lists.) The upshot is that any non-Erlang code trying to parse such a response will have to do some by-hand parsing of the JSON data to get the _attachment keys in order. This can be fixed by adding a Content-ID header to each attachment body, whose value is the filename. It would be nice if other standard headers were added too, like Content-Type, Content-Length, Content-Encoding, as this would make it work better with existing MIME multipart libraries. -- 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-1368) multipart/related document body doesn't identify which part is which attachment
[ https://issues.apache.org/jira/browse/COUCHDB-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497466#comment-13497466 ] Jan Lehnardt commented on COUCHDB-1368: --- Jup, check out share/www/script/test/attachments_multipart.js :) multipart/related document body doesn't identify which part is which attachment --- Key: COUCHDB-1368 URL: https://issues.apache.org/jira/browse/COUCHDB-1368 Project: CouchDB Issue Type: Bug Components: HTTP Interface Reporter: Jens Alfke Priority: Minor If you GET a document with attachments in multipart/related format (by adding ?attachments=true and setting Accept:multipart/related), the MIME bodies for the attachments have no headers. This makes it difficult to tell which one is which. Damien says they're in the same order that they appear in the document's _attachments object ... which is fine if you're Erlang, because Erlang preserves the order of keys in a JSON object, but no other JSON implementation I know of does that (because they use hashtables instead of linked lists.) The upshot is that any non-Erlang code trying to parse such a response will have to do some by-hand parsing of the JSON data to get the _attachment keys in order. This can be fixed by adding a Content-ID header to each attachment body, whose value is the filename. It would be nice if other standard headers were added too, like Content-Type, Content-Length, Content-Encoding, as this would make it work better with existing MIME multipart libraries. -- 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-1520) Replicator does not close Socket in pull from HTTPS source
[
https://issues.apache.org/jira/browse/COUCHDB-1520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497467#comment-13497467
]
Jan Lehnardt commented on COUCHDB-1520:
---
Is there a test script you could provide that reproduces this for you?
Replicator does not close Socket in pull from HTTPS source
--
Key: COUCHDB-1520
URL: https://issues.apache.org/jira/browse/COUCHDB-1520
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.2
Environment: Ubuntu 8.04, Erlang 14.b.4 64bit
Reporter: Simon Eisenmann
Assignee: Robert Newson
Priority: Critical
Labels: close, https, leak, replication, socket, ssl
Fix For: 1.3
When replicating using pull replication from an HTTPS-CouchDB source, the
client socket does not go away, but stays in CLOSE_WAIT forever, This will
crash the whole CouchDB server, as it will run out of file descriptors.
This did not happen with CouchDB 1.1.
I experimented with changing the socket options for the replicator client,
though no luck. The only change i saw was then running with keepalive (which
was the default), also the server side (pull peer) leaks a connection. Now i
am running with socket_options = [{keepalive, false}, {send_timeout, 1},
{send_timeout_close, true}]
which does not change a thing other than on the client side is leaking
connections.
To test this, you need the PID of the couchdb's beam process (ps aux |grep
beam)
Then you list all the open files of this PID with lsof -p $PID
First you will see the pull connections beeing in ESTABLISHED state for a
wile (even when the replication itself is long finished), Then at some point
it switches to CLOSE_WAIT. The client side socket needs to be closed by the
replicator to go away and release the resources (eg. file pointer).
--
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-1593) Raise erlang/OTP minimum version to R13B04
[ https://issues.apache.org/jira/browse/COUCHDB-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt updated COUCHDB-1593: -- Priority: Blocker (was: Major) Marking this as a blocker, we should sort out what the minimum required version for 1.3.x is and document that accordingly. Currently it says R12B5. We should test if that is still true. Raise erlang/OTP minimum version to R13B04 -- Key: COUCHDB-1593 URL: https://issues.apache.org/jira/browse/COUCHDB-1593 Project: CouchDB Issue Type: Improvement Reporter: Robert Newson Priority: Blocker Fix For: 1.3 Let's ensure that all 1.3.0 installations have snappy and ejson by insisting that all builds use R13B04 or higher. -- 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] [Closed] (COUCHDB-942) CouchDB build fails without eunit
[ https://issues.apache.org/jira/browse/COUCHDB-942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt closed COUCHDB-942. Resolution: Fixed We are tracking the update of mochiweb in COUCHDB-1598 CouchDB build fails without eunit - Key: COUCHDB-942 URL: https://issues.apache.org/jira/browse/COUCHDB-942 Project: CouchDB Issue Type: Bug Components: Build System Affects Versions: 1.1 Reporter: Robert Newson Assignee: Robert Newson Fix For: 1.3 Attachments: 0001-make-eunit-completely-optional.patch A recent upgrade to mochiweb introduced a dependency on eunit but the build tools were not updated to match (mea culpa) This ticket includes a patch to mochiweb to make eunit completely optional (and declines to take the option). The patch has been submitted upstream (https://github.com/mochi/mochiweb/pull/22) -- 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-653) Extensible password storage
[ https://issues.apache.org/jira/browse/COUCHDB-653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt updated COUCHDB-653: - Fix Version/s: (was: 1.3) Extensible password storage --- Key: COUCHDB-653 URL: https://issues.apache.org/jira/browse/COUCHDB-653 Project: CouchDB Issue Type: Improvement Components: HTTP Interface, Infrastructure Reporter: Filipe Manana Attachments: couchdb-extensible-passwd-storage-trunk.patch As it has been discussed in the @dev mailing list, CouchDB should be configurable to use customizable password storage/hashing schemes. Brian Candler suggested the support for the OpenLDAP schemes for example. From the Auth roadmap mail chain: 1) Extensible password storage. Thanks Brian Candler for the links to the OpenLDAP style of storage. I think we should do this asap so we don't have to worry about backwards compatibility with the current storage mechanism until the end of time. The relevant message: http://permalink.gmane.org/gmane.comp.db.couchdb.devel/7588; -- 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] [Closed] (COUCHDB-430) respondWith() called after getRow() does not set Content-Type response
[
https://issues.apache.org/jira/browse/COUCHDB-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Lehnardt closed COUCHDB-430.
Resolution: Fixed
Fix Version/s: (was: 1.3)
1.4
respondWith() called after getRow() does not set Content-Type response
Key: COUCHDB-430
URL: https://issues.apache.org/jira/browse/COUCHDB-430
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 0.10
Environment: {couchdb:Welcome,version:0.10.0a796218}
Linux
Reporter: Rune S. Larsen
Assignee: Dave Cottlehuber
Priority: Minor
Fix For: 1.4
Attachments: 20121106_github_pr_18.diff
After calling getRow() once, the response header are locked and cannot be
changed by respondWith.
getRow() should be side-effect free and Sending shouldn't start before
calling send();
Example, where respondWith() cannot set Content-Type response header
according to Accept request header:
function(head, req){
var row = getRow();
respondWith(req,
{
json : function() {
send({'json'});
},
xml : function() {
send('?xml version=1.0 encoding=UTF-8?');
}
});
}
--
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] [Reopened] (COUCHDB-430) respondWith() called after getRow() does not set Content-Type response
[
https://issues.apache.org/jira/browse/COUCHDB-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Lehnardt reopened COUCHDB-430:
--
dDave, feel free to merge (cherry-pick) this to master.
respondWith() called after getRow() does not set Content-Type response
Key: COUCHDB-430
URL: https://issues.apache.org/jira/browse/COUCHDB-430
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 0.10
Environment: {couchdb:Welcome,version:0.10.0a796218}
Linux
Reporter: Rune S. Larsen
Assignee: Dave Cottlehuber
Priority: Minor
Fix For: 1.4
Attachments: 20121106_github_pr_18.diff
After calling getRow() once, the response header are locked and cannot be
changed by respondWith.
getRow() should be side-effect free and Sending shouldn't start before
calling send();
Example, where respondWith() cannot set Content-Type response header
according to Accept request header:
function(head, req){
var row = getRow();
respondWith(req,
{
json : function() {
send({'json'});
},
xml : function() {
send('?xml version=1.0 encoding=UTF-8?');
}
});
}
--
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
