[jira] [Commented] (COUCHDB-2237) Add a 'live' sugar for 'continuous'
[ https://issues.apache.org/jira/browse/COUCHDB-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14497344#comment-14497344 ] Joan Touzet commented on COUCHDB-2237: -- I'm still -0.9 but whatever. I will not obstruct the community on this. Add a 'live' sugar for 'continuous' --- Key: COUCHDB-2237 URL: https://issues.apache.org/jira/browse/COUCHDB-2237 Project: CouchDB Issue Type: Improvement Security Level: public(Regular issues) Components: HTTP Interface Reporter: Dale Harvey With PouchDB we generally try to stick to the same param names as Couch, we are even changing some we implemented first to be compatible (https://github.com/pouchdb/pouchdb/issues/2193) However 'continuous' sucks to type, its confusing to type and spell and everyone gets it wrong, we still support it but switched to documenting it as 'live' and life is awesome again -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2594) Single node mode: remove warning
[ https://issues.apache.org/jira/browse/COUCHDB-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14395944#comment-14395944 ] Joan Touzet commented on COUCHDB-2594: -- If [~rnewson] agrees then let it stand, but I think suppressing the warning when you only see a single node could be dangerous. This might be a new node in a large cluster that hasn't been joined to the cluster correctly, and a request came into it through a load balancer. Surely making single-node installs have N=1 in their configs as part of the setup procedure is the right fix? Single node mode: remove warning Key: COUCHDB-2594 URL: https://issues.apache.org/jira/browse/COUCHDB-2594 Project: CouchDB Issue Type: Task Security Level: public(Regular issues) Components: Database Core Reporter: Robert Kowalski Priority: Blocker Fix For: 2.0.0 we have to remove a warning that is sent as response if the node is not joined into a multi-node cluster and has no membership -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2594) Single node mode: remove warning
[ https://issues.apache.org/jira/browse/COUCHDB-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14395946#comment-14395946 ] Joan Touzet commented on COUCHDB-2594: -- Your setup wizard could confirm with the user that they want a single-node setup, and force _config to set n=1 and be done with it that way. Single node mode: remove warning Key: COUCHDB-2594 URL: https://issues.apache.org/jira/browse/COUCHDB-2594 Project: CouchDB Issue Type: Task Security Level: public(Regular issues) Components: Database Core Reporter: Robert Kowalski Priority: Blocker Fix For: 2.0.0 we have to remove a warning that is sent as response if the node is not joined into a multi-node cluster and has no membership -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2594) Single node mode: remove warning
[ https://issues.apache.org/jira/browse/COUCHDB-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14395929#comment-14395929 ] Joan Touzet commented on COUCHDB-2594: -- surely this is a config change for the default N value? Single node mode: remove warning Key: COUCHDB-2594 URL: https://issues.apache.org/jira/browse/COUCHDB-2594 Project: CouchDB Issue Type: Task Security Level: public(Regular issues) Components: Database Core Reporter: Robert Kowalski Priority: Blocker Fix For: 2.0.0 we have to remove a warning that is sent as response if the node is not joined into a multi-node cluster and has no membership -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COUCHDB-2636) Futon loses data from fields being edited on save
[ https://issues.apache.org/jira/browse/COUCHDB-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet closed COUCHDB-2636. Futon loses data from fields being edited on save - Key: COUCHDB-2636 URL: https://issues.apache.org/jira/browse/COUCHDB-2636 Project: CouchDB Issue Type: Bug Security Level: public(Regular issues) Components: Futon Reporter: Sam Gentle Assignee: Joan Touzet When you're editing a document in Futon via the Fields editor, and you click Save Document, any fields that are still being edited (ie, you haven't clicked the green tick or red x) are reverted when being saved. Couch version: 1.6.1 Steps to reproduce: 1. Go to a document in Futon 2. Spend an hour writing text into a text field 3. Hit save document Expected behaviour: Data is saved, or some kind of please confirm your changes warning appears. Actual behaviour: Data disappears irrevocably. Note that this doesn't affect the Source editor because it updates as soon as the textarea loses focus. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (COUCHDB-2636) Futon loses data from fields being edited on save
[ https://issues.apache.org/jira/browse/COUCHDB-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet resolved COUCHDB-2636. -- Resolution: Won't Fix Assignee: Joan Touzet Hi Sam, thanks for reporting this. I am guessing that you lost some important data in a document of yours, and for that, I apologize on behalf of the CouchDB team. The Futon interface is deprecated in Couch 1.7.x and completely replaced with Fauxton in 2.0. As such we won't be revisiting Futon to make changes to it at this point. I encourage you to download a CouchDB 2.0 preview build and see if Fauxton works better for you! All the best, Joan Futon loses data from fields being edited on save - Key: COUCHDB-2636 URL: https://issues.apache.org/jira/browse/COUCHDB-2636 Project: CouchDB Issue Type: Bug Security Level: public(Regular issues) Components: Futon Reporter: Sam Gentle Assignee: Joan Touzet When you're editing a document in Futon via the Fields editor, and you click Save Document, any fields that are still being edited (ie, you haven't clicked the green tick or red x) are reverted when being saved. Couch version: 1.6.1 Steps to reproduce: 1. Go to a document in Futon 2. Spend an hour writing text into a text field 3. Hit save document Expected behaviour: Data is saved, or some kind of please confirm your changes warning appears. Actual behaviour: Data disappears irrevocably. Note that this doesn't affect the Source editor because it updates as soon as the textarea loses focus. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COUCHDB-1963) Move from etap to eunit
[ https://issues.apache.org/jira/browse/COUCHDB-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet closed COUCHDB-1963. Move from etap to eunit --- Key: COUCHDB-1963 URL: https://issues.apache.org/jira/browse/COUCHDB-1963 Project: CouchDB Issue Type: Improvement Components: Test Suite Reporter: Joan Touzet Assignee: Alexander Shorin Labels: etap, eunit, test Fix For: 2.0.0 Pursuant to an IRC/Twitter discussion, it seems that there is some support ([~pjdavis1970], [~janl]) to move off of etap. Motivations include etap being unmaintained for 2+ years, eunit shipping with Erlang, and least importantly etap tests being completely broken on the Windows build. There are only 63 .t files in the entire source tree; hopefully this is work that can be weekend-tackled by one person, or could be tag-teamed with little friction. There was a subsequent discussion about the current, existing JS tests; while there are issues with these and room for improvement, this bug is *strictly* about our white-box etap unit tests and larger multi-instance tests that may not best be accomplished by a JS framework. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2390) Fauxton config, admin sections considered dangerous in 2.0
[ https://issues.apache.org/jira/browse/COUCHDB-2390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14230428#comment-14230428 ] Joan Touzet commented on COUCHDB-2390: -- Stopping by as the thread is quite long here. As the original requestor I agree with [~robertkowalski]. You can say in the UI that the page affects the current node only as [~garren] suggests, but if you're hitting the cluster through a load balancer (as is recommended) you'll have no control over which node you hit. Further, each node may be firewalled to prevent access directly by an end user. Further there is no visual indication as to which node you're talking to in this situation, so it's pointless to try and use the functionality. Given these limitations I think having these pages available is actually worse than not providing them at all. My recommendation is to remove this functionality until such time as we have a configuration endpoint that allows you to set values on all nodes in a cluster at once (or, after cluster expansion/node replacement, force values to be consistent across a cluster / to a specific node). Once that's available we can resurrect these pages in a fashion that makes sense. Fauxton config, admin sections considered dangerous in 2.0 -- Key: COUCHDB-2390 URL: https://issues.apache.org/jira/browse/COUCHDB-2390 Project: CouchDB Issue Type: Bug Security Level: public(Regular issues) Components: BigCouch, Fauxton Reporter: Joan Touzet Assignee: Ben Keen Priority: Blocker In Fauxton today, there is are 2 sections to edit config-file settings and to create new admins. Neither of these sections will work as intended in a clustered setup. Any Fauxton session will necessarily be speaking to a single machine. The config APIs and admin user info as exposed will only add that information to a single node's .ini file. We should hide these features in Fauxton for now (short-term fix) and correct the config /admin creation APIs to work correctly in a clustered setup (medium-term fix). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (COUCHDB-2480) ';l'l;'l';l'l;'
[ https://issues.apache.org/jira/browse/COUCHDB-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet reassigned COUCHDB-2480: Assignee: Daniel Gruno ??? ';l'l;'l';l'l;' --- Key: COUCHDB-2480 URL: https://issues.apache.org/jira/browse/COUCHDB-2480 Project: CouchDB Issue Type: Bug Security Level: public(Regular issues) Reporter: ASF subversion and git services Assignee: Daniel Gruno ';l'l;'l';l'l;' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (COUCHDB-2464) make dist is broken
Joan Touzet created COUCHDB-2464: Summary: make dist is broken Key: COUCHDB-2464 URL: https://issues.apache.org/jira/browse/COUCHDB-2464 Project: CouchDB Issue Type: Bug Security Level: public (Regular issues) Components: Build System Reporter: Joan Touzet Filing for [~janl]. 1. For the goodbye-futon branch, where fauxton replaces futon, /_utils is 404 even though the ini was adjusted and fauxton is moved into rel/couchdb. 2. rel/couchdb.config hardcodes paths that should be variable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2237) Add a 'live' sugar for 'continuous'
[ https://issues.apache.org/jira/browse/COUCHDB-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14194030#comment-14194030 ] Joan Touzet commented on COUCHDB-2237: -- I'm -0.9 on this suggestion. Live implies that changes are instantaneously sent, which isn't necessarily true. First off, without a since value it'll start from the earliest rev it knows of, which certainly isn't live data. And even if you are caught up in the feed, there are still reasons why the feed you get will not be near-instantaneous, especially if someone else is replicating (old?) documents into the db, or if you're in a degraded cluster that is suddenly rejoined together (similar to the replication scenario). TL;DR: live might be easier to type than continuous but it doesn't mean the same thing. Add a 'live' sugar for 'continuous' --- Key: COUCHDB-2237 URL: https://issues.apache.org/jira/browse/COUCHDB-2237 Project: CouchDB Issue Type: Improvement Security Level: public(Regular issues) Components: HTTP Interface Reporter: Dale Harvey With PouchDB we generally try to stick to the same param names as Couch, we are even changing some we implemented first to be compatible (https://github.com/pouchdb/pouchdb/issues/2193) However 'continuous' sucks to type, its confusing to type and spell and everyone gets it wrong, we still support it but switched to documenting it as 'live' and life is awesome again -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2237) Add a 'live' sugar for 'continuous'
[ https://issues.apache.org/jira/browse/COUCHDB-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14194032#comment-14194032 ] Joan Touzet commented on COUCHDB-2237: -- Other suggestions I came up with on IRC just now: watch=true follow=true stream=true Add a 'live' sugar for 'continuous' --- Key: COUCHDB-2237 URL: https://issues.apache.org/jira/browse/COUCHDB-2237 Project: CouchDB Issue Type: Improvement Security Level: public(Regular issues) Components: HTTP Interface Reporter: Dale Harvey With PouchDB we generally try to stick to the same param names as Couch, we are even changing some we implemented first to be compatible (https://github.com/pouchdb/pouchdb/issues/2193) However 'continuous' sucks to type, its confusing to type and spell and everyone gets it wrong, we still support it but switched to documenting it as 'live' and life is awesome again -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2407) Database updates feed is broken
[
https://issues.apache.org/jira/browse/COUCHDB-2407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14184309#comment-14184309
]
Joan Touzet commented on COUCHDB-2407:
--
I think what [~rnewson] is trying to say is that, in 2.0, the /_db_updates
endpoint is not just an endpoint, it actually requires a database to operate.
That's why you have to create the database only after the cluster has been
established, otherwise creating the DB will put it only on some (or one!) of
the nodes -- which will be insufficient to make the functionality work.
Auto-creation of various clustered databases on startup is what [~janl] is
looking at, as it's a bootstrapping problem.
Database updates feed is broken
---
Key: COUCHDB-2407
URL: https://issues.apache.org/jira/browse/COUCHDB-2407
Project: CouchDB
Issue Type: Bug
Security Level: public(Regular issues)
Components: HTTP Interface
Affects Versions: 2.0.0
Reporter: Alexander Shorin
For current state of CouchDB 2.0 (not sure to which commit make a reference,
just for today) it acts very inconsistent:
{code}
http --json http://localhost:15984/_db_updates
HTTP/1.1 404 Object Not Found
Cache-Control: must-revalidate
Content-Length: 58
Content-Type: application/json
Date: Sat, 25 Oct 2014 13:42:25 GMT
Server: CouchDB/40c5c85 (Erlang OTP/17)
X-Couch-Request-ID: 27e8ab2a
X-CouchDB-Body-Time: 0
{
error: not_found,
reason: Database does not exist.
}
{code}
Ok, there is no such database. But wait:
{code}
http --json 'http://localhost:15984/_db_updates?feed=eventsource'
HTTP/1.1 400 Bad Request
Cache-Control: must-revalidate
Content-Length: 88
Content-Type: application/json
Date: Sat, 25 Oct 2014 13:39:59 GMT
Server: CouchDB/40c5c85 (Erlang OTP/17)
X-Couch-Request-ID: 3a5ca656
X-CouchDB-Body-Time: 0
{
error: bad_request,
reason: Supported `feed` types: normal, continuous, longpoll
}
{code}
The eventsource feed type is supported by CouchDB 1.x. Ok, let's try
suggested continuous one:
{code}
http --json
'http://localhost:15984/_db_updates?timeout=1000heartbeat=falsefeed=continuous'
HTTP/1.1 400 Bad Request
Cache-Control: must-revalidate
Content-Length: 51
Content-Type: application/json
Date: Sat, 25 Oct 2014 13:50:59 GMT
Server: CouchDB/40c5c85 (Erlang OTP/17)
X-Couch-Request-ID: 6c560dc2
X-CouchDB-Body-Time: 0
{
error: bad_request,
reason: invalid_integer
}
{code}
The same request is correct for CouchDB 1.x.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (COUCHDB-2407) Improve docs, bootstrap process for database updates feed
[
https://issues.apache.org/jira/browse/COUCHDB-2407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet updated COUCHDB-2407:
-
Summary: Improve docs, bootstrap process for database updates feed (was:
Database updates feed is broken)
Improve docs, bootstrap process for database updates feed
--
Key: COUCHDB-2407
URL: https://issues.apache.org/jira/browse/COUCHDB-2407
Project: CouchDB
Issue Type: Bug
Security Level: public(Regular issues)
Components: HTTP Interface
Affects Versions: 2.0.0
Reporter: Alexander Shorin
For current state of CouchDB 2.0 (not sure to which commit make a reference,
just for today) it acts very inconsistent:
{code}
http --json http://localhost:15984/_db_updates
HTTP/1.1 404 Object Not Found
Cache-Control: must-revalidate
Content-Length: 58
Content-Type: application/json
Date: Sat, 25 Oct 2014 13:42:25 GMT
Server: CouchDB/40c5c85 (Erlang OTP/17)
X-Couch-Request-ID: 27e8ab2a
X-CouchDB-Body-Time: 0
{
error: not_found,
reason: Database does not exist.
}
{code}
Ok, there is no such database. But wait:
{code}
http --json 'http://localhost:15984/_db_updates?feed=eventsource'
HTTP/1.1 400 Bad Request
Cache-Control: must-revalidate
Content-Length: 88
Content-Type: application/json
Date: Sat, 25 Oct 2014 13:39:59 GMT
Server: CouchDB/40c5c85 (Erlang OTP/17)
X-Couch-Request-ID: 3a5ca656
X-CouchDB-Body-Time: 0
{
error: bad_request,
reason: Supported `feed` types: normal, continuous, longpoll
}
{code}
The eventsource feed type is supported by CouchDB 1.x. Ok, let's try
suggested continuous one:
{code}
http --json
'http://localhost:15984/_db_updates?timeout=1000heartbeat=falsefeed=continuous'
HTTP/1.1 400 Bad Request
Cache-Control: must-revalidate
Content-Length: 51
Content-Type: application/json
Date: Sat, 25 Oct 2014 13:50:59 GMT
Server: CouchDB/40c5c85 (Erlang OTP/17)
X-Couch-Request-ID: 6c560dc2
X-CouchDB-Body-Time: 0
{
error: bad_request,
reason: invalid_integer
}
{code}
The same request is correct for CouchDB 1.x.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (COUCHDB-2407) Improve docs, error messages, bootstrap process for database updates feed
[
https://issues.apache.org/jira/browse/COUCHDB-2407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet updated COUCHDB-2407:
-
Summary: Improve docs, error messages, bootstrap process for database
updates feed (was: Improve docs, bootstrap process for database updates feed )
Improve docs, error messages, bootstrap process for database updates feed
--
Key: COUCHDB-2407
URL: https://issues.apache.org/jira/browse/COUCHDB-2407
Project: CouchDB
Issue Type: Bug
Security Level: public(Regular issues)
Components: HTTP Interface
Affects Versions: 2.0.0
Reporter: Alexander Shorin
For current state of CouchDB 2.0 (not sure to which commit make a reference,
just for today) it acts very inconsistent:
{code}
http --json http://localhost:15984/_db_updates
HTTP/1.1 404 Object Not Found
Cache-Control: must-revalidate
Content-Length: 58
Content-Type: application/json
Date: Sat, 25 Oct 2014 13:42:25 GMT
Server: CouchDB/40c5c85 (Erlang OTP/17)
X-Couch-Request-ID: 27e8ab2a
X-CouchDB-Body-Time: 0
{
error: not_found,
reason: Database does not exist.
}
{code}
Ok, there is no such database. But wait:
{code}
http --json 'http://localhost:15984/_db_updates?feed=eventsource'
HTTP/1.1 400 Bad Request
Cache-Control: must-revalidate
Content-Length: 88
Content-Type: application/json
Date: Sat, 25 Oct 2014 13:39:59 GMT
Server: CouchDB/40c5c85 (Erlang OTP/17)
X-Couch-Request-ID: 3a5ca656
X-CouchDB-Body-Time: 0
{
error: bad_request,
reason: Supported `feed` types: normal, continuous, longpoll
}
{code}
The eventsource feed type is supported by CouchDB 1.x. Ok, let's try
suggested continuous one:
{code}
http --json
'http://localhost:15984/_db_updates?timeout=1000heartbeat=falsefeed=continuous'
HTTP/1.1 400 Bad Request
Cache-Control: must-revalidate
Content-Length: 51
Content-Type: application/json
Date: Sat, 25 Oct 2014 13:50:59 GMT
Server: CouchDB/40c5c85 (Erlang OTP/17)
X-Couch-Request-ID: 6c560dc2
X-CouchDB-Body-Time: 0
{
error: bad_request,
reason: invalid_integer
}
{code}
The same request is correct for CouchDB 1.x.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (COUCHDB-2405) Improve _active_tasks endpoint with filter query string parameters
Joan Touzet created COUCHDB-2405: Summary: Improve _active_tasks endpoint with filter query string parameters Key: COUCHDB-2405 URL: https://issues.apache.org/jira/browse/COUCHDB-2405 Project: CouchDB Issue Type: Improvement Security Level: public (Regular issues) Components: HTTP Interface Reporter: Joan Touzet As an Fauxton developer, I'd like to specify type, node and range filters on /_active_tasks to be able to improve Dashboard support for visualising long-running CouchDB cluster tasks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (COUCHDB-2390) Fauxton config, admin sections considered dangerous in 2.0
Joan Touzet created COUCHDB-2390: Summary: Fauxton config, admin sections considered dangerous in 2.0 Key: COUCHDB-2390 URL: https://issues.apache.org/jira/browse/COUCHDB-2390 Project: CouchDB Issue Type: Bug Security Level: public (Regular issues) Components: BigCouch, Fauxton Reporter: Joan Touzet In Fauxton today, there is are 2 sections to edit config-file settings and to create new admins. Neither of these sections will work as intended in a clustered setup. Any Fauxton session will necessarily be speaking to a single machine. The config APIs and admin user info as exposed will only add that information to a single node's .ini file. We should hide these features in Fauxton for now (short-term fix) and correct the config /admin creation APIs to work correctly in a clustered setup (medium-term fix). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2027) CORS should not require authentication on preflight OPTIONS request
[ https://issues.apache.org/jira/browse/COUCHDB-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14167301#comment-14167301 ] Joan Touzet commented on COUCHDB-2027: -- [~joshperry] Have you tried this against the master branch of CouchDB? There have been changes to CORS and I don't know if they have resolved your issue or not. CORS should not require authentication on preflight OPTIONS request --- Key: COUCHDB-2027 URL: https://issues.apache.org/jira/browse/COUCHDB-2027 Project: CouchDB Issue Type: Bug Components: HTTP Interface Reporter: Stéphane Alnet The discussion in https://github.com/daleharvey/pouchdb/issues/1003 points to an issue whereby CouchDB is requiring authentication for preflight OPTIONS message where it shouldn't. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (COUCHDB-2369) Adding Nightwatch.js to test Fauxton
[ https://issues.apache.org/jira/browse/COUCHDB-2369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet reassigned COUCHDB-2369: Assignee: Michelle Phung Adding Nightwatch.js to test Fauxton Key: COUCHDB-2369 URL: https://issues.apache.org/jira/browse/COUCHDB-2369 Project: CouchDB Issue Type: Test Security Level: public(Regular issues) Components: Fauxton Reporter: Michelle Phung Assignee: Michelle Phung Priority: Minor Browser Automation: Nightwatch.js is an easy to use Node.js based End-to-End (E2E) testing solution for browser based apps and websites. It uses the powerful Selenium WebDriver API to perform commands and assertions on DOM elements. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-1863) Documentation link should be on top links of front page
[ https://issues.apache.org/jira/browse/COUCHDB-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14165188#comment-14165188 ] Joan Touzet commented on COUCHDB-1863: -- Planet is fun, but there needs to be more content on it. I think we need to promote it more. Guide I agree, it's time to de-promote, unless a v2.0 is planned [~janl] [~nslater]? Documentation link should be on top links of front page --- Key: COUCHDB-1863 URL: https://issues.apache.org/jira/browse/COUCHDB-1863 Project: CouchDB Issue Type: Bug Components: Website Reporter: Dale Harvey Assignee: Noah Slater Its about the most important link there and nobody (including me) can find it. Can send in a patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-1355) split code create couch_httpd application
[ https://issues.apache.org/jira/browse/COUCHDB-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14162732#comment-14162732 ] Joan Touzet commented on COUCHDB-1355: -- Does this ticket make any sense now that we have chttpd, [~pjdavis1970]? split code create couch_httpd application --- Key: COUCHDB-1355 URL: https://issues.apache.org/jira/browse/COUCHDB-1355 Project: CouchDB Issue Type: Improvement Components: Database Core, HTTP Interface Affects Versions: 1.3 Reporter: Benoit Chesneau Assignee: Benoit Chesneau Attachments: 0001-couch_httpd-application.patch, 0002-move-httpd-record-in-couch_httpd-include-couch_httpd.patch, 0003-create-couch_changes-application.-Fix-tests-and-allo.patch Couchdb is still to monolithic. This tcicket track changes to extract CouchDB HTTP API as a full application. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-1251) Factor out couch core and hook other compnonents through a module system
[ https://issues.apache.org/jira/browse/COUCHDB-1251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14158683#comment-14158683 ] Joan Touzet commented on COUCHDB-1251: -- [~tilgovi] Do you feel this is satisfied by the current state of CouchDB master? If so I'd like to close this. Factor out couch core and hook other compnonents through a module system Key: COUCHDB-1251 URL: https://issues.apache.org/jira/browse/COUCHDB-1251 Project: CouchDB Issue Type: Umbrella Components: Build System, Database Core Reporter: Randall Leeds Fix For: 2.0.0 https://mail-archives.apache.org/mod_mbox/couchdb-dev/201108.mbox/browser -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COUCHDB-1756) 100% compatibility with BigCouch API
[ https://issues.apache.org/jira/browse/COUCHDB-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet closed COUCHDB-1756. Resolution: Fixed We have this now., thanks to Bob Newson's herculean efforts. I'm closing. If we find any inconsistencies let's raise new tickets for that. 100% compatibility with BigCouch API Key: COUCHDB-1756 URL: https://issues.apache.org/jira/browse/COUCHDB-1756 Project: CouchDB Issue Type: Task Reporter: Robert Newson Assignee: Robert Newson Fix For: 2.0.0 The release that includes the resolution of this ticket will be 100% compatible with the release after the BigCouch merge. This will include additions (of new parameters, methods) that pertain to clustered databases, subtractions (of parameters, features) that do not work in clusters and changes (typically of response values like update sequences). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2350) Finish move of the wiki documentation; clean up references in docs.couchdb.org
[ https://issues.apache.org/jira/browse/COUCHDB-2350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14158869#comment-14158869 ] Joan Touzet commented on COUCHDB-2350: -- Hi Javier, I'm happy to grant you access, but please keep in mind that the *large bulk* of the old wiki has been converted to the official documentation. None of us want to see those pages mass imported in. You should make a point of checking docs.couchdb.org first, and if the information is contained there, simply obsolete the old page and have it redirect to the appropriate docs page. Finish move of the wiki documentation; clean up references in docs.couchdb.org -- Key: COUCHDB-2350 URL: https://issues.apache.org/jira/browse/COUCHDB-2350 Project: CouchDB Issue Type: Improvement Security Level: public(Regular issues) Components: Documentation, Website Reporter: Javier Candeira It occurs to me that as a new inductee into the project I'm in a privileged position to update and restructure the documentation as I take the project in, and it would probably be a better first task than to go after individual bugs. This is how I'd go about working on restructuring the documentation: - move the old wiki content to confluence and 301 all wiki.apache.org pages to the new wiki. No new content added. - track all links and references to old wiki in docs.couchdb.org, and rewrite them to point at new wiki. Still no new content added. - then I would start triaging documentation bugs. There are many tasks that are better done by a newcomer, since we need to follow the documentation or be confused by it. This is what I'd need: - To be added to the confluence wiki contributors list (username: candeira) - To be added to the old wiki contributors list (username: JavierCandeira) - Optionally, to have a test confluence wiki so I can test migrating the old one to the new one via scripts without making public changes until bugs have been ironed out. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2350) Finish move of the wiki documentation; clean up references in docs.couchdb.org
[ https://issues.apache.org/jira/browse/COUCHDB-2350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14158877#comment-14158877 ] Joan Touzet commented on COUCHDB-2350: -- Oh before I forget - please make sure you chat with [~andywenk] before making any major changes. He had a plan for migrating the content over, and I'm sure he'd be happy to see you take over carry on, modifying the plan as appropriate. Finish move of the wiki documentation; clean up references in docs.couchdb.org -- Key: COUCHDB-2350 URL: https://issues.apache.org/jira/browse/COUCHDB-2350 Project: CouchDB Issue Type: Improvement Security Level: public(Regular issues) Components: Documentation, Website Reporter: Javier Candeira It occurs to me that as a new inductee into the project I'm in a privileged position to update and restructure the documentation as I take the project in, and it would probably be a better first task than to go after individual bugs. This is how I'd go about working on restructuring the documentation: - move the old wiki content to confluence and 301 all wiki.apache.org pages to the new wiki. No new content added. - track all links and references to old wiki in docs.couchdb.org, and rewrite them to point at new wiki. Still no new content added. - then I would start triaging documentation bugs. There are many tasks that are better done by a newcomer, since we need to follow the documentation or be confused by it. This is what I'd need: - To be added to the confluence wiki contributors list (username: candeira) - To be added to the old wiki contributors list (username: JavierCandeira) - Optionally, to have a test confluence wiki so I can test migrating the old one to the new one via scripts without making public changes until bugs have been ironed out. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2350) Finish move of the wiki documentation; clean up references in docs.couchdb.org
[ https://issues.apache.org/jira/browse/COUCHDB-2350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14158886#comment-14158886 ] Joan Touzet commented on COUCHDB-2350: -- OK, you have write access now to the new wiki. I am *positive* that I used to have access to the old wiki, but I don't seem to have anymore. Perhaps [~janl] can arrange this for you (and for me!) I'm afraid only INFRA can add more Confluence spaces, and I've never seen them grant permission for a test space, so keep that in mind. Finish move of the wiki documentation; clean up references in docs.couchdb.org -- Key: COUCHDB-2350 URL: https://issues.apache.org/jira/browse/COUCHDB-2350 Project: CouchDB Issue Type: Improvement Security Level: public(Regular issues) Components: Documentation, Website Reporter: Javier Candeira It occurs to me that as a new inductee into the project I'm in a privileged position to update and restructure the documentation as I take the project in, and it would probably be a better first task than to go after individual bugs. This is how I'd go about working on restructuring the documentation: - move the old wiki content to confluence and 301 all wiki.apache.org pages to the new wiki. No new content added. - track all links and references to old wiki in docs.couchdb.org, and rewrite them to point at new wiki. Still no new content added. - then I would start triaging documentation bugs. There are many tasks that are better done by a newcomer, since we need to follow the documentation or be confused by it. This is what I'd need: - To be added to the confluence wiki contributors list (username: candeira) - To be added to the old wiki contributors list (username: JavierCandeira) - Optionally, to have a test confluence wiki so I can test migrating the old one to the new one via scripts without making public changes until bugs have been ironed out. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (COUCHDB-2343) /_config/admins/username fails on master
Joan Touzet created COUCHDB-2343: Summary: /_config/admins/username fails on master Key: COUCHDB-2343 URL: https://issues.apache.org/jira/browse/COUCHDB-2343 Project: CouchDB Issue Type: Bug Security Level: public (Regular issues) Components: HTTP Interface Reporter: Joan Touzet In a multi-node setup, calling _config/admins/username to create an admin user fails to correctly configure a cluster with a new administrator. This fails for two reasons: 1) The call is only processed on a single node, and the admin entry is not replicated 2) Even if the call is repeated on all nodes manually, the hashes will be different on each node, which will cause cookie failure when attempting to authenticate via other machines. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (COUCHDB-2343) /_config/admins/username fails on master
[ https://issues.apache.org/jira/browse/COUCHDB-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet updated COUCHDB-2343: - Priority: Blocker (was: Major) /_config/admins/username fails on master Key: COUCHDB-2343 URL: https://issues.apache.org/jira/browse/COUCHDB-2343 Project: CouchDB Issue Type: Bug Security Level: public(Regular issues) Components: HTTP Interface Affects Versions: 2.0.0 Reporter: Joan Touzet Priority: Blocker Labels: auth In a multi-node setup, calling _config/admins/username to create an admin user fails to correctly configure a cluster with a new administrator. This fails for two reasons: 1) The call is only processed on a single node, and the admin entry is not replicated 2) Even if the call is repeated on all nodes manually, the hashes will be different on each node, which will cause cookie failure when attempting to authenticate via other machines. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (COUCHDB-2343) /_config/admins/username fails on master
[ https://issues.apache.org/jira/browse/COUCHDB-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet updated COUCHDB-2343: - Labels: auth (was: ) /_config/admins/username fails on master Key: COUCHDB-2343 URL: https://issues.apache.org/jira/browse/COUCHDB-2343 Project: CouchDB Issue Type: Bug Security Level: public(Regular issues) Components: HTTP Interface Affects Versions: 2.0.0 Reporter: Joan Touzet Priority: Blocker Labels: auth In a multi-node setup, calling _config/admins/username to create an admin user fails to correctly configure a cluster with a new administrator. This fails for two reasons: 1) The call is only processed on a single node, and the admin entry is not replicated 2) Even if the call is repeated on all nodes manually, the hashes will be different on each node, which will cause cookie failure when attempting to authenticate via other machines. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (COUCHDB-2343) /_config/admins/username fails on master
[ https://issues.apache.org/jira/browse/COUCHDB-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet updated COUCHDB-2343: - Affects Version/s: 2.0.0 /_config/admins/username fails on master Key: COUCHDB-2343 URL: https://issues.apache.org/jira/browse/COUCHDB-2343 Project: CouchDB Issue Type: Bug Security Level: public(Regular issues) Components: HTTP Interface Affects Versions: 2.0.0 Reporter: Joan Touzet Priority: Blocker Labels: auth In a multi-node setup, calling _config/admins/username to create an admin user fails to correctly configure a cluster with a new administrator. This fails for two reasons: 1) The call is only processed on a single node, and the admin entry is not replicated 2) Even if the call is repeated on all nodes manually, the hashes will be different on each node, which will cause cookie failure when attempting to authenticate via other machines. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2334) Metadata db cassim does not exist
[
https://issues.apache.org/jira/browse/COUCHDB-2334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14144193#comment-14144193
]
Joan Touzet commented on COUCHDB-2334:
--
One parenthetical comment here: [~janl] has talked about his desire for
endpoints in 2.0 that can be hit to connect a cluster. He went so far as to
suggest to me he felt such endpoints, and Fauxton support for them, were
blockers for a 2.0 release. This particular ticket sounds like the final step
in such work.
As such, would it be prudent to sketch out what the workflow looks like for
first-time cluster setup as well as adding/removing nodes to a cluster, and
design the correct endpoints around those? _setup_complete works for first-time
cluster setup, but intentionally neglects what happens when nodes are added to
a cluster.
Metadata db cassim does not exist
---
Key: COUCHDB-2334
URL: https://issues.apache.org/jira/browse/COUCHDB-2334
Project: CouchDB
Issue Type: Bug
Security Level: public(Regular issues)
Components: BigCouch
Reporter: Alexander Shorin
And so happens every 5 minutes:
{code}
2014-09-20 04:00:06.786 [error] node1@127.0.0.1 0.341.0 Metadata db
cassim does not exist
2014-09-20 04:05:06.788 [error] node1@127.0.0.1 0.341.0 Metadata db
cassim does not exist
2014-09-20 04:10:06.790 [error] node1@127.0.0.1 0.341.0 Metadata db
cassim does not exist
2014-09-20 04:15:06.792 [error] node1@127.0.0.1 0.341.0 Metadata db
cassim does not exist
2014-09-20 04:20:06.794 [error] node1@127.0.0.1 0.341.0 Metadata db
cassim does not exist
2014-09-20 04:25:06.796 [error] node1@127.0.0.1 0.341.0 Metadata db
cassim does not exist
2014-09-20 04:30:06.798 [error] node1@127.0.0.1 0.341.0 Metadata db
cassim does not exist
2014-09-20 04:35:06.800 [error] node1@127.0.0.1 0.341.0 Metadata db
cassim does not exist
2014-09-20 04:40:06.802 [error] node1@127.0.0.1 0.341.0 Metadata db
cassim does not exist
2014-09-20 04:45:06.804 [error] node1@127.0.0.1 0.341.0 Metadata db
cassim does not exist
2014-09-20 04:50:06.806 [error] node1@127.0.0.1 0.341.0 Metadata db
cassim does not exist
2014-09-20 04:55:06.808 [error] node1@127.0.0.1 0.341.0 Metadata db
cassim does not exist
2014-09-20 05:00:06.810 [error] node1@127.0.0.1 0.341.0 Metadata db
cassim does not exist
2014-09-20 05:05:06.812 [error] node1@127.0.0.1 0.341.0 Metadata db
cassim does not exist
2014-09-20 05:10:06.814 [error] node1@127.0.0.1 0.341.0 Metadata db
cassim does not exist
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (COUCHDB-523) View API POST keys to retrieve multiple docs by key could also allow for multiple 'range' queries, i.e. an array of { startkey: .., endkey: ... } params in the POST
[
https://issues.apache.org/jira/browse/COUCHDB-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet resolved COUCHDB-523.
-
Resolution: Fixed
Fix Version/s: 2.0.0
Russell's work got merged to master along with the windsor-merge branch.
View API POST keys to retrieve multiple docs by key could also allow for
multiple 'range' queries, i.e. an array of { startkey: .., endkey: ... }
params in the POST
Key: COUCHDB-523
URL: https://issues.apache.org/jira/browse/COUCHDB-523
Project: CouchDB
Issue Type: Improvement
Components: HTTP Interface
Reporter: Nathan Stott
Assignee: Russell Branca
Priority: Minor
Fix For: 2.0.0
Attachments: couch_httpd_view.erl, multi_start_end_key.diff,
ranged_key_post.diff
It would be useful if I could do a single POST to a view to retrieve multiple
ranges specified by startkey, endkey.
The format could be as follows:
{ ranges: [ { startkey: a, endkey: c }, { startkey:g,
endkey:z } ] }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (COUCHDB-257) HTTP caching headers make Internet Explorer experience poor
[ https://issues.apache.org/jira/browse/COUCHDB-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet updated COUCHDB-257: Summary: HTTP caching headers make Internet Explorer experience poor (was: HTTP caching headers don't provide expected behaviour) HTTP caching headers make Internet Explorer experience poor --- Key: COUCHDB-257 URL: https://issues.apache.org/jira/browse/COUCHDB-257 Project: CouchDB Issue Type: Bug Components: HTTP Interface Affects Versions: 0.8.1, 0.9 Environment: Server: Ubuntu Hardy on x86. Client: Windows XP (32-bit). Reporter: Vinay Sajip Priority: Minor Attachments: caching-header-patch.diff, expires.patch The HTTP caching headers currently put out cause IE (for example) to not display information correctly in Futon. It's easy to reproduce: I open windows in Firefox and IE simultaneously, do an update using Firefox (e.g. add a new document) and refresh the IE window. The updated document count is not shown. If I clear the browser cache and try again, the updated information is displayed. The HTTP header put out is Cache-Control: must-revalidate which seems to me insufficient - for IE, at least. Is there way of configuring these headers, to for example Cache-Control: no-cache Pragma: no-cache Expires: some date in the past, or the same value as the Date: header Christopher Lenz has said about this that This is due to extra-aggressive (and against the HTTP spec) caching that IE does on XMLHTTPRequests. A patch would need to do user agent sniffing to conditionally add the cache: false parameter to the jQuery ajax() invocations in jquery.couch.js (and maybe elsewhere). I wouldn't want to add this for all user agents, as it basically circumvents any caching for AJAX requests (even for not-craptastically-broken implementations), and thus would add quite a bit of unnecessary overhead. To this, I would comment that I don't believe a patch to the client-side code in Futon would be sufficient. There are other clients out there, some of which will be on Windows and so by default use the (acknowledgely broken) Microsoft stack. In my view it is more important to err on the side of correctness than performance - so I believe the headers generated server-side need to change, as well as perhaps Futon client-side changes. I note that handle_uuids_req in couch_httpd_misc_handlers.erl uses the no-cache/Expires scheme I mention. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (COUCHDB-257) HTTP caching headers make Internet Explorer experience poor
[ https://issues.apache.org/jira/browse/COUCHDB-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet updated COUCHDB-257: Skill Level: (was: Regular Contributors Level (Easy to Medium)) Labels: wontfix (was: ) Saw this one scroll by on IRC and decided it's time to change the title, as the old one scared me every time I saw it. There's nothing we can do to fix IE's broken behaviour here without making important, *incorrect* semantic changes for programmatic access to CouchDB. Those changes would break appropriate decisions being made by non-brain-dead client implementations. You can't please all of the people all of the time - and as an occasional Windows user myself, all of you IE people have my deepest symapthy for the trouble this causes you. Might I suggest Firefox or Chrome if you need to use your browser to directly talk to CouchDB? HTTP caching headers make Internet Explorer experience poor --- Key: COUCHDB-257 URL: https://issues.apache.org/jira/browse/COUCHDB-257 Project: CouchDB Issue Type: Bug Components: HTTP Interface Affects Versions: 0.8.1, 0.9 Environment: Server: Ubuntu Hardy on x86. Client: Windows XP (32-bit). Reporter: Vinay Sajip Priority: Minor Labels: wontfix Attachments: caching-header-patch.diff, expires.patch The HTTP caching headers currently put out cause IE (for example) to not display information correctly in Futon. It's easy to reproduce: I open windows in Firefox and IE simultaneously, do an update using Firefox (e.g. add a new document) and refresh the IE window. The updated document count is not shown. If I clear the browser cache and try again, the updated information is displayed. The HTTP header put out is Cache-Control: must-revalidate which seems to me insufficient - for IE, at least. Is there way of configuring these headers, to for example Cache-Control: no-cache Pragma: no-cache Expires: some date in the past, or the same value as the Date: header Christopher Lenz has said about this that This is due to extra-aggressive (and against the HTTP spec) caching that IE does on XMLHTTPRequests. A patch would need to do user agent sniffing to conditionally add the cache: false parameter to the jQuery ajax() invocations in jquery.couch.js (and maybe elsewhere). I wouldn't want to add this for all user agents, as it basically circumvents any caching for AJAX requests (even for not-craptastically-broken implementations), and thus would add quite a bit of unnecessary overhead. To this, I would comment that I don't believe a patch to the client-side code in Futon would be sufficient. There are other clients out there, some of which will be on Windows and so by default use the (acknowledgely broken) Microsoft stack. In my view it is more important to err on the side of correctness than performance - so I believe the headers generated server-side need to change, as well as perhaps Futon client-side changes. I note that handle_uuids_req in couch_httpd_misc_handlers.erl uses the no-cache/Expires scheme I mention. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-1125) implement inclusive_start view option
[ https://issues.apache.org/jira/browse/COUCHDB-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14130982#comment-14130982 ] Joan Touzet commented on COUCHDB-1125: -- Pull requests welcome ;) implement inclusive_start view option - Key: COUCHDB-1125 URL: https://issues.apache.org/jira/browse/COUCHDB-1125 Project: CouchDB Issue Type: Bug Affects Versions: 1.2 Reporter: Jan Lehnardt Priority: Minor Attachments: inclusive_start.patch From COUCHDB-194: I suggest to generalize to left or/and right opened range. Because, to select a left opened range of keys, we have to use a tip. Exemple : keys = [1, 2, 3, 4, 5] to select where 2key We have to do : startkey=2skip=1 But : If keys are no unique, the skip tip no more works. Ex: keys = [1, 2, 2, 3, 4, 5] The request startkey=2skip=1 doesn't work because a 2 key is returned. (ps: non unique keys can be a wanted result) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (COUCHDB-1631) Require admin privileges to read _all_dbs
[ https://issues.apache.org/jira/browse/COUCHDB-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet resolved COUCHDB-1631. -- Resolution: Won't Fix Looks like consensus is that we want _all_dbs to show just those databases to which you have access. I'm going to open a new ticket for this feature request so we can leave this patch (and confusing discussion) behind. Require admin privileges to read _all_dbs - Key: COUCHDB-1631 URL: https://issues.apache.org/jira/browse/COUCHDB-1631 Project: CouchDB Issue Type: New Feature Components: HTTP Interface Reporter: Dave Cottlehuber Attachments: force_admins_only_for_all_dbs.diff The patch for this is straightforwards, I think that this should actually be the default behaviour in future. Comments? Note to self, docs, tests required once discussion is settled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (COUCHDB-2319) _all_dbs should only list databases to which the user has access
Joan Touzet created COUCHDB-2319:
Summary: _all_dbs should only list databases to which the user has
access
Key: COUCHDB-2319
URL: https://issues.apache.org/jira/browse/COUCHDB-2319
Project: CouchDB
Issue Type: Improvement
Security Level: public (Regular issues)
Components: Database Core
Reporter: Joan Touzet
C.f. discussion around COUCHDB-1631.
On a GET /_all_dbs:
* If you are an admin, or if CouchDB is in admin party, you should be able
to see all databases.
* If you are a user or unauthenticated, you should only see those databases
for which you have read access.
* If you are a user with access to no databases, or unauthenticated and no
databases are publicly readalbe, we can return an empty set, or optionally the
same error message as today , such as
{code:javascript}
{error:unauthorized,reason:You have access to no databases.}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (COUCHDB-2296) Possible non-free software included
[ https://issues.apache.org/jira/browse/COUCHDB-2296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14101640#comment-14101640 ] Joan Touzet commented on COUCHDB-2296: -- Thanks for the report. As far as I can tell, base64.js is used in the old JavaScript test library only. CouchDB 2.0 will remove futon entirely and replace it with Fauxton, which does not include this code - JS tests are run from the command line and I don't believe require base64.js any longer. I'll ask a Fauxton developer to confirm before closing this ticket. Possible non-free software included --- Key: COUCHDB-2296 URL: https://issues.apache.org/jira/browse/COUCHDB-2296 Project: CouchDB Issue Type: Bug Security Level: public(Regular issues) Reporter: Harlan Lieberman-Berg Hello, I'm writing in regards to Debian Bug [#758558|https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758558]. It seems that the file share/www/script/base64.js is licensed under terms that are vague enough to perhaps be unenforceable. The license matches no known open source license, and though the authors intent is clear to open source it to some extent, the question is with what restrictions. Defining it as free is not enough to meet the DFSG requirements in my mind, and I wanted to raise it to your attention in the case that it doesn't match yours either. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (COUCHDB-2287) couchdb 1.6 crash on FreeBSD 10
[
https://issues.apache.org/jira/browse/COUCHDB-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet resolved COUCHDB-2287.
--
Resolution: Invalid
{code}
File operation error: eacces. Target: /usr/local/lib/couchdb/erlang/lib.
Function: list_dir.
{code}
EACCES means the permissions are wrong on that path. Make sure that the user
who couchdb runs as, is able to access and read that directory and the files
inside of it.
couchdb 1.6 crash on FreeBSD 10
---
Key: COUCHDB-2287
URL: https://issues.apache.org/jira/browse/COUCHDB-2287
Project: CouchDB
Issue Type: Bug
Security Level: public(Regular issues)
Components: Database Core
Affects Versions: 1.6.0
Environment: FreeBSD 10 Erlang 17
Reporter: Edison Chindrawaly
Dear All,
I am using FreeBSD 10 and I install couchdb 1.6 from port without any
problem. However upon starting couchdb using service couchdb start, it
crashed without having a specific reason.
I looked for answer in google and many says due to permission in all the
folders of couchdb /var/{run log db}/couchdb and /usr/local/lib/couchdb - I
set them all to couchdb and set mod to 770 as many of results in google.
However the couchdb won't start either.
I tried to run as normal user (not couchdb user) and it will give me this
error.
{error_logger,{{2014,7,30},{10,15,44}},std_error,File operation error:
eacces. Target: /usr/local/lib/couchdb/erlang/lib. Function: list_dir.
Process: code_server.}
=ERROR REPORT 30-Jul-2014::17:15:44 ===
File operation error: eacces. Target: /usr/local/lib/couchdb/erlang/lib.
Function: list_dir. Process: code_server.
{init terminating in
do_boot,{undef,[{couch,start,[],[]},{init,start_it,1,[]},{init,start_em,1,[]}]}}
if I ran as root (service couchdb start) - it won't give me that error above,
it just simply crash with
heart_beat_kill_pid = 542
heart_beat_timeout = 11
heart: Wed Jul 30 10:00:24 2014: Erlang is crashing .. (waiting for crash
dump file)
heart: Wed Jul 30 10:00:25 2014: Executed /usr/local/bin/couchdb -k - 0.
Terminating.
-
Any idea?
Thanks in advance
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (COUCHDB-2287) couchdb 1.6 crash on FreeBSD 10
[
https://issues.apache.org/jira/browse/COUCHDB-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet closed COUCHDB-2287.
couchdb 1.6 crash on FreeBSD 10
---
Key: COUCHDB-2287
URL: https://issues.apache.org/jira/browse/COUCHDB-2287
Project: CouchDB
Issue Type: Bug
Security Level: public(Regular issues)
Components: Database Core
Affects Versions: 1.6.0
Environment: FreeBSD 10 Erlang 17
Reporter: Edison Chindrawaly
Dear All,
I am using FreeBSD 10 and I install couchdb 1.6 from port without any
problem. However upon starting couchdb using service couchdb start, it
crashed without having a specific reason.
I looked for answer in google and many says due to permission in all the
folders of couchdb /var/{run log db}/couchdb and /usr/local/lib/couchdb - I
set them all to couchdb and set mod to 770 as many of results in google.
However the couchdb won't start either.
I tried to run as normal user (not couchdb user) and it will give me this
error.
{error_logger,{{2014,7,30},{10,15,44}},std_error,File operation error:
eacces. Target: /usr/local/lib/couchdb/erlang/lib. Function: list_dir.
Process: code_server.}
=ERROR REPORT 30-Jul-2014::17:15:44 ===
File operation error: eacces. Target: /usr/local/lib/couchdb/erlang/lib.
Function: list_dir. Process: code_server.
{init terminating in
do_boot,{undef,[{couch,start,[],[]},{init,start_it,1,[]},{init,start_em,1,[]}]}}
if I ran as root (service couchdb start) - it won't give me that error above,
it just simply crash with
heart_beat_kill_pid = 542
heart_beat_timeout = 11
heart: Wed Jul 30 10:00:24 2014: Erlang is crashing .. (waiting for crash
dump file)
heart: Wed Jul 30 10:00:25 2014: Executed /usr/local/bin/couchdb -k - 0.
Terminating.
-
Any idea?
Thanks in advance
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (COUCHDB-2270) Contribute Cloudant Query
Joan Touzet created COUCHDB-2270: Summary: Contribute Cloudant Query Key: COUCHDB-2270 URL: https://issues.apache.org/jira/browse/COUCHDB-2270 Project: CouchDB Issue Type: New Feature Security Level: public (Regular issues) Components: View Server Support Reporter: Joan Touzet Cloudant has announced the contribution of Cloudant Query to the Apache CouchDB project. This ticket will track that contributions progress through readiness, acceptance, review, integration, test and release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (COUCHDB-2270) Contribute Cloudant Query
[ https://issues.apache.org/jira/browse/COUCHDB-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet updated COUCHDB-2270: - Fix Version/s: 3.0.0 It is not clear that this work will land in 2.0.0 so I am currently setting the milestone to 3.0.0 (as we don't yet have a 2.0.x / 2.1.x / etc.) If we are able to pull this work into 2.0.0, great. Contribute Cloudant Query - Key: COUCHDB-2270 URL: https://issues.apache.org/jira/browse/COUCHDB-2270 Project: CouchDB Issue Type: New Feature Security Level: public(Regular issues) Components: View Server Support Reporter: Joan Touzet Fix For: 3.0.0 Cloudant has announced the contribution of Cloudant Query to the Apache CouchDB project. This ticket will track that contributions progress through readiness, acceptance, review, integration, test and release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (COUCHDB-2270) Contribute Cloudant Query
[ https://issues.apache.org/jira/browse/COUCHDB-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet updated COUCHDB-2270: - Announcement: https://cloudant.com/blog/couchdb-and-mongodb-let-our-query-apis-combine/ Contribute Cloudant Query - Key: COUCHDB-2270 URL: https://issues.apache.org/jira/browse/COUCHDB-2270 Project: CouchDB Issue Type: New Feature Security Level: public(Regular issues) Components: View Server Support Reporter: Joan Touzet Fix For: 3.0.0 Cloudant has announced the contribution of Cloudant Query to the Apache CouchDB project. This ticket will track that contributions progress through readiness, acceptance, review, integration, test and release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (COUCHDB-2267) Views suddenly stopped working with os_process_error
[
https://issues.apache.org/jira/browse/COUCHDB-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet reopened COUCHDB-2267:
--
OK, this is definitely still a bug, we'll take it from here. name= isn't valid
parameter for content_type per RFC 2616 section 3.7, but we can at least reject
the document if we see stuff in there we don't understand.
Views suddenly stopped working with os_process_error
-
Key: COUCHDB-2267
URL: https://issues.apache.org/jira/browse/COUCHDB-2267
Project: CouchDB
Issue Type: Bug
Security Level: public(Regular issues)
Components: Database Core
Reporter: Danny Thuering
Hi,
we use CouchDb for one of our projects and it worked very well till today.
Logfile shows:
{code}
[Mon, 14 Jul 2014 19:21:32 GMT] [info] [0.19826.0] 62.203.116.116 - - GET
/_config/native_query_servers/ 200
[error] [0.19843.0] OS Process Error 0.19845.0 :: {os_process_error,
{exit_status,1}}
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [0.19843.0] OS Process Error
0.19845.0 :: {os_process_error,
{exit_status,1}}
[error] [emulator] Error in process 0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [emulator] Error in process
0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
=ERROR REPORT 14-Jul-2014::19:21:32 ===
Error in process 0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
[info] [0.19822.0] 62.203.116.116 - - GET
/adsnooper/_design/unify/_view/empties?limit=11reduce=false 500
[Mon, 14 Jul 2014 19:21:32 GMT] [info] [0.19822.0] 62.203.116.116 - - GET
/adsnooper/_design/unify/_view/empties?limit=11reduce=false 500
[error] [0.19822.0] httpd 500 error response:
{error:os_process_error,reason:{exit_status,1}}
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [0.19822.0] httpd 500 error
response:
{error:os_process_error,reason:{exit_status,1}}
{code}
Tried to increase the stack memory to 1GB but this did not help.
We are running 1.5.0 on FreeBSD 9.2. Database is 210GB with 3.5M documents.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (COUCHDB-2267) UTF-8 in attachment content_type breaks views/replication
[
https://issues.apache.org/jira/browse/COUCHDB-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet updated COUCHDB-2267:
-
Summary: UTF-8 in attachment content_type breaks views/replication (was:
Views suddenly stopped working with os_process_error )
UTF-8 in attachment content_type breaks views/replication
-
Key: COUCHDB-2267
URL: https://issues.apache.org/jira/browse/COUCHDB-2267
Project: CouchDB
Issue Type: Bug
Security Level: public(Regular issues)
Components: Database Core
Reporter: Danny Thuering
Hi,
we use CouchDb for one of our projects and it worked very well till today.
Logfile shows:
{code}
[Mon, 14 Jul 2014 19:21:32 GMT] [info] [0.19826.0] 62.203.116.116 - - GET
/_config/native_query_servers/ 200
[error] [0.19843.0] OS Process Error 0.19845.0 :: {os_process_error,
{exit_status,1}}
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [0.19843.0] OS Process Error
0.19845.0 :: {os_process_error,
{exit_status,1}}
[error] [emulator] Error in process 0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [emulator] Error in process
0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
=ERROR REPORT 14-Jul-2014::19:21:32 ===
Error in process 0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
[info] [0.19822.0] 62.203.116.116 - - GET
/adsnooper/_design/unify/_view/empties?limit=11reduce=false 500
[Mon, 14 Jul 2014 19:21:32 GMT] [info] [0.19822.0] 62.203.116.116 - - GET
/adsnooper/_design/unify/_view/empties?limit=11reduce=false 500
[error] [0.19822.0] httpd 500 error response:
{error:os_process_error,reason:{exit_status,1}}
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [0.19822.0] httpd 500 error
response:
{error:os_process_error,reason:{exit_status,1}}
{code}
Tried to increase the stack memory to 1GB but this did not help.
We are running 1.5.0 on FreeBSD 9.2. Database is 210GB with 3.5M documents.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (COUCHDB-2267) UTF-8 in attachment content_type breaks views/replication
[
https://issues.apache.org/jira/browse/COUCHDB-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14067710#comment-14067710
]
Joan Touzet commented on COUCHDB-2267:
--
Thoughts from IRC:
{code}
18:32 +rnewson so..
18:32 +rnewson a 400 if the utf-8 is invalid.
18:32 +rnewson and a 400 if you add parameters
18:32 +rnewson or, more kindly, a 400 if the name parameter is not the same
as the attachment name in the url.
18:32 +rnewson still, you'd think mochi was parsing this.
{code}
UTF-8 in attachment content_type breaks views/replication
-
Key: COUCHDB-2267
URL: https://issues.apache.org/jira/browse/COUCHDB-2267
Project: CouchDB
Issue Type: Bug
Security Level: public(Regular issues)
Components: Database Core
Reporter: Danny Thuering
Hi,
we use CouchDb for one of our projects and it worked very well till today.
Logfile shows:
{code}
[Mon, 14 Jul 2014 19:21:32 GMT] [info] [0.19826.0] 62.203.116.116 - - GET
/_config/native_query_servers/ 200
[error] [0.19843.0] OS Process Error 0.19845.0 :: {os_process_error,
{exit_status,1}}
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [0.19843.0] OS Process Error
0.19845.0 :: {os_process_error,
{exit_status,1}}
[error] [emulator] Error in process 0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [emulator] Error in process
0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
=ERROR REPORT 14-Jul-2014::19:21:32 ===
Error in process 0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
[info] [0.19822.0] 62.203.116.116 - - GET
/adsnooper/_design/unify/_view/empties?limit=11reduce=false 500
[Mon, 14 Jul 2014 19:21:32 GMT] [info] [0.19822.0] 62.203.116.116 - - GET
/adsnooper/_design/unify/_view/empties?limit=11reduce=false 500
[error] [0.19822.0] httpd 500 error response:
{error:os_process_error,reason:{exit_status,1}}
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [0.19822.0] httpd 500 error
response:
{error:os_process_error,reason:{exit_status,1}}
{code}
Tried to increase the stack memory to 1GB but this did not help.
We are running 1.5.0 on FreeBSD 9.2. Database is 210GB with 3.5M documents.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (COUCHDB-1795) 1.3.x version startup script /bin/couchdb is not clearing pid file on stop
[ https://issues.apache.org/jira/browse/COUCHDB-1795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet closed COUCHDB-1795. 1.3.x version startup script /bin/couchdb is not clearing pid file on stop --- Key: COUCHDB-1795 URL: https://issues.apache.org/jira/browse/COUCHDB-1795 Project: CouchDB Issue Type: Bug Components: Infrastructure Reporter: dileep Assignee: Jan Lehnardt Priority: Blocker Fix For: 1.6.0 Taken changes from 1.2.1 to stop the service. /bin/couchdb runs in a loop checks if pid file not empty it assumes couchdb might have crashed and restarts couch. Latest start script is not clearing pid file.. so it keeps on starting couch server even after running couchdb -d -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (COUCHDB-2267) Views suddenly stopped working with os_process_error
[
https://issues.apache.org/jira/browse/COUCHDB-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet updated COUCHDB-2267:
-
Description:
Hi,
we use CouchDb for one of our projects and it worked very well till today.
Logfile shows:
[Mon, 14 Jul 2014 19:21:32 GMT] [info] [0.19826.0] 62.203.116.116 - - GET
/_config/native_query_servers/ 200
[error] [0.19843.0] OS Process Error 0.19845.0 :: {os_process_error,
{exit_status,1}}
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [0.19843.0] OS Process Error
0.19845.0 :: {os_process_error,
{exit_status,1}}
[error] [emulator] Error in process 0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [emulator] Error in process 0.19843.0
with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
=ERROR REPORT 14-Jul-2014::19:21:32 ===
Error in process 0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
[info] [0.19822.0] 62.203.116.116 - - GET
/adsnooper/_design/unify/_view/empties?limit=11reduce=false 500
[Mon, 14 Jul 2014 19:21:32 GMT] [info] [0.19822.0] 62.203.116.116 - - GET
/adsnooper/_design/unify/_view/empties?limit=11reduce=false 500
[error] [0.19822.0] httpd 500 error response:
{error:os_process_error,reason:{exit_status,1}}
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [0.19822.0] httpd 500 error response:
{error:os_process_error,reason:{exit_status,1}}
Tried to increase the stack memory to 1GB but this did not help.
We are running 1.5.0 on FreeBSD 9.2. Database is 210GB with 3.5M documents.
was:
Hi,
we use CouchDb for one of our projects and it worked very well till today.
Logfile shows:
[Mon, 14 Jul 2014 19:21:32 GMT] [info] [0.19826.0] 62.203.116.116 - - GET
/_config/native_query_servers/ 200
[error] [0.19843.0] OS Process Error 0.19845.0 :: {os_process_error,
{exit_status,1}}
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [0.19843.0] OS Process Error
0.19845.0 :: {os_process_error,
{exit_status,1}}
[error] [emulator] Error in process 0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [emulator] Error in process 0.19843.0
with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
=ERROR REPORT 14-Jul-2014::19:21:32 ===
Error in process 0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
[info] [0.19822.0] 62.203.116.116 - - GET
/adsnooper/_design/unify/_view/empties?limit=11reduce=false 500
[Mon, 14 Jul 2014 19:21:32 GMT] [info] [0.19822.0] 62.203.116.116 - - GET
/adsnooper/_design/unify/_view/empties?limit=11reduce=false 500
[error] [0.19822.0] httpd 500 error response:
{error:os_process_error,reason:{exit_status,1}}
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [0.19822.0] httpd 500 error response:
{error:os_process_error,reason:{exit_status,1}}
Tried to increase the stack memory to 1GB but this did not help.
We are running 1.5.0 on FreeBSD 9.2. Database is 210GB with 3.5M documents.
Views suddenly stopped working with os_process_error
-
Key: COUCHDB-2267
URL: https://issues.apache.org/jira/browse/COUCHDB-2267
Project: CouchDB
Issue Type: Bug
Security Level: public(Regular issues)
Components: Database Core
Reporter: Danny Thuering
Hi,
we use CouchDb for one of our projects and it worked very well till today.
Logfile shows:
[Mon, 14 Jul 2014 19:21:32 GMT] [info] [0.19826.0]
[jira] [Updated] (COUCHDB-2267) Views suddenly stopped working with os_process_error
[
https://issues.apache.org/jira/browse/COUCHDB-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet updated COUCHDB-2267:
-
Description:
Hi,
we use CouchDb for one of our projects and it worked very well till today.
Logfile shows:
{code}
[Mon, 14 Jul 2014 19:21:32 GMT] [info] [0.19826.0] 62.203.116.116 - - GET
/_config/native_query_servers/ 200
[error] [0.19843.0] OS Process Error 0.19845.0 :: {os_process_error,
{exit_status,1}}
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [0.19843.0] OS Process Error
0.19845.0 :: {os_process_error,
{exit_status,1}}
[error] [emulator] Error in process 0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [emulator] Error in process 0.19843.0
with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
=ERROR REPORT 14-Jul-2014::19:21:32 ===
Error in process 0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
[info] [0.19822.0] 62.203.116.116 - - GET
/adsnooper/_design/unify/_view/empties?limit=11reduce=false 500
[Mon, 14 Jul 2014 19:21:32 GMT] [info] [0.19822.0] 62.203.116.116 - - GET
/adsnooper/_design/unify/_view/empties?limit=11reduce=false 500
[error] [0.19822.0] httpd 500 error response:
{error:os_process_error,reason:{exit_status,1}}
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [0.19822.0] httpd 500 error response:
{error:os_process_error,reason:{exit_status,1}}
{code}
Tried to increase the stack memory to 1GB but this did not help.
We are running 1.5.0 on FreeBSD 9.2. Database is 210GB with 3.5M documents.
was:
Hi,
we use CouchDb for one of our projects and it worked very well till today.
Logfile shows:
[Mon, 14 Jul 2014 19:21:32 GMT] [info] [0.19826.0] 62.203.116.116 - - GET
/_config/native_query_servers/ 200
[error] [0.19843.0] OS Process Error 0.19845.0 :: {os_process_error,
{exit_status,1}}
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [0.19843.0] OS Process Error
0.19845.0 :: {os_process_error,
{exit_status,1}}
[error] [emulator] Error in process 0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [emulator] Error in process 0.19843.0
with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
=ERROR REPORT 14-Jul-2014::19:21:32 ===
Error in process 0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
[info] [0.19822.0] 62.203.116.116 - - GET
/adsnooper/_design/unify/_view/empties?limit=11reduce=false 500
[Mon, 14 Jul 2014 19:21:32 GMT] [info] [0.19822.0] 62.203.116.116 - - GET
/adsnooper/_design/unify/_view/empties?limit=11reduce=false 500
[error] [0.19822.0] httpd 500 error response:
{error:os_process_error,reason:{exit_status,1}}
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [0.19822.0] httpd 500 error response:
{error:os_process_error,reason:{exit_status,1}}
Tried to increase the stack memory to 1GB but this did not help.
We are running 1.5.0 on FreeBSD 9.2. Database is 210GB with 3.5M documents.
Views suddenly stopped working with os_process_error
-
Key: COUCHDB-2267
URL: https://issues.apache.org/jira/browse/COUCHDB-2267
Project: CouchDB
Issue Type: Bug
Security Level: public(Regular issues)
Components: Database Core
Reporter: Danny Thuering
Hi,
we use CouchDb for one of our projects and it worked very well till today.
Logfile shows:
{code}
[Mon, 14 Jul 2014 19:21:32 GMT]
[jira] [Commented] (COUCHDB-2267) Views suddenly stopped working with os_process_error
[
https://issues.apache.org/jira/browse/COUCHDB-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14061100#comment-14061100
]
Joan Touzet commented on COUCHDB-2267:
--
Is your couchjs dying because it's out of memory? System logs or monitoring may
indicate this. Have you tried to build couchjs 64-bit?
Views suddenly stopped working with os_process_error
-
Key: COUCHDB-2267
URL: https://issues.apache.org/jira/browse/COUCHDB-2267
Project: CouchDB
Issue Type: Bug
Security Level: public(Regular issues)
Components: Database Core
Reporter: Danny Thuering
Hi,
we use CouchDb for one of our projects and it worked very well till today.
Logfile shows:
{code}
[Mon, 14 Jul 2014 19:21:32 GMT] [info] [0.19826.0] 62.203.116.116 - - GET
/_config/native_query_servers/ 200
[error] [0.19843.0] OS Process Error 0.19845.0 :: {os_process_error,
{exit_status,1}}
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [0.19843.0] OS Process Error
0.19845.0 :: {os_process_error,
{exit_status,1}}
[error] [emulator] Error in process 0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [emulator] Error in process
0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
=ERROR REPORT 14-Jul-2014::19:21:32 ===
Error in process 0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
[info] [0.19822.0] 62.203.116.116 - - GET
/adsnooper/_design/unify/_view/empties?limit=11reduce=false 500
[Mon, 14 Jul 2014 19:21:32 GMT] [info] [0.19822.0] 62.203.116.116 - - GET
/adsnooper/_design/unify/_view/empties?limit=11reduce=false 500
[error] [0.19822.0] httpd 500 error response:
{error:os_process_error,reason:{exit_status,1}}
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [0.19822.0] httpd 500 error
response:
{error:os_process_error,reason:{exit_status,1}}
{code}
Tried to increase the stack memory to 1GB but this did not help.
We are running 1.5.0 on FreeBSD 9.2. Database is 210GB with 3.5M documents.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (COUCHDB-2267) Views suddenly stopped working with os_process_error
[
https://issues.apache.org/jira/browse/COUCHDB-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14061158#comment-14061158
]
Joan Touzet commented on COUCHDB-2267:
--
Try invoking couchjs from the command line, or using {{ldd}} on it. It may be
that a system update screwed up one of the libraries against which it compiles
(most commonly, updating the version of spidermonkey).
Views suddenly stopped working with os_process_error
-
Key: COUCHDB-2267
URL: https://issues.apache.org/jira/browse/COUCHDB-2267
Project: CouchDB
Issue Type: Bug
Security Level: public(Regular issues)
Components: Database Core
Reporter: Danny Thuering
Hi,
we use CouchDb for one of our projects and it worked very well till today.
Logfile shows:
{code}
[Mon, 14 Jul 2014 19:21:32 GMT] [info] [0.19826.0] 62.203.116.116 - - GET
/_config/native_query_servers/ 200
[error] [0.19843.0] OS Process Error 0.19845.0 :: {os_process_error,
{exit_status,1}}
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [0.19843.0] OS Process Error
0.19845.0 :: {os_process_error,
{exit_status,1}}
[error] [emulator] Error in process 0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [emulator] Error in process
0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
=ERROR REPORT 14-Jul-2014::19:21:32 ===
Error in process 0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
[info] [0.19822.0] 62.203.116.116 - - GET
/adsnooper/_design/unify/_view/empties?limit=11reduce=false 500
[Mon, 14 Jul 2014 19:21:32 GMT] [info] [0.19822.0] 62.203.116.116 - - GET
/adsnooper/_design/unify/_view/empties?limit=11reduce=false 500
[error] [0.19822.0] httpd 500 error response:
{error:os_process_error,reason:{exit_status,1}}
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [0.19822.0] httpd 500 error
response:
{error:os_process_error,reason:{exit_status,1}}
{code}
Tried to increase the stack memory to 1GB but this did not help.
We are running 1.5.0 on FreeBSD 9.2. Database is 210GB with 3.5M documents.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (COUCHDB-2267) Views suddenly stopped working with os_process_error
[
https://issues.apache.org/jira/browse/COUCHDB-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14061189#comment-14061189
]
Joan Touzet commented on COUCHDB-2267:
--
It is possible that a document somehow got into the DB that is corrupt (invalid
UTF-8). Do you have any way of pinpointing when the failures started, and
looking at documents added around that time?
Views suddenly stopped working with os_process_error
-
Key: COUCHDB-2267
URL: https://issues.apache.org/jira/browse/COUCHDB-2267
Project: CouchDB
Issue Type: Bug
Security Level: public(Regular issues)
Components: Database Core
Reporter: Danny Thuering
Hi,
we use CouchDb for one of our projects and it worked very well till today.
Logfile shows:
{code}
[Mon, 14 Jul 2014 19:21:32 GMT] [info] [0.19826.0] 62.203.116.116 - - GET
/_config/native_query_servers/ 200
[error] [0.19843.0] OS Process Error 0.19845.0 :: {os_process_error,
{exit_status,1}}
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [0.19843.0] OS Process Error
0.19845.0 :: {os_process_error,
{exit_status,1}}
[error] [emulator] Error in process 0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [emulator] Error in process
0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
=ERROR REPORT 14-Jul-2014::19:21:32 ===
Error in process 0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
[info] [0.19822.0] 62.203.116.116 - - GET
/adsnooper/_design/unify/_view/empties?limit=11reduce=false 500
[Mon, 14 Jul 2014 19:21:32 GMT] [info] [0.19822.0] 62.203.116.116 - - GET
/adsnooper/_design/unify/_view/empties?limit=11reduce=false 500
[error] [0.19822.0] httpd 500 error response:
{error:os_process_error,reason:{exit_status,1}}
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [0.19822.0] httpd 500 error
response:
{error:os_process_error,reason:{exit_status,1}}
{code}
Tried to increase the stack memory to 1GB but this did not help.
We are running 1.5.0 on FreeBSD 9.2. Database is 210GB with 3.5M documents.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (COUCHDB-2267) Views suddenly stopped working with os_process_error
[
https://issues.apache.org/jira/browse/COUCHDB-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14061218#comment-14061218
]
Joan Touzet commented on COUCHDB-2267:
--
CouchDB should be filtering out any invalid UTF-8, so letting us know how
you're getting the invalid UTF-8 in there would help a lot (client library,
replication, etc.)
jsonlint would be one way, yes. I don't know of any more expedient ways.
Views suddenly stopped working with os_process_error
-
Key: COUCHDB-2267
URL: https://issues.apache.org/jira/browse/COUCHDB-2267
Project: CouchDB
Issue Type: Bug
Security Level: public(Regular issues)
Components: Database Core
Reporter: Danny Thuering
Hi,
we use CouchDb for one of our projects and it worked very well till today.
Logfile shows:
{code}
[Mon, 14 Jul 2014 19:21:32 GMT] [info] [0.19826.0] 62.203.116.116 - - GET
/_config/native_query_servers/ 200
[error] [0.19843.0] OS Process Error 0.19845.0 :: {os_process_error,
{exit_status,1}}
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [0.19843.0] OS Process Error
0.19845.0 :: {os_process_error,
{exit_status,1}}
[error] [emulator] Error in process 0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [emulator] Error in process
0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
=ERROR REPORT 14-Jul-2014::19:21:32 ===
Error in process 0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
[info] [0.19822.0] 62.203.116.116 - - GET
/adsnooper/_design/unify/_view/empties?limit=11reduce=false 500
[Mon, 14 Jul 2014 19:21:32 GMT] [info] [0.19822.0] 62.203.116.116 - - GET
/adsnooper/_design/unify/_view/empties?limit=11reduce=false 500
[error] [0.19822.0] httpd 500 error response:
{error:os_process_error,reason:{exit_status,1}}
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [0.19822.0] httpd 500 error
response:
{error:os_process_error,reason:{exit_status,1}}
{code}
Tried to increase the stack memory to 1GB but this did not help.
We are running 1.5.0 on FreeBSD 9.2. Database is 210GB with 3.5M documents.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (COUCHDB-2267) Views suddenly stopped working with os_process_error
[
https://issues.apache.org/jira/browse/COUCHDB-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14061247#comment-14061247
]
Joan Touzet commented on COUCHDB-2267:
--
Ektorp goes through the HTTP interface so there is possibly a bug. Do let us
know when you've found the offending document(s), if that turns out to be the
issue.
Views suddenly stopped working with os_process_error
-
Key: COUCHDB-2267
URL: https://issues.apache.org/jira/browse/COUCHDB-2267
Project: CouchDB
Issue Type: Bug
Security Level: public(Regular issues)
Components: Database Core
Reporter: Danny Thuering
Hi,
we use CouchDb for one of our projects and it worked very well till today.
Logfile shows:
{code}
[Mon, 14 Jul 2014 19:21:32 GMT] [info] [0.19826.0] 62.203.116.116 - - GET
/_config/native_query_servers/ 200
[error] [0.19843.0] OS Process Error 0.19845.0 :: {os_process_error,
{exit_status,1}}
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [0.19843.0] OS Process Error
0.19845.0 :: {os_process_error,
{exit_status,1}}
[error] [emulator] Error in process 0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [emulator] Error in process
0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
=ERROR REPORT 14-Jul-2014::19:21:32 ===
Error in process 0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
[info] [0.19822.0] 62.203.116.116 - - GET
/adsnooper/_design/unify/_view/empties?limit=11reduce=false 500
[Mon, 14 Jul 2014 19:21:32 GMT] [info] [0.19822.0] 62.203.116.116 - - GET
/adsnooper/_design/unify/_view/empties?limit=11reduce=false 500
[error] [0.19822.0] httpd 500 error response:
{error:os_process_error,reason:{exit_status,1}}
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [0.19822.0] httpd 500 error
response:
{error:os_process_error,reason:{exit_status,1}}
{code}
Tried to increase the stack memory to 1GB but this did not help.
We are running 1.5.0 on FreeBSD 9.2. Database is 210GB with 3.5M documents.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (COUCHDB-2267) Views suddenly stopped working with os_process_error
[
https://issues.apache.org/jira/browse/COUCHDB-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14061292#comment-14061292
]
Joan Touzet commented on COUCHDB-2267:
--
That's basically a smoking gun right there. stale=ok working strongly suggests
that you have a corrupt document that couch passes to couchjs, which then
crashes couchjs and is holding up further indexing.
Figuring out the latest doc visible in your view should help you determine the
doc that is holding things up.
Views suddenly stopped working with os_process_error
-
Key: COUCHDB-2267
URL: https://issues.apache.org/jira/browse/COUCHDB-2267
Project: CouchDB
Issue Type: Bug
Security Level: public(Regular issues)
Components: Database Core
Reporter: Danny Thuering
Hi,
we use CouchDb for one of our projects and it worked very well till today.
Logfile shows:
{code}
[Mon, 14 Jul 2014 19:21:32 GMT] [info] [0.19826.0] 62.203.116.116 - - GET
/_config/native_query_servers/ 200
[error] [0.19843.0] OS Process Error 0.19845.0 :: {os_process_error,
{exit_status,1}}
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [0.19843.0] OS Process Error
0.19845.0 :: {os_process_error,
{exit_status,1}}
[error] [emulator] Error in process 0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [emulator] Error in process
0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
=ERROR REPORT 14-Jul-2014::19:21:32 ===
Error in process 0.19843.0 with exit value:
{{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,couch_os_process.erl},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,couch_query_servers.erl},{line,88}]},{couch_mrview_updater,'-map_docs/2-fun-0-'...
[info] [0.19822.0] 62.203.116.116 - - GET
/adsnooper/_design/unify/_view/empties?limit=11reduce=false 500
[Mon, 14 Jul 2014 19:21:32 GMT] [info] [0.19822.0] 62.203.116.116 - - GET
/adsnooper/_design/unify/_view/empties?limit=11reduce=false 500
[error] [0.19822.0] httpd 500 error response:
{error:os_process_error,reason:{exit_status,1}}
[Mon, 14 Jul 2014 19:21:32 GMT] [error] [0.19822.0] httpd 500 error
response:
{error:os_process_error,reason:{exit_status,1}}
{code}
Tried to increase the stack memory to 1GB but this did not help.
We are running 1.5.0 on FreeBSD 9.2. Database is 210GB with 3.5M documents.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (COUCHDB-1415) Re-insering a document silently fails after compact is executed
[
https://issues.apache.org/jira/browse/COUCHDB-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet updated COUCHDB-1415:
-
Fix Version/s: 2.0.0
Re-insering a document silently fails after compact is executed
---
Key: COUCHDB-1415
URL: https://issues.apache.org/jira/browse/COUCHDB-1415
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 1.1.1
Environment: Tested on multiple linux platforms
Reporter: Viktor Szabo
Assignee: Paul Joseph Davis
Fix For: 2.0.0
Attachments: patch
When a document is re-inserted after a compact operation using the same
contents it was originally created, the insert operation is silently ignored,
leaving the client unaware of the fact it's document is not available in the
database.
Can be reproduced using the following sequence of steps:
alias curl='curl -H Content-Type: application/json'
url=http://localhost:5984/database;
1 curl -X PUT $url
2 curl -X POST $url -d '{_id: bug, key: value}'
3 curl -X DELETE $url/bug?rev=1-59414e77c768bc202142ac82c2f129de
4 curl -X POST $url/_compact
5 curl -X POST $url -d '{_id: bug, key: value}'
6 curl -X GET $url/bug
(bug here)
1 {ok:true}
201
2 [{ok:true,id:bug,rev:1-59414e77c768bc202142ac82c2f129de}]
201
3 {ok:true,id:bug,rev:2-9b2e3bcc3752a3a952a3570b2ed4d27e}
200
4 {ok:true}
202
5 [{ok:true,id:bug,rev:1-59414e77c768bc202142ac82c2f129de}]
201
6 {error:not_found,reason:deleted}
404
CouchDB shouldn't report ok on step 5 and then go on to claim that the doc
is deleted. Also, it seems to work on second try:
7 curl -X POST $url -d '{_id: bug, key: value}'
8 curl -X GET $url/bug
7 {ok:true,id:bug,rev:3-674f864b73df1c80925e48436e21d550}
201
8 {_id:bug,_rev:3-674f864b73df1c80925e48436e21d550,key:value}
200
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (COUCHDB-2258) CouchDB 1.6.0 returns wrong Content-Type
[ https://issues.apache.org/jira/browse/COUCHDB-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet resolved COUCHDB-2258. -- Resolution: Duplicate This is a duplicate of COUCHDB-1175. Please read the history there to get a better sense of why this is an intractable problem at scale. CouchDB 1.6.0 returns wrong Content-Type Key: COUCHDB-2258 URL: https://issues.apache.org/jira/browse/COUCHDB-2258 Project: CouchDB Issue Type: Bug Security Level: public(Regular issues) Components: HTTP Interface Reporter: Kaj Nielsen CouchDB returns JSON documents. So the Content-Type set by CouchDB should be application/json. Instead: GET /db/doc HTTP/1.1 Host: localhost:5984 HTTP/1.1 200 OK Server: CouchDB/1.6.0 (Erlang OTP/R15B01) ETag: 167-37f82fdbfdc49d38b1c66815deb1e338 Date: Tue, 24 Jun 2014 22:26:39 GMT Content-Type: text/plain; charset=utf-8 Content-Length: 649 Cache-Control: must-revalidate ... As seen above, CouchDB returns text/plain. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (COUCHDB-2261) CouchDB 1.6.0 returns wrong Cache-Control header
[ https://issues.apache.org/jira/browse/COUCHDB-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet closed COUCHDB-2261. Resolution: Duplicate Duplicate of COUCHDB-2260 CouchDB 1.6.0 returns wrong Cache-Control header Key: COUCHDB-2261 URL: https://issues.apache.org/jira/browse/COUCHDB-2261 Project: CouchDB Issue Type: Bug Security Level: public(Regular issues) Components: HTTP Interface Reporter: Kaj Nielsen CouchDB returns must-revalidate in all responses. This does not mean what you think it means. Modern HTTP caches will happily return cached copies of must-revalidate items without consulting the backend server. According to the RFC: Section 14.9.4 of HTTP/1.1: When the must-revalidate directive is present in a response received by a cache, that cache MUST NOT use the entry after it becomes stale to respond to a subsequent request without first revalidating it with the origin server Section 14.8 of HTTP/1.1: If the response includes the must-revalidate cache-control directive, the cache MAY use that response in replying to a subsequent request. But if the response is stale, all caches MUST first revalidate it with the origin server... Meaning that the cache may serve the item without revalidation as long as the response is not stale yet. When is the response stale? Regarding staleness, see for example RFC5861: == A response containing: Cache-Control: max-age=600, ... indicates that it is fresh for 600 seconds == Meaning that the content goes stale after the max-age expires. Since CouchDB does not set a max-age, the cache may assume that the content does not go stale, and thus that must-revalidate is irrelevant. Which is exactly what Varnish does when you stick it in front of CouchDB. Correct solution is to set either: * Cache-Control: max-age=0, must-revalidate Or: * Cache-Control: no-cache The latter meaning that the cache must also refresh on each request (but is free to use conditional GETs if it wishes) - see RFC. See also: https://stackoverflow.com/questions/7573466/is-cache-controlmust-revalidate-obliging-to-validate-all-requests-or-just-the -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (COUCHDB-2091) Add a configurable whitelist of user document properties
[ https://issues.apache.org/jira/browse/COUCHDB-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet closed COUCHDB-2091. Add a configurable whitelist of user document properties Key: COUCHDB-2091 URL: https://issues.apache.org/jira/browse/COUCHDB-2091 Project: CouchDB Issue Type: Improvement Security Level: public(Regular issues) Components: BigCouch Reporter: Paul Joseph Davis Assignee: Joan Touzet Labels: merge Check for regressions -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (COUCHDB-2255) Running the test suite errors out with [error] [0.348.0] OS Process Error 0.354.0
[
https://issues.apache.org/jira/browse/COUCHDB-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14027995#comment-14027995
]
Joan Touzet commented on COUCHDB-2255:
--
This looks like a CouchJS problem. Can you paste the output of ldd
/path/to/couchjs as well as trying this command: /path/to/couchjs
/path/to/main.js
Running the test suite errors out with [error] [0.348.0] OS Process Error
0.354.0
-
Key: COUCHDB-2255
URL: https://issues.apache.org/jira/browse/COUCHDB-2255
Project: CouchDB
Issue Type: Bug
Security Level: public(Regular issues)
Components: Test Suite
Reporter: Ajay Gourneni
Running the Basic test suite errors out with [error] [0.348.0] OS Process
Error 0.354.0 right after the Starting index update for db: test_suite_db
idx. Please see the log below.
could you please help us with this and let us know if we are doing anything
wrongly?
We are running Couchdb 1.5.0 on RHEL installed from source with JS 1.85.
[Wed, 11 Jun 2014 14:38:03 GMT] [info] [0.32.0] Apache CouchDB has started
on http://0.0.0.0:5984/
[Wed, 11 Jun 2014 14:40:31 GMT] [info] [0.143.0] 10.145.97.90 - - GET
/_utils/couch_tests.html?script/couch_tests.js 200
[Wed, 11 Jun 2014 14:40:31 GMT] [info] [0.143.0] 10.145.97.90 - - GET
/_utils/style/layout.css?0.11.0 200
[Wed, 11 Jun 2014 14:40:31 GMT] [info] [0.143.0] 10.145.97.90 - - GET
/_session 200
[Wed, 11 Jun 2014 14:40:31 GMT] [info] [0.295.0] 10.145.97.90 - - GET / 200
[Wed, 11 Jun 2014 14:40:34 GMT] [info] [0.143.0] 10.145.97.90 - - GET
/_session 200
[Wed, 11 Jun 2014 14:40:34 GMT] [info] [0.143.0] 10.145.97.90 - - GET / 200
[Wed, 11 Jun 2014 14:40:34 GMT] [info] [0.143.0] 10.145.97.90 - - DELETE
/test_suite_db/ 200
[Wed, 11 Jun 2014 14:40:35 GMT] [info] [0.143.0] 10.145.97.90 - - DELETE
/test_suite_db/ 404
[Wed, 11 Jun 2014 14:40:35 GMT] [info] [0.143.0] 10.145.97.90 - - PUT
/test_suite_db/ 201
[Wed, 11 Jun 2014 14:40:35 GMT] [info] [0.143.0] 10.145.97.90 - - PUT
/test_suite_db/ 412
[Wed, 11 Jun 2014 14:40:35 GMT] [info] [0.143.0] 10.145.97.90 - - DELETE
/test_suite_db 200
[Wed, 11 Jun 2014 14:40:35 GMT] [info] [0.143.0] 10.145.97.90 - - PUT
/test_suite_db 201
[Wed, 11 Jun 2014 14:40:36 GMT] [info] [0.143.0] 10.145.97.90 - - DELETE
/test_suite_db%2Fwith_slashes 200
[Wed, 11 Jun 2014 14:40:36 GMT] [info] [0.143.0] 10.145.97.90 - - PUT
/test_suite_db%2Fwith_slashes 201
[Wed, 11 Jun 2014 14:40:36 GMT] [info] [0.143.0] 10.145.97.90 - - GET
/test_suite_db/ 200
[Wed, 11 Jun 2014 14:40:37 GMT] [info] [0.143.0] 10.145.97.90 - - GET
/_all_dbs 200
[Wed, 11 Jun 2014 14:40:37 GMT] [info] [0.143.0] 10.145.97.90 - - GET
/test_suite_db/ 200
[Wed, 11 Jun 2014 14:40:37 GMT] [info] [0.143.0] 10.145.97.90 - - PUT
/test_suite_db/0 201
[Wed, 11 Jun 2014 14:40:37 GMT] [info] [0.143.0] 10.145.97.90 - - GET
/test_suite_db/0?revs_info=true 200
[Wed, 11 Jun 2014 14:40:37 GMT] [info] [0.143.0] 10.145.97.90 - - GET
/test_suite_db/0?local_seq=true 200
[Wed, 11 Jun 2014 14:40:38 GMT] [info] [0.143.0] 10.145.97.90 - - PUT
/test_suite_db/1 201
[Wed, 11 Jun 2014 14:40:38 GMT] [info] [0.143.0] 10.145.97.90 - - PUT
/test_suite_db/2 201
[Wed, 11 Jun 2014 14:40:38 GMT] [info] [0.143.0] 10.145.97.90 - - PUT
/test_suite_db/3 201
[Wed, 11 Jun 2014 14:40:38 GMT] [info] [0.143.0] 10.145.97.90 - - GET
/test_suite_db/ 200
[Wed, 11 Jun 2014 14:40:38 GMT] [info] [0.143.0] 10.145.97.90 - - PUT
/test_suite_db/COUCHDB-954 201
[Wed, 11 Jun 2014 14:40:39 GMT] [info] [0.143.0] 10.145.97.90 - - PUT
/test_suite_db/COUCHDB-954 201
[Wed, 11 Jun 2014 14:40:39 GMT] [info] [0.143.0] 10.145.97.90 - - GET
/test_suite_db/COUCHDB-954?open_revs=%5B%221-23202479633c2b380f79507a776743d5%22%2C%222-31ac920bb936ec9e0c2c84b56d04d890%22%5D
200
[Wed, 11 Jun 2014 14:40:39 GMT] [info] [0.143.0] 10.145.97.90 - - GET
/test_suite_db/COUCHDB-954?open_revs=%5B%221-23202479633c2b380f79507a776743d5%22%2C%222-31ac920bb936ec9e0c2c84b56d04d890%22%5Dlatest=true
200
[Wed, 11 Jun 2014 14:40:39 GMT] [info] [0.143.0] 10.145.97.90 - - GET
/test_suite_db/COUCHDB-954?open_revs=%5B%221-23202479633c2b380f79507a776743d5%22%5Dlatest=true
200
[Wed, 11 Jun 2014 14:40:39 GMT] [info] [0.143.0] 10.145.97.90 - - PUT
/test_suite_db/COUCHDB-954 200
[Wed, 11 Jun 2014 14:40:40 GMT] [info] [0.338.0] Opening index for db:
test_suite_db idx: 767f605380e963a6602ba439cf18f4a6 sig:
ac9569796d8030aaf02081b24d8b9a93
[Wed, 11 Jun 2014 14:40:40 GMT] [info] [0.343.0] Starting index update for
db: test_suite_db idx: 767f605380e963a6602ba439cf18f4a6
[Wed, 11 Jun 2014 14:40:40 GMT] [error] [0.348.0] OS Process Error
0.350.0 :: {os_process_error,
{exit_status,127}}
[jira] [Resolved] (COUCHDB-2255) Running the test suite errors out with [error] [0.348.0] OS Process Error 0.354.0
[ https://issues.apache.org/jira/browse/COUCHDB-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet resolved COUCHDB-2255. -- Resolution: Invalid So it looks like your couchjs binary is dynamically linked against libmozjs185 but the dynamic linker can't find that library. You'll need to update your dynamic linker config to know where that library is (see OS documentation) or you can set LD_LIBRARY_PATH in your environment to include a path to the library. Running the test suite errors out with [error] [0.348.0] OS Process Error 0.354.0 - Key: COUCHDB-2255 URL: https://issues.apache.org/jira/browse/COUCHDB-2255 Project: CouchDB Issue Type: Bug Security Level: public(Regular issues) Components: Test Suite Reporter: Ajay Gourneni Running the Basic test suite errors out with [error] [0.348.0] OS Process Error 0.354.0 right after the Starting index update for db: test_suite_db idx. Please see the log below. could you please help us with this and let us know if we are doing anything wrongly? We are running Couchdb 1.5.0 on RHEL installed from source with JS 1.85. [Wed, 11 Jun 2014 14:38:03 GMT] [info] [0.32.0] Apache CouchDB has started on http://0.0.0.0:5984/ [Wed, 11 Jun 2014 14:40:31 GMT] [info] [0.143.0] 10.145.97.90 - - GET /_utils/couch_tests.html?script/couch_tests.js 200 [Wed, 11 Jun 2014 14:40:31 GMT] [info] [0.143.0] 10.145.97.90 - - GET /_utils/style/layout.css?0.11.0 200 [Wed, 11 Jun 2014 14:40:31 GMT] [info] [0.143.0] 10.145.97.90 - - GET /_session 200 [Wed, 11 Jun 2014 14:40:31 GMT] [info] [0.295.0] 10.145.97.90 - - GET / 200 [Wed, 11 Jun 2014 14:40:34 GMT] [info] [0.143.0] 10.145.97.90 - - GET /_session 200 [Wed, 11 Jun 2014 14:40:34 GMT] [info] [0.143.0] 10.145.97.90 - - GET / 200 [Wed, 11 Jun 2014 14:40:34 GMT] [info] [0.143.0] 10.145.97.90 - - DELETE /test_suite_db/ 200 [Wed, 11 Jun 2014 14:40:35 GMT] [info] [0.143.0] 10.145.97.90 - - DELETE /test_suite_db/ 404 [Wed, 11 Jun 2014 14:40:35 GMT] [info] [0.143.0] 10.145.97.90 - - PUT /test_suite_db/ 201 [Wed, 11 Jun 2014 14:40:35 GMT] [info] [0.143.0] 10.145.97.90 - - PUT /test_suite_db/ 412 [Wed, 11 Jun 2014 14:40:35 GMT] [info] [0.143.0] 10.145.97.90 - - DELETE /test_suite_db 200 [Wed, 11 Jun 2014 14:40:35 GMT] [info] [0.143.0] 10.145.97.90 - - PUT /test_suite_db 201 [Wed, 11 Jun 2014 14:40:36 GMT] [info] [0.143.0] 10.145.97.90 - - DELETE /test_suite_db%2Fwith_slashes 200 [Wed, 11 Jun 2014 14:40:36 GMT] [info] [0.143.0] 10.145.97.90 - - PUT /test_suite_db%2Fwith_slashes 201 [Wed, 11 Jun 2014 14:40:36 GMT] [info] [0.143.0] 10.145.97.90 - - GET /test_suite_db/ 200 [Wed, 11 Jun 2014 14:40:37 GMT] [info] [0.143.0] 10.145.97.90 - - GET /_all_dbs 200 [Wed, 11 Jun 2014 14:40:37 GMT] [info] [0.143.0] 10.145.97.90 - - GET /test_suite_db/ 200 [Wed, 11 Jun 2014 14:40:37 GMT] [info] [0.143.0] 10.145.97.90 - - PUT /test_suite_db/0 201 [Wed, 11 Jun 2014 14:40:37 GMT] [info] [0.143.0] 10.145.97.90 - - GET /test_suite_db/0?revs_info=true 200 [Wed, 11 Jun 2014 14:40:37 GMT] [info] [0.143.0] 10.145.97.90 - - GET /test_suite_db/0?local_seq=true 200 [Wed, 11 Jun 2014 14:40:38 GMT] [info] [0.143.0] 10.145.97.90 - - PUT /test_suite_db/1 201 [Wed, 11 Jun 2014 14:40:38 GMT] [info] [0.143.0] 10.145.97.90 - - PUT /test_suite_db/2 201 [Wed, 11 Jun 2014 14:40:38 GMT] [info] [0.143.0] 10.145.97.90 - - PUT /test_suite_db/3 201 [Wed, 11 Jun 2014 14:40:38 GMT] [info] [0.143.0] 10.145.97.90 - - GET /test_suite_db/ 200 [Wed, 11 Jun 2014 14:40:38 GMT] [info] [0.143.0] 10.145.97.90 - - PUT /test_suite_db/COUCHDB-954 201 [Wed, 11 Jun 2014 14:40:39 GMT] [info] [0.143.0] 10.145.97.90 - - PUT /test_suite_db/COUCHDB-954 201 [Wed, 11 Jun 2014 14:40:39 GMT] [info] [0.143.0] 10.145.97.90 - - GET /test_suite_db/COUCHDB-954?open_revs=%5B%221-23202479633c2b380f79507a776743d5%22%2C%222-31ac920bb936ec9e0c2c84b56d04d890%22%5D 200 [Wed, 11 Jun 2014 14:40:39 GMT] [info] [0.143.0] 10.145.97.90 - - GET /test_suite_db/COUCHDB-954?open_revs=%5B%221-23202479633c2b380f79507a776743d5%22%2C%222-31ac920bb936ec9e0c2c84b56d04d890%22%5Dlatest=true 200 [Wed, 11 Jun 2014 14:40:39 GMT] [info] [0.143.0] 10.145.97.90 - - GET /test_suite_db/COUCHDB-954?open_revs=%5B%221-23202479633c2b380f79507a776743d5%22%5Dlatest=true 200 [Wed, 11 Jun 2014 14:40:39 GMT] [info] [0.143.0] 10.145.97.90 - - PUT /test_suite_db/COUCHDB-954 200 [Wed, 11 Jun 2014 14:40:40 GMT] [info] [0.338.0] Opening index for db: test_suite_db idx: 767f605380e963a6602ba439cf18f4a6 sig: ac9569796d8030aaf02081b24d8b9a93 [Wed, 11 Jun 2014 14:40:40 GMT] [info] [0.343.0] Starting index update for db: test_suite_db idx: 767f605380e963a6602ba439cf18f4a6 [Wed, 11 Jun 2014 14:40:40 GMT]
[jira] [Resolved] (COUCHDB-2255) Running the test suite errors out with [error] [0.348.0] OS Process Error 0.354.0
[ https://issues.apache.org/jira/browse/COUCHDB-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet resolved COUCHDB-2255. -- Resolution: Invalid You need the LD_LIBRARY_PATH to be set within the process from which you launch CouchDB, which means changing your startup script or editing /etc/ld.so.conf appropriately (on Linux). Please if possible move this question to our user or dev mailing lists. This is not a CouchDB bug. Running the test suite errors out with [error] [0.348.0] OS Process Error 0.354.0 - Key: COUCHDB-2255 URL: https://issues.apache.org/jira/browse/COUCHDB-2255 Project: CouchDB Issue Type: Bug Security Level: public(Regular issues) Components: Test Suite Reporter: Ajay Gourneni Running the Basic test suite errors out with [error] [0.348.0] OS Process Error 0.354.0 right after the Starting index update for db: test_suite_db idx. Please see the log below. could you please help us with this and let us know if we are doing anything wrongly? We are running Couchdb 1.5.0 on RHEL installed from source with JS 1.85. [Wed, 11 Jun 2014 14:38:03 GMT] [info] [0.32.0] Apache CouchDB has started on http://0.0.0.0:5984/ [Wed, 11 Jun 2014 14:40:31 GMT] [info] [0.143.0] 10.145.97.90 - - GET /_utils/couch_tests.html?script/couch_tests.js 200 [Wed, 11 Jun 2014 14:40:31 GMT] [info] [0.143.0] 10.145.97.90 - - GET /_utils/style/layout.css?0.11.0 200 [Wed, 11 Jun 2014 14:40:31 GMT] [info] [0.143.0] 10.145.97.90 - - GET /_session 200 [Wed, 11 Jun 2014 14:40:31 GMT] [info] [0.295.0] 10.145.97.90 - - GET / 200 [Wed, 11 Jun 2014 14:40:34 GMT] [info] [0.143.0] 10.145.97.90 - - GET /_session 200 [Wed, 11 Jun 2014 14:40:34 GMT] [info] [0.143.0] 10.145.97.90 - - GET / 200 [Wed, 11 Jun 2014 14:40:34 GMT] [info] [0.143.0] 10.145.97.90 - - DELETE /test_suite_db/ 200 [Wed, 11 Jun 2014 14:40:35 GMT] [info] [0.143.0] 10.145.97.90 - - DELETE /test_suite_db/ 404 [Wed, 11 Jun 2014 14:40:35 GMT] [info] [0.143.0] 10.145.97.90 - - PUT /test_suite_db/ 201 [Wed, 11 Jun 2014 14:40:35 GMT] [info] [0.143.0] 10.145.97.90 - - PUT /test_suite_db/ 412 [Wed, 11 Jun 2014 14:40:35 GMT] [info] [0.143.0] 10.145.97.90 - - DELETE /test_suite_db 200 [Wed, 11 Jun 2014 14:40:35 GMT] [info] [0.143.0] 10.145.97.90 - - PUT /test_suite_db 201 [Wed, 11 Jun 2014 14:40:36 GMT] [info] [0.143.0] 10.145.97.90 - - DELETE /test_suite_db%2Fwith_slashes 200 [Wed, 11 Jun 2014 14:40:36 GMT] [info] [0.143.0] 10.145.97.90 - - PUT /test_suite_db%2Fwith_slashes 201 [Wed, 11 Jun 2014 14:40:36 GMT] [info] [0.143.0] 10.145.97.90 - - GET /test_suite_db/ 200 [Wed, 11 Jun 2014 14:40:37 GMT] [info] [0.143.0] 10.145.97.90 - - GET /_all_dbs 200 [Wed, 11 Jun 2014 14:40:37 GMT] [info] [0.143.0] 10.145.97.90 - - GET /test_suite_db/ 200 [Wed, 11 Jun 2014 14:40:37 GMT] [info] [0.143.0] 10.145.97.90 - - PUT /test_suite_db/0 201 [Wed, 11 Jun 2014 14:40:37 GMT] [info] [0.143.0] 10.145.97.90 - - GET /test_suite_db/0?revs_info=true 200 [Wed, 11 Jun 2014 14:40:37 GMT] [info] [0.143.0] 10.145.97.90 - - GET /test_suite_db/0?local_seq=true 200 [Wed, 11 Jun 2014 14:40:38 GMT] [info] [0.143.0] 10.145.97.90 - - PUT /test_suite_db/1 201 [Wed, 11 Jun 2014 14:40:38 GMT] [info] [0.143.0] 10.145.97.90 - - PUT /test_suite_db/2 201 [Wed, 11 Jun 2014 14:40:38 GMT] [info] [0.143.0] 10.145.97.90 - - PUT /test_suite_db/3 201 [Wed, 11 Jun 2014 14:40:38 GMT] [info] [0.143.0] 10.145.97.90 - - GET /test_suite_db/ 200 [Wed, 11 Jun 2014 14:40:38 GMT] [info] [0.143.0] 10.145.97.90 - - PUT /test_suite_db/COUCHDB-954 201 [Wed, 11 Jun 2014 14:40:39 GMT] [info] [0.143.0] 10.145.97.90 - - PUT /test_suite_db/COUCHDB-954 201 [Wed, 11 Jun 2014 14:40:39 GMT] [info] [0.143.0] 10.145.97.90 - - GET /test_suite_db/COUCHDB-954?open_revs=%5B%221-23202479633c2b380f79507a776743d5%22%2C%222-31ac920bb936ec9e0c2c84b56d04d890%22%5D 200 [Wed, 11 Jun 2014 14:40:39 GMT] [info] [0.143.0] 10.145.97.90 - - GET /test_suite_db/COUCHDB-954?open_revs=%5B%221-23202479633c2b380f79507a776743d5%22%2C%222-31ac920bb936ec9e0c2c84b56d04d890%22%5Dlatest=true 200 [Wed, 11 Jun 2014 14:40:39 GMT] [info] [0.143.0] 10.145.97.90 - - GET /test_suite_db/COUCHDB-954?open_revs=%5B%221-23202479633c2b380f79507a776743d5%22%5Dlatest=true 200 [Wed, 11 Jun 2014 14:40:39 GMT] [info] [0.143.0] 10.145.97.90 - - PUT /test_suite_db/COUCHDB-954 200 [Wed, 11 Jun 2014 14:40:40 GMT] [info] [0.338.0] Opening index for db: test_suite_db idx: 767f605380e963a6602ba439cf18f4a6 sig: ac9569796d8030aaf02081b24d8b9a93 [Wed, 11 Jun 2014 14:40:40 GMT] [info] [0.343.0] Starting index update for db: test_suite_db idx: 767f605380e963a6602ba439cf18f4a6 [Wed, 11 Jun 2014 14:40:40 GMT] [error] [0.348.0] OS Process Error
[jira] [Closed] (COUCHDB-68) Add bi-directional replication
[ https://issues.apache.org/jira/browse/COUCHDB-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet closed COUCHDB-68. -- Add bi-directional replication -- Key: COUCHDB-68 URL: https://issues.apache.org/jira/browse/COUCHDB-68 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Environment: All Reporter: Jan Lehnardt Assignee: Jan Lehnardt Priority: Trivial Add a API call that triggers two unidirectional replications from A to B and B to A. No guarantees about atomicity are made. This is pure syntactic sugar. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (COUCHDB-476) Futon needs to remember rows per page.
[ https://issues.apache.org/jira/browse/COUCHDB-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet resolved COUCHDB-476. - Resolution: Won't Fix Assignee: Joan Touzet (was: Sam Bisbee) Futon will be EOL'ed in favour of Fauxton. If Fauxton does not remember number of rows per page, we should create a new ticket to cover that request. Futon needs to remember rows per page. -- Key: COUCHDB-476 URL: https://issues.apache.org/jira/browse/COUCHDB-476 Project: CouchDB Issue Type: Improvement Components: Futon Environment: * Reporter: Simon Thulbourn Assignee: Joan Touzet Priority: Trivial Attachments: 0001-Remember-rows-per-page-across-all-database.html-disp.patch, cookie.diff Original Estimate: 48h Remaining Estimate: 48h It would be nice if futon remembered the rows per page selection for every time you used it. This would be trivial to do, by using a cookie. I'll look into it after work. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (COUCHDB-476) Futon needs to remember rows per page.
[ https://issues.apache.org/jira/browse/COUCHDB-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet closed COUCHDB-476. --- Futon needs to remember rows per page. -- Key: COUCHDB-476 URL: https://issues.apache.org/jira/browse/COUCHDB-476 Project: CouchDB Issue Type: Improvement Components: Futon Environment: * Reporter: Simon Thulbourn Assignee: Joan Touzet Priority: Trivial Attachments: 0001-Remember-rows-per-page-across-all-database.html-disp.patch, cookie.diff Original Estimate: 48h Remaining Estimate: 48h It would be nice if futon remembered the rows per page selection for every time you used it. This would be trivial to do, by using a cookie. I'll look into it after work. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (COUCHDB-1986) 04-replication-large-atts.t times out
[ https://issues.apache.org/jira/browse/COUCHDB-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet resolved COUCHDB-1986. -- Resolution: Fixed I believe this was resolved in the last checkpoint and in rc.5. 04-replication-large-atts.t times out - Key: COUCHDB-1986 URL: https://issues.apache.org/jira/browse/COUCHDB-1986 Project: CouchDB Issue Type: Bug Components: Replication Affects Versions: 1.5.0 Reporter: Jan Lehnardt Assignee: Dave Cottlehuber Fix For: 1.6.0 04-replication-large-atts.t gets stuck around 558, sometimes a little earlier or later, but it times out eventually, regardless of the timeout. I tried doubling and such. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (COUCHDB-1824) Official documentation of replication algorithm?
[ https://issues.apache.org/jira/browse/COUCHDB-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet resolved COUCHDB-1824. -- Resolution: Fixed I am marking this as done in 1.6.0; if additional enhancement is required, please open a new ticket and please call out specific things that need to be better documented than they are today. Official documentation of replication algorithm? Key: COUCHDB-1824 URL: https://issues.apache.org/jira/browse/COUCHDB-1824 Project: CouchDB Issue Type: Documentation Components: Documentation Reporter: Nathan Vander Wilt Assignee: Alexander Shorin Fix For: 1.6.0 Though it's in some ways an internal detail, it might be nice to provide a canonical description of CouchDB's replication protocol (algorithm, really) in the documentation. See links at: http://wiki.apache.org/couchdb/Replication#Protocol_Documentation -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (COUCHDB-1334) Indexer speedup (for non-native view servers)
[
https://issues.apache.org/jira/browse/COUCHDB-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet updated COUCHDB-1334:
-
Fix Version/s: (was: 1.6.0)
Indexer speedup (for non-native view servers)
-
Key: COUCHDB-1334
URL: https://issues.apache.org/jira/browse/COUCHDB-1334
Project: CouchDB
Issue Type: Improvement
Components: Database Core, JavaScript View Server, View Server
Support
Reporter: Filipe Manana
Assignee: Joan Touzet
Attachments: 0001-More-efficient-view-updater-writes.patch,
0002-More-efficient-communication-with-the-view-server.patch,
master-0002-More-efficient-communication-with-the-view-server.patch,
master-2-0002-More-efficient-communication-with-the-view-server.patch,
master-3-0002-More-efficient-communication-with-the-view-server.patch,
master-4-0002-More-efficient-communication-with-the-view-server.patch
The following 2 patches significantly improve view index generation/update
time and reduce CPU consumption.
The first patch makes the view updater's batching more efficient, by ensuring
each btree bulk insertion adds/removes a minimum of N (=100) key/value
pairts. This also makes the index file size grow not so fast with old data
(old btree nodes basically). This behaviour is already done in master/trunk
in the new indexer (by Paul Davis).
The second patch maximizes the throughput with an external view server (such
as couchjs). Basically it makes the pipe (erlang port) communication between
the Erlang VM (couch_os_process basically) and the view server more efficient
since the 2 sides spend less time block on reading from the pipe.
Here follow some benchmarks.
test database at http://fdmanana.iriscouch.com/test_db (1 million documents)
branch 1.2.x
$ echo 3 /proc/sys/vm/drop_caches
$ time curl http://localhost:5984/test_db/_design/test/_view/test1
{rows:[
{key:null,value:100}
]}
real 2m45.097s
user 0m0.006s
sys 0m0.007s
view file size: 333Mb
CPU usage:
$ sar 1 60
22:27:20 %usr %nice %sys %idle
22:27:21 38 0 12 50
()
22:28:21 39 0 13 49
Average: 39 0 13 47
branch 1.2.x + batch patch (first patch)
$ echo 3 /proc/sys/vm/drop_caches
$ time curl http://localhost:5984/test_db/_design/test/_view/test1
{rows:[
{key:null,value:100}
]}
real 2m12.736s
user 0m0.006s
sys 0m0.005s
view file size 72Mb
branch 1.2.x + batch patch + os_process patch
$ echo 3 /proc/sys/vm/drop_caches
$ time curl http://localhost:5984/test_db/_design/test/_view/test1
{rows:[
{key:null,value:100}
]}
real 1m9.330s
user 0m0.006s
sys 0m0.004s
view file size: 72Mb
CPU usage:
$ sar 1 60
22:22:55 %usr %nice %sys %idle
22:23:53 22 0 6 72
()
22:23:55 22 0 6 72
Average: 22 0 7 70
master/trunk
$ echo 3 /proc/sys/vm/drop_caches
$ time curl http://localhost:5984/test_db/_design/test/_view/test1
{rows:[
{key:null,value:100}
]}
real 1m57.296s
user 0m0.006s
sys 0m0.005s
master/trunk + os_process patch
$ echo 3 /proc/sys/vm/drop_caches
$ time curl http://localhost:5984/test_db/_design/test/_view/test1
{rows:[
{key:null,value:100}
]}
real 0m53.768s
user 0m0.006s
sys 0m0.006s
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (COUCHDB-1572) Remove support for spidermonkey versions 1.8.5
[ https://issues.apache.org/jira/browse/COUCHDB-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet updated COUCHDB-1572: - Fix Version/s: (was: 1.6.0) Remove support for spidermonkey versions 1.8.5 Key: COUCHDB-1572 URL: https://issues.apache.org/jira/browse/COUCHDB-1572 Project: CouchDB Issue Type: Improvement Components: Build System Reporter: Robert Newson Simplify build system and provide a consistent Javascript environment by ditching spidermonkey versions below 1.8.5 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (COUCHDB-1218) Better logger performance
[ https://issues.apache.org/jira/browse/COUCHDB-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet updated COUCHDB-1218: - Fix Version/s: (was: 1.6.0) Better logger performance - Key: COUCHDB-1218 URL: https://issues.apache.org/jira/browse/COUCHDB-1218 Project: CouchDB Issue Type: Improvement Reporter: Filipe Manana Assignee: Filipe Manana Attachments: 0001-Better-logger-performance.patch I made some experiments with OTP's disk_log module (available since 2001 at least) to use it to manage the log file. It turns out I got better throughput by using it. Basically it adopts a strategy similar to the asynchronous couch_file Damien described in this thread: http://mail-archives.apache.org/mod_mbox/couchdb-dev/201106.mbox/%3c5c39fb5a-0aca-4ff9-bd90-2ebecf271...@apache.org%3E Here's a benchmark with relaximation, 50 writers, 100 readers, documents of 1Kb, delayed_commits set to false and 'info' log level (default): http://graphs.mikeal.couchone.com/#/graph/9e19f6d9eeb318c70cabcf67bc013c7f The reads got a better throughput (bottom graph, easier to visualize). The patch (also attached here), which has a descriptive comment, is at: https://github.com/fdmanana/couchdb/compare/logger_perf.patch -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (COUCHDB-1377) support X-Forwarded-* headers in couch_httpd
[ https://issues.apache.org/jira/browse/COUCHDB-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet updated COUCHDB-1377: - Fix Version/s: (was: 1.6.0) support X-Forwarded-* headers in couch_httpd Key: COUCHDB-1377 URL: https://issues.apache.org/jira/browse/COUCHDB-1377 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Affects Versions: 1.1.1, 1.2 Reporter: Randall Leeds Assignee: Randall Leeds Attachments: ASF.LICENSE.NOT.GRANTED--v1-0001-COUCHDB-1377-X-Forwarded-headers-in-proxy-module.patch X-Forwarded-For, as well as X-Forwarded-Proto and X-Forwarded-Ssl, are partially supported by the couch_httpd module. However, the couch_httpd_proxy module ignores these same configuration settings when it could manipulate the headers to pass more information upstream. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (COUCHDB-1795) 1.3.x version startup script /bin/couchdb is not clearing pid file on stop
[ https://issues.apache.org/jira/browse/COUCHDB-1795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet resolved COUCHDB-1795. -- Resolution: Fixed 1.3.x version startup script /bin/couchdb is not clearing pid file on stop --- Key: COUCHDB-1795 URL: https://issues.apache.org/jira/browse/COUCHDB-1795 Project: CouchDB Issue Type: Bug Components: Infrastructure Reporter: dileep Assignee: Jan Lehnardt Priority: Blocker Fix For: 1.6.0 Taken changes from 1.2.1 to stop the service. /bin/couchdb runs in a loop checks if pid file not empty it assumes couchdb might have crashed and restarts couch. Latest start script is not clearing pid file.. so it keeps on starting couch server even after running couchdb -d -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (COUCHDB-1837) Incorrect HTTP response on attempt to update other user doc with public fields enabled
[
https://issues.apache.org/jira/browse/COUCHDB-1837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14013034#comment-14013034
]
Joan Touzet commented on COUCHDB-1837:
--
Propose we drop this from blocker to Major so that it does not block the 1.6.0
release.
Incorrect HTTP response on attempt to update other user doc with public
fields enabled
--
Key: COUCHDB-1837
URL: https://issues.apache.org/jira/browse/COUCHDB-1837
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Reporter: Alexander Shorin
Priority: Blocker
Fix For: 1.6.0
When `public_fields` are specified (see
[8d7ab8b1|https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=8d7ab8b18dd20f8785e69f4420c6f93a2edbfa60]
commit) and regular user tries to update other user doc, CouchDB return HTTP
404 Not Found request while HTTP 403 Forbidden is more expected.
Steps to reproduce:
1. Enable `public_fields`
{code}
curl -X PUT http://localhost:5984/_config/couch_httpd_auth/public_fields -d
'name,email,whatever' -H Content-Type: application/json --user
couch_admin
{code}
2. Setup some users
{code}
curl -X PUT http://localhost:5984/_users/org.couchdb.user:abc -d
'{name:abc, roles:[], type:user, password: cba}' -H
Content-Type: application/json
curl -X PUT http://localhost:5984/_users/org.couchdb.user:def -d
'{name:def, roles:[], type:user, password: fed}' -H
Content-Type: application/json
{code}
3. Now user `abc` may browse `def` doc
{code}
curl -v http://abc:cba@localhost:5984/_users/org.couchdb.user:def
HTTP/1.1 200 OK
Cache-Control: must-revalidate
Content-Length: 88
Content-Type: text/plain; charset=utf-8
Date: Fri, 21 Jun 2013 22:48:03 GMT
ETag: 1-fa20c151bb6946527d261e9ef4338923
Server: CouchDB/1.4.0+build.8d7ab8b (Erlang OTP/R16B)
{_id:org.couchdb.user:def,_rev:1-fa20c151bb6946527d261e9ef4338923,name:def}
{code}
4. Try to save `def`'s doc:
{code}
curl -v -X PUT http://abc:cba@localhost:5984/_users/org.couchdb.user:def -d
'{}' -H Content-Type: application/json
HTTP/1.1 404 Object Not Found
Server: CouchDB/1.4.0+build.8d7ab8b (Erlang OTP/R16B)
Date: Fri, 21 Jun 2013 22:49:44 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 41
Cache-Control: must-revalidate
{error:not_found,reason:missing}
{code}
Since `org.couchdb.user:def` doc is actually exists and available for direct
GET request 404 response is incorrect and confuses while HTTP 403 Forbidden
is expected.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (COUCHDB-1838) Specifying public_fields parameter discloses all user docs
[
https://issues.apache.org/jira/browse/COUCHDB-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14013035#comment-14013035
]
Joan Touzet commented on COUCHDB-1838:
--
Propose we drop this from Blocker to Major and let 1.6.0 go without it.
Specifying public_fields parameter discloses all user docs
--
Key: COUCHDB-1838
URL: https://issues.apache.org/jira/browse/COUCHDB-1838
Project: CouchDB
Issue Type: Bug
Reporter: Alexander Shorin
Priority: Blocker
Fix For: 1.6.0
When public_fields are specified it's possible to retrieve all available user
docs, no matter does they contains specified public fields or not.
0. Setup some users:
{code}
curl -X PUT http://localhost:5984/_users/org.couchdb.user:abc -d
'{name:abc, roles:[], type:user, password: cba}' -H
Content-Type: application/json
curl -X PUT http://localhost:5984/_users/org.couchdb.user:def -d
'{name:def, roles:[], type:user, password: fed}' -H
Content-Type: application/json
{code}
1. Check the old behavior without public_fields:
{code}
curl -v http://abc:cba@localhost:5984/_users/_all_docs
HTTP/1.1 403 Forbidden
Server: CouchDB/1.4.0+build.8d7ab8b (Erlang OTP/R16B)
Date: Fri, 21 Jun 2013 23:12:13 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 87
Cache-Control: must-revalidate
{error:forbidden,reason:Only admins can access _all_docs of system
databases.}
{code}
2. Specify some public fields that no one actually has:
{code}
curl -X PUT http://localhost:5984/_config/couch_httpd_auth/public_fields -d
'no_user_will_never_has_ziz_field_in_his_doc' -H Content-Type:
application/json --user couch_admin
{code}
3. Try step 1 one more time:
{code}
curl -v http://abc:cba@localhost:5984/_users/_all_docs
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Server: CouchDB/1.4.0+build.8d7ab8b (Erlang OTP/R16B)
ETag: 55N0CA8VM2Z0DQO85L1PM20XS
Date: Fri, 21 Jun 2013 23:15:05 GMT
Content-Type: text/plain; charset=utf-8
Cache-Control: must-revalidate
{total_rows:6,offset:0,rows:[
{id:_design/_auth,key:_design/_auth,value:{rev:1-619db7ba8551c0de3f3a178775509611}},
{id:org.couchdb.user:abc,key:org.couchdb.user:abc,value:{rev:1-64d299987b4df59c048171a8ab8ba951}},
{id:org.couchdb.user:def,key:org.couchdb.user:def,value:{rev:1-479a3e8a66652838706cc49544730a34}},
{id:org.couchdb.user:foo,key:org.couchdb.user:foo,value:{rev:1-3859ee3742314dcb4b4f1ffaba398c91}},
{id:org.couchdb.user:mia,key:org.couchdb.user:mia,value:{rev:1-f87f5003323e705d8c7a533cdd0a267c}},
{id:org.couchdb.user:root,key:org.couchdb.user:root,value:{rev:1-f43dadbe5e780f392a6bd283686b3704}}
]}
{code}
Same for anonymous user:
{code}
curl -v http://localhost:5984/_users/_all_docs
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Server: CouchDB/1.4.0+build.8d7ab8b (Erlang OTP/R16B)
ETag: 55N0CA8VM2Z0DQO85L1PM20XS
Date: Sat, 22 Jun 2013 00:04:17 GMT
Content-Type: text/plain; charset=utf-8
Cache-Control: must-revalidate
{total_rows:6,offset:0,rows:[
{id:_design/_auth,key:_design/_auth,value:{rev:1-619db7ba8551c0de3f3a178775509611}},
{id:org.couchdb.user:abc,key:org.couchdb.user:abc,value:{rev:1-64d299987b4df59c048171a8ab8ba951}},
{id:org.couchdb.user:def,key:org.couchdb.user:def,value:{rev:1-479a3e8a66652838706cc49544730a34}},
{id:org.couchdb.user:foo,key:org.couchdb.user:foo,value:{rev:1-3859ee3742314dcb4b4f1ffaba398c91}},
{id:org.couchdb.user:mia,key:org.couchdb.user:mia,value:{rev:1-f87f5003323e705d8c7a533cdd0a267c}},
{id:org.couchdb.user:root,key:org.couchdb.user:root,value:{rev:1-f43dadbe5e780f392a6bd283686b3704}}
]}
{code}
The problem is that with specified public_fields it's possible to retrieve
all user's names no matter has their public field or not. This behaviour a
bit violates implemented [System Database
Security|https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=e5503ff]:
[CouchDB 1.2.0 release
notes|https://blogs.apache.org/couchdb/entry/apache_couchdb_1_2_0]:
{quote}
Documents in the _users database can no longer be read by everyone
Documents in the _users databases can now only be read by the respective
authenticated user and administrators. Before, all docs were world-readable
including their password hashes and salts.
{quote}
[Security Features
Overview|http://wiki.apache.org/couchdb/Security_Features_Overview#Authentication%20database]:
{quote}
In addition, the _users database is now treated different from other
databases:
An anonymous user can only create a new document.
An authenticated user can only update their own document.
A server or database admin can access and update all documents.
Only server or database admins can create design documents and access
views and _all_docs and _changes.
{quote}
Expected behaviour when
[jira] [Updated] (COUCHDB-1838) Specifying public_fields parameter discloses all user docs
[
https://issues.apache.org/jira/browse/COUCHDB-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet updated COUCHDB-1838:
-
Priority: Major (was: Blocker)
Fix Version/s: (was: 1.6.0)
Specifying public_fields parameter discloses all user docs
--
Key: COUCHDB-1838
URL: https://issues.apache.org/jira/browse/COUCHDB-1838
Project: CouchDB
Issue Type: Bug
Reporter: Alexander Shorin
When public_fields are specified it's possible to retrieve all available user
docs, no matter does they contains specified public fields or not.
0. Setup some users:
{code}
curl -X PUT http://localhost:5984/_users/org.couchdb.user:abc -d
'{name:abc, roles:[], type:user, password: cba}' -H
Content-Type: application/json
curl -X PUT http://localhost:5984/_users/org.couchdb.user:def -d
'{name:def, roles:[], type:user, password: fed}' -H
Content-Type: application/json
{code}
1. Check the old behavior without public_fields:
{code}
curl -v http://abc:cba@localhost:5984/_users/_all_docs
HTTP/1.1 403 Forbidden
Server: CouchDB/1.4.0+build.8d7ab8b (Erlang OTP/R16B)
Date: Fri, 21 Jun 2013 23:12:13 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 87
Cache-Control: must-revalidate
{error:forbidden,reason:Only admins can access _all_docs of system
databases.}
{code}
2. Specify some public fields that no one actually has:
{code}
curl -X PUT http://localhost:5984/_config/couch_httpd_auth/public_fields -d
'no_user_will_never_has_ziz_field_in_his_doc' -H Content-Type:
application/json --user couch_admin
{code}
3. Try step 1 one more time:
{code}
curl -v http://abc:cba@localhost:5984/_users/_all_docs
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Server: CouchDB/1.4.0+build.8d7ab8b (Erlang OTP/R16B)
ETag: 55N0CA8VM2Z0DQO85L1PM20XS
Date: Fri, 21 Jun 2013 23:15:05 GMT
Content-Type: text/plain; charset=utf-8
Cache-Control: must-revalidate
{total_rows:6,offset:0,rows:[
{id:_design/_auth,key:_design/_auth,value:{rev:1-619db7ba8551c0de3f3a178775509611}},
{id:org.couchdb.user:abc,key:org.couchdb.user:abc,value:{rev:1-64d299987b4df59c048171a8ab8ba951}},
{id:org.couchdb.user:def,key:org.couchdb.user:def,value:{rev:1-479a3e8a66652838706cc49544730a34}},
{id:org.couchdb.user:foo,key:org.couchdb.user:foo,value:{rev:1-3859ee3742314dcb4b4f1ffaba398c91}},
{id:org.couchdb.user:mia,key:org.couchdb.user:mia,value:{rev:1-f87f5003323e705d8c7a533cdd0a267c}},
{id:org.couchdb.user:root,key:org.couchdb.user:root,value:{rev:1-f43dadbe5e780f392a6bd283686b3704}}
]}
{code}
Same for anonymous user:
{code}
curl -v http://localhost:5984/_users/_all_docs
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Server: CouchDB/1.4.0+build.8d7ab8b (Erlang OTP/R16B)
ETag: 55N0CA8VM2Z0DQO85L1PM20XS
Date: Sat, 22 Jun 2013 00:04:17 GMT
Content-Type: text/plain; charset=utf-8
Cache-Control: must-revalidate
{total_rows:6,offset:0,rows:[
{id:_design/_auth,key:_design/_auth,value:{rev:1-619db7ba8551c0de3f3a178775509611}},
{id:org.couchdb.user:abc,key:org.couchdb.user:abc,value:{rev:1-64d299987b4df59c048171a8ab8ba951}},
{id:org.couchdb.user:def,key:org.couchdb.user:def,value:{rev:1-479a3e8a66652838706cc49544730a34}},
{id:org.couchdb.user:foo,key:org.couchdb.user:foo,value:{rev:1-3859ee3742314dcb4b4f1ffaba398c91}},
{id:org.couchdb.user:mia,key:org.couchdb.user:mia,value:{rev:1-f87f5003323e705d8c7a533cdd0a267c}},
{id:org.couchdb.user:root,key:org.couchdb.user:root,value:{rev:1-f43dadbe5e780f392a6bd283686b3704}}
]}
{code}
The problem is that with specified public_fields it's possible to retrieve
all user's names no matter has their public field or not. This behaviour a
bit violates implemented [System Database
Security|https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=e5503ff]:
[CouchDB 1.2.0 release
notes|https://blogs.apache.org/couchdb/entry/apache_couchdb_1_2_0]:
{quote}
Documents in the _users database can no longer be read by everyone
Documents in the _users databases can now only be read by the respective
authenticated user and administrators. Before, all docs were world-readable
including their password hashes and salts.
{quote}
[Security Features
Overview|http://wiki.apache.org/couchdb/Security_Features_Overview#Authentication%20database]:
{quote}
In addition, the _users database is now treated different from other
databases:
An anonymous user can only create a new document.
An authenticated user can only update their own document.
A server or database admin can access and update all documents.
Only server or database admins can create design documents and access
views and _all_docs and _changes.
{quote}
Expected behaviour when `public_fields` specified:
`_all_docs` should returns only those user docs, that are actually contains
[jira] [Updated] (COUCHDB-1837) Incorrect HTTP response on attempt to update other user doc with public fields enabled
[
https://issues.apache.org/jira/browse/COUCHDB-1837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet updated COUCHDB-1837:
-
Priority: Major (was: Blocker)
Fix Version/s: (was: 1.6.0)
Incorrect HTTP response on attempt to update other user doc with public
fields enabled
--
Key: COUCHDB-1837
URL: https://issues.apache.org/jira/browse/COUCHDB-1837
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Reporter: Alexander Shorin
When `public_fields` are specified (see
[8d7ab8b1|https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=8d7ab8b18dd20f8785e69f4420c6f93a2edbfa60]
commit) and regular user tries to update other user doc, CouchDB return HTTP
404 Not Found request while HTTP 403 Forbidden is more expected.
Steps to reproduce:
1. Enable `public_fields`
{code}
curl -X PUT http://localhost:5984/_config/couch_httpd_auth/public_fields -d
'name,email,whatever' -H Content-Type: application/json --user
couch_admin
{code}
2. Setup some users
{code}
curl -X PUT http://localhost:5984/_users/org.couchdb.user:abc -d
'{name:abc, roles:[], type:user, password: cba}' -H
Content-Type: application/json
curl -X PUT http://localhost:5984/_users/org.couchdb.user:def -d
'{name:def, roles:[], type:user, password: fed}' -H
Content-Type: application/json
{code}
3. Now user `abc` may browse `def` doc
{code}
curl -v http://abc:cba@localhost:5984/_users/org.couchdb.user:def
HTTP/1.1 200 OK
Cache-Control: must-revalidate
Content-Length: 88
Content-Type: text/plain; charset=utf-8
Date: Fri, 21 Jun 2013 22:48:03 GMT
ETag: 1-fa20c151bb6946527d261e9ef4338923
Server: CouchDB/1.4.0+build.8d7ab8b (Erlang OTP/R16B)
{_id:org.couchdb.user:def,_rev:1-fa20c151bb6946527d261e9ef4338923,name:def}
{code}
4. Try to save `def`'s doc:
{code}
curl -v -X PUT http://abc:cba@localhost:5984/_users/org.couchdb.user:def -d
'{}' -H Content-Type: application/json
HTTP/1.1 404 Object Not Found
Server: CouchDB/1.4.0+build.8d7ab8b (Erlang OTP/R16B)
Date: Fri, 21 Jun 2013 22:49:44 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 41
Cache-Control: must-revalidate
{error:not_found,reason:missing}
{code}
Since `org.couchdb.user:def` doc is actually exists and available for direct
GET request 404 response is incorrect and confuses while HTTP 403 Forbidden
is expected.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (COUCHDB-1399) Rename _rev to _mvcc or _lock
[ https://issues.apache.org/jira/browse/COUCHDB-1399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet updated COUCHDB-1399: - Fix Version/s: (was: 2.0.0) Rename _rev to _mvcc or _lock - Key: COUCHDB-1399 URL: https://issues.apache.org/jira/browse/COUCHDB-1399 Project: CouchDB Issue Type: Improvement Components: Database Core Affects Versions: 2.0.0 Reporter: Paul Joseph Davis We should rename the revisions to lock or token or some other suitably opaque term so we stop getting people asking questions about treating them as revisions. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (COUCHDB-956) Return all _seq values as strings not integers
[
https://issues.apache.org/jira/browse/COUCHDB-956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet updated COUCHDB-956:
Fix Version/s: (was: 2.0.0)
Return all _seq values as strings not integers
--
Key: COUCHDB-956
URL: https://issues.apache.org/jira/browse/COUCHDB-956
Project: CouchDB
Issue Type: Improvement
Reporter: Robert Newson
Some fields are returned as strings in db_info and other places to protect
against numeric overflow;
{db_name:db,doc_count:0,doc_del_count:0,update_seq:0,purge_seq:0,compact_running:false,disk_size:79,instance_start_time:1290088043619158,disk_format_version:5,committed_update_seq:0}
here, instance_start_time is protected but, more critically, update_seq is
not.
If update_seq were to be wrapped due to precision issues, what breaks?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (COUCHDB-1251) Factor out couch core and hook other compnonents through a module system
[ https://issues.apache.org/jira/browse/COUCHDB-1251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14013211#comment-14013211 ] Joan Touzet commented on COUCHDB-1251: -- Question: Is this already covered by work in the merge? If so, is that from rcouch's OTP work or from bigcouch's chttpd (for -1355)? Factor out couch core and hook other compnonents through a module system Key: COUCHDB-1251 URL: https://issues.apache.org/jira/browse/COUCHDB-1251 Project: CouchDB Issue Type: Umbrella Components: Build System, Database Core Reporter: Randall Leeds Fix For: 2.0.0 https://mail-archives.apache.org/mod_mbox/couchdb-dev/201108.mbox/browser -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (COUCHDB-904) No method to detect view server VM version
[
https://issues.apache.org/jira/browse/COUCHDB-904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet updated COUCHDB-904:
Fix Version/s: (was: 2.0.0)
3.0.0
No method to detect view server VM version
--
Key: COUCHDB-904
URL: https://issues.apache.org/jira/browse/COUCHDB-904
Project: CouchDB
Issue Type: New Feature
Components: JavaScript View Server
Reporter: Paul Joseph Davis
Priority: Minor
Fix For: 3.0.0
Attachments: patch.txt
There's currently no way to tell what version of the view server is being
used. Ie, the JS VM (Or Python, or Ruby, etc) that is being used. Just
occurred to me it could be useful for debugging things that work one place
and not another.
A proposed simple fix would be to have the view server protocol dictate that
when a server boots up it spits out a line like:
{version: OPAQUE_STRING} that gets stored in a view_server_versions section
in the config or some such.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (COUCHDB-1164) Pass CouchDB version to view server
[ https://issues.apache.org/jira/browse/COUCHDB-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet updated COUCHDB-1164: - Fix Version/s: (was: 2.0.0) 3.0.0 Pass CouchDB version to view server --- Key: COUCHDB-1164 URL: https://issues.apache.org/jira/browse/COUCHDB-1164 Project: CouchDB Issue Type: New Feature Components: JavaScript View Server Reporter: Alexander Shorin Priority: Minor Fix For: 3.0.0 Imagine that I'm developer of some view server. I'd like to create view server which covers most of CouchDB releases. Each new CouchDB release brings new features, improvements and API changes, some times backward-incompatible (as for 0.9-0.10-0.11-0.11.1) . However, I couldn't solve this task due to there is not way to know about CouchDB version and API that I have to implement. So there are three ways that I have: 1. develop only bleeding edge view server that support only latest version 2. make separate branch per version 3. keep all in one and pass version as command line argument. First one makes to forgot about old releases, second is supporting hell. Last one is more effective, but requires to keep in mind changing argument on server update. So there is actually no way to make great view server such as javascript/erlang one with wide CouchDB versions support. Without that support using and developing couchapps for ruby/python/clojure/others view servers is quite unpromising. This issue could be an improvement of COUCHDB-904 by using next scenario: CouchDB pass version command to view server with additional value of CouchDB version and excepts that view server return his version back. That would be something like version exchange. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (COUCHDB-1756) 100% compatibility with BigCouch API
[ https://issues.apache.org/jira/browse/COUCHDB-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14013217#comment-14013217 ] Joan Touzet commented on COUCHDB-1756: -- Is this ticket still useful? 100% compatibility with BigCouch API Key: COUCHDB-1756 URL: https://issues.apache.org/jira/browse/COUCHDB-1756 Project: CouchDB Issue Type: Task Reporter: Robert Newson Assignee: Robert Newson Fix For: 2.0.0 The release that includes the resolution of this ticket will be 100% compatible with the release after the BigCouch merge. This will include additions (of new parameters, methods) that pertain to clustered databases, subtractions (of parameters, features) that do not work in clusters and changes (typically of response values like update sequences). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (COUCHDB-1298) X-Couch-Update-NewRev and ETag and Content-Type
[ https://issues.apache.org/jira/browse/COUCHDB-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet updated COUCHDB-1298: - Fix Version/s: (was: 2.0.0) 3.0.0 X-Couch-Update-NewRev and ETag and Content-Type - Key: COUCHDB-1298 URL: https://issues.apache.org/jira/browse/COUCHDB-1298 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Affects Versions: 1.2 Reporter: gert cuykens Assignee: Randall Leeds Priority: Trivial Labels: couchdb Fix For: 3.0.0 Original Estimate: 1h Remaining Estimate: 1h There are three inconsistencies 1) The use of ETag vs X-Couch-Update-NewRev 2) The use of ... around the rev number 3) Content-Type: is different, see the space between ;...charset PUT /users/_design/user/_update/form/gert HTTP/1.1 Host: 127.0.0.1:5984 HTTP/1.1 201 Created X-Couch-Update-NewRev: 245-2ddebfc32429bc723cb20543a97d3598 Server: CouchDB/1.3.0a-f07c75f-git (Erlang OTP/R13B03) Date: Wed, 28 Sep 2011 15:49:49 GMT Content-Type: text/html; charset=utf-8 Content-Length: 8 PUT /users/gert/picture.png HTTP/1.1 Host: 127.0.0.1:5984 HTTP/1.1 201 Created Server: CouchDB/1.3.0a-f07c75f-git (Erlang OTP/R13B03) Location: http://127.0.0.1:5984/users/gert/picture.png ETag: 246-f1291707f1827ef38217972ea1f3824c Date: Wed, 28 Sep 2011 15:50:25 GMT Content-Type: text/plain;charset=utf-8 Content-Length: 69 Cache-Control: must-revalidate Pleas always use ETag without ... When a new document is been created, also use ETag because its already indicated by status 201, no need for special headers. Also note Content-Type: is different, see the space between ;...charset -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (COUCHDB-2248) Replace master and slave terminology
[ https://issues.apache.org/jira/browse/COUCHDB-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011497#comment-14011497 ] Joan Touzet commented on COUCHDB-2248: -- +1. DO IT NOW, THIS NEEDS TO BE PUT TO BED. :D Replace master and slave terminology Key: COUCHDB-2248 URL: https://issues.apache.org/jira/browse/COUCHDB-2248 Project: CouchDB Issue Type: Bug Security Level: public(Regular issues) Components: Documentation Reporter: Noah Slater Priority: Trivial Inspired by the comments on this PR: https://github.com/django/django/pull/2692 Summary is: `master` and `slave` are racially charged terms, and it would be good to avoid them. Django have gone for `primary` and `replica`. But we also have to deal with what we now call multi-master setups. I propose peer to peer as a replacement, or just peer if you're describing one node. As far as I can tell, the primary work here is the docs. The wiki and any supporting material can be updated after. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (COUCHDB-2248) Replace master and slave terminology
[ https://issues.apache.org/jira/browse/COUCHDB-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14009739#comment-14009739 ] Joan Touzet commented on COUCHDB-2248: -- I have Native American heritage and was born in the USA, does that mean I qualify as an American POC? First Nations people certainly were enslaved and the subjects of a concerted genocide effort. Was the comment made by a POC specifically about CouchDB's documentation? We really never talk about slave in our docs. No one has yet suggested a suitable replacement for multi-master replication. Rather than continuing to fight over intent and hurt feelings, I suggest we table this discussion until there is some replacement worth discussing. I also recommend that such change appear in a diff or commit somewhere, rather than as a stump speech here in CouchDB. Replace master and slave terminology Key: COUCHDB-2248 URL: https://issues.apache.org/jira/browse/COUCHDB-2248 Project: CouchDB Issue Type: Bug Security Level: public(Regular issues) Components: Documentation Reporter: Noah Slater Priority: Trivial Inspired by the comments on this PR: https://github.com/django/django/pull/2692 Summary is: `master` and `slave` are racially charged terms, and it would be good to avoid them. Django have gone for `primary` and `replica`. But we also have to deal with what we now call multi-master setups. I propose peer to peer as a replacement, or just peer if you're describing one node. As far as I can tell, the primary work here is the docs. The wiki and any supporting material can be updated after. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (COUCHDB-2248) Replace master and slave terminology
[ https://issues.apache.org/jira/browse/COUCHDB-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14009759#comment-14009759 ] Joan Touzet commented on COUCHDB-2248: -- Confirming that master and replica is the sense we use today, along with master-master or master-replica in sense I. Replace master and slave terminology Key: COUCHDB-2248 URL: https://issues.apache.org/jira/browse/COUCHDB-2248 Project: CouchDB Issue Type: Bug Security Level: public(Regular issues) Components: Documentation Reporter: Noah Slater Priority: Trivial Inspired by the comments on this PR: https://github.com/django/django/pull/2692 Summary is: `master` and `slave` are racially charged terms, and it would be good to avoid them. Django have gone for `primary` and `replica`. But we also have to deal with what we now call multi-master setups. I propose peer to peer as a replacement, or just peer if you're describing one node. As far as I can tell, the primary work here is the docs. The wiki and any supporting material can be updated after. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (COUCHDB-2248) Replace master and slave terminology
[ https://issues.apache.org/jira/browse/COUCHDB-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14009141#comment-14009141 ] Joan Touzet commented on COUCHDB-2248: -- $ grep -ri slave * share/doc/src/intro/consistency.rst:multi-master, master/slave, partitioning, sharding, write-through caches, One change surely isn't a big deal, is it? Also, this can be taken too far - we're not going to rename git master just because it might sound like a master/slave relationship Replace master and slave terminology Key: COUCHDB-2248 URL: https://issues.apache.org/jira/browse/COUCHDB-2248 Project: CouchDB Issue Type: Bug Security Level: public(Regular issues) Components: Documentation Reporter: Noah Slater Inspired by the comments on this PR: https://github.com/django/django/pull/2692 Summary is: `master` and `slave` are racially charged terms, and it would be good to avoid them. Django have gone for `primary` and `replica`. But we also have to deal with what we now call multi-master setups. I propose peer to peer as a replacement, or just peer if you're describing one node. As far as I can tell, the primary work here is the docs. The wiki and any supporting material can be updated after. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (COUCHDB-2248) Replace master and slave terminology
[ https://issues.apache.org/jira/browse/COUCHDB-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet updated COUCHDB-2248: - Priority: Trivial (was: Major) Replace master and slave terminology Key: COUCHDB-2248 URL: https://issues.apache.org/jira/browse/COUCHDB-2248 Project: CouchDB Issue Type: Bug Security Level: public(Regular issues) Components: Documentation Reporter: Noah Slater Priority: Trivial Inspired by the comments on this PR: https://github.com/django/django/pull/2692 Summary is: `master` and `slave` are racially charged terms, and it would be good to avoid them. Django have gone for `primary` and `replica`. But we also have to deal with what we now call multi-master setups. I propose peer to peer as a replacement, or just peer if you're describing one node. As far as I can tell, the primary work here is the docs. The wiki and any supporting material can be updated after. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (COUCHDB-2248) Replace master and slave terminology
[ https://issues.apache.org/jira/browse/COUCHDB-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14009152#comment-14009152 ] Joan Touzet commented on COUCHDB-2248: -- 1. We have no references to slave that describe CouchDB, only a mention in passing with respect to other databases. We have *never* referred to any CouchDB server in documentation or examples using the term slave. 2. Multi-master implies *everyone* is a master. This is not racially charged and is sex-positive. It is, in fact, empowering and supportive of equanimity across many diverse demographics - every CouchDB is master of its own data domain. 3. Multi-master replication is an industry term that is well recognized, enough to have its own Wikipedia page: https://en.wikipedia.org/wiki/Multi-master_replication We do ourselves a disservice to stop using this term. 4. The proposed term primary suggests that there is a write master, a dangerous assertion that will give people the wrong impression about our technology. We should be proud not to have write masters in clustered BigCouch / merged CouchDB architectures. 5. Replica-replica-replication sounds too redundant and does not provide the semantic nuance that writes can be made in both replicas. It also suggests a failover cluster model which, again, is not what CouchDB provides. Proposal: leave everything in the repo as is. If you want to be racially positive and loudly denounce human slavery as wrong and use our project as a platform for that, you should instead proudly promote that CouchDB makes a slave of no one, and empowers everyone to be the master of their data, no matter how many replicas there are of it. Replace master and slave terminology Key: COUCHDB-2248 URL: https://issues.apache.org/jira/browse/COUCHDB-2248 Project: CouchDB Issue Type: Bug Security Level: public(Regular issues) Components: Documentation Reporter: Noah Slater Priority: Trivial Inspired by the comments on this PR: https://github.com/django/django/pull/2692 Summary is: `master` and `slave` are racially charged terms, and it would be good to avoid them. Django have gone for `primary` and `replica`. But we also have to deal with what we now call multi-master setups. I propose peer to peer as a replacement, or just peer if you're describing one node. As far as I can tell, the primary work here is the docs. The wiki and any supporting material can be updated after. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (COUCHDB-2248) Replace master and slave terminology
[ https://issues.apache.org/jira/browse/COUCHDB-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14009160#comment-14009160 ] Joan Touzet commented on COUCHDB-2248: -- peer to peer replication sounds like BitTorrent and also gives the wrong impression. There is no mistaking what master-master replication means in the database world. I am opposed to changing away from the well-understood master-master replication terminology unless there is another well-understood term we can use to replace it. CouchDB needs to be less obscure, not more. Replace master and slave terminology Key: COUCHDB-2248 URL: https://issues.apache.org/jira/browse/COUCHDB-2248 Project: CouchDB Issue Type: Bug Security Level: public(Regular issues) Components: Documentation Reporter: Noah Slater Priority: Trivial Inspired by the comments on this PR: https://github.com/django/django/pull/2692 Summary is: `master` and `slave` are racially charged terms, and it would be good to avoid them. Django have gone for `primary` and `replica`. But we also have to deal with what we now call multi-master setups. I propose peer to peer as a replacement, or just peer if you're describing one node. As far as I can tell, the primary work here is the docs. The wiki and any supporting material can be updated after. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (COUCHDB-2248) Replace master and slave terminology
[ https://issues.apache.org/jira/browse/COUCHDB-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14009167#comment-14009167 ] Joan Touzet commented on COUCHDB-2248: -- I think you underestimate the damage and confusion that changing master-master to peer-to-peer replication would lead to. It inaccurately conflates the plumbing of replication, i.e. the underlying network mechanism, with the logic of replication, i.e. whether changes can come from one or both sides during a replication process. Remember that peer-to-peer networking apps are banned at most corporate institutions. It suggests a specific architecture that is required to make replication work, that is not at all necessary for CouchDB. In Futon and Fauxton we talk about source and target already. Surely this is sufficient! Replace master and slave terminology Key: COUCHDB-2248 URL: https://issues.apache.org/jira/browse/COUCHDB-2248 Project: CouchDB Issue Type: Bug Security Level: public(Regular issues) Components: Documentation Reporter: Noah Slater Priority: Trivial Inspired by the comments on this PR: https://github.com/django/django/pull/2692 Summary is: `master` and `slave` are racially charged terms, and it would be good to avoid them. Django have gone for `primary` and `replica`. But we also have to deal with what we now call multi-master setups. I propose peer to peer as a replacement, or just peer if you're describing one node. As far as I can tell, the primary work here is the docs. The wiki and any supporting material can be updated after. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (COUCHDB-1669) Unable to start CouchDB in background through a psuedo-tty
[
https://issues.apache.org/jira/browse/COUCHDB-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13975399#comment-13975399
]
Joan Touzet commented on COUCHDB-1669:
--
Confirmed on Debian 7.4. This is a result of how couchdb -b recurses and
creates a grandchild process. Sadly this isn't a quick fix, will keep looking.
Unable to start CouchDB in background through a psuedo-tty
---
Key: COUCHDB-1669
URL: https://issues.apache.org/jira/browse/COUCHDB-1669
Project: CouchDB
Issue Type: Bug
Reporter: Daniel Woelfel
Assignee: Joan Touzet
CouchDB crashes when started as a background process in a psuedo-tty.
Steps to reproduce:
On a machine that you can ssh into localhost do:
ssh -tt localhost /path/to/couchdb -b
When the connection closes, CouchDB will be killed.
A few things I've discovered while debugging
When I do
ssh -tt localhost ~/build-couchdb/build/bin/couchdb -b sleep 10 curl
localhost:5984
The output from the command is:
Apache CouchDB has started, time to relax.
{couchdb:Welcome,version:1.2.1}
Connection to localhost closed.
The contents or couchdb's stdout file is
Apache CouchDB 1.2.1 (LogLevel=info) is starting.
Apache CouchDB has started. Time to relax.
[info] [0.32.0] Apache CouchDB has started on http://127.0.0.1:5984/
[info] [0.131.0] 127.0.0.1 - - GET / 200
The contents of couchdb's stderr is
heart_beat_kill_pid = 32631
heart_beat_timeout = 11
heart: Mon Feb 4 07:31:57 2013: Erlang has closed.
heart: Mon Feb 4 07:31:58 2013: Executed
/home/ubuntu/build-couchdb/build/bin/couchdb -k - 0. Terminating.
This happens no matter how I start CouchDB: as a service, with the init
script, with nohup, or with the command above. I built CouchDB using the
build instructions for Ubuntu 12.04 from the wiki and using the build-couchdb
project on Github.
The really odd thing is that this only happens when I start couchdb with `ssh
-tt`. If I ssh into localhost and start couchdb in the background, it will
continue running after I exit the ssh session.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (COUCHDB-2220) /usr/bin/couchdb -b doesn't close stdout / stderr
[ https://issues.apache.org/jira/browse/COUCHDB-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joan Touzet resolved COUCHDB-2220. -- Resolution: Fixed Fix Version/s: 1.7.0 Closing stdout/stderr when recursing fixes this bug. /usr/bin/couchdb -b doesn't close stdout / stderr --- Key: COUCHDB-2220 URL: https://issues.apache.org/jira/browse/COUCHDB-2220 Project: CouchDB Issue Type: Bug Security Level: public(Regular issues) Reporter: Shish Assignee: Joan Touzet Fix For: 1.7.0 /usr/bin/couchdb -b launches a copy of itself in the background, but leaves stdout and stderr for the subprocess attached to the controlling terminal in the foreground This makes salt hang when launching couchdb, because it tries to read the output of /etc/init.d/couchdb restart - despite the fact that that init script itself has returned, the children (ie, the daemon) are still holding the console file descriptors open I *suspect* that this is also the cause of this issue -- https://issues.apache.org/jira/browse/COUCHDB-1669 If you have salt-minion 2014.1.0 installed, try stopping couchdb and then starting it up with: salt-call cmd.run 'su couchdb -c /usr/bin/couchdb -b -o /tmp/couchdb.stdout -e /tmp/couchdb.stderr' Originally reported as a bug in salt, but it seems that couchdb is the part with the non-standard behaviour https://github.com/saltstack/salt/issues/11228 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (COUCHDB-1669) Unable to start CouchDB in background through a psuedo-tty
[
https://issues.apache.org/jira/browse/COUCHDB-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joan Touzet resolved COUCHDB-1669.
--
Resolution: Fixed
Fix Version/s: 1.7.0
Closing stdout/stderr when recursing fixes this bug.
Unable to start CouchDB in background through a psuedo-tty
---
Key: COUCHDB-1669
URL: https://issues.apache.org/jira/browse/COUCHDB-1669
Project: CouchDB
Issue Type: Bug
Reporter: Daniel Woelfel
Assignee: Joan Touzet
Fix For: 1.7.0
CouchDB crashes when started as a background process in a psuedo-tty.
Steps to reproduce:
On a machine that you can ssh into localhost do:
ssh -tt localhost /path/to/couchdb -b
When the connection closes, CouchDB will be killed.
A few things I've discovered while debugging
When I do
ssh -tt localhost ~/build-couchdb/build/bin/couchdb -b sleep 10 curl
localhost:5984
The output from the command is:
Apache CouchDB has started, time to relax.
{couchdb:Welcome,version:1.2.1}
Connection to localhost closed.
The contents or couchdb's stdout file is
Apache CouchDB 1.2.1 (LogLevel=info) is starting.
Apache CouchDB has started. Time to relax.
[info] [0.32.0] Apache CouchDB has started on http://127.0.0.1:5984/
[info] [0.131.0] 127.0.0.1 - - GET / 200
The contents of couchdb's stderr is
heart_beat_kill_pid = 32631
heart_beat_timeout = 11
heart: Mon Feb 4 07:31:57 2013: Erlang has closed.
heart: Mon Feb 4 07:31:58 2013: Executed
/home/ubuntu/build-couchdb/build/bin/couchdb -k - 0. Terminating.
This happens no matter how I start CouchDB: as a service, with the init
script, with nohup, or with the command above. I built CouchDB using the
build instructions for Ubuntu 12.04 from the wiki and using the build-couchdb
project on Github.
The really odd thing is that this only happens when I start couchdb with `ssh
-tt`. If I ssh into localhost and start couchdb in the background, it will
continue running after I exit the ssh session.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (COUCHDB-1994) merge rcouch with couchdb 1.6 in a branch
[ https://issues.apache.org/jira/browse/COUCHDB-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13974907#comment-13974907 ] Joan Touzet commented on COUCHDB-1994: -- [~benoitc] It's a 404. There is no ICU at http://dl.refuge.io/, just js/nspr. merge rcouch with couchdb 1.6 in a branch - Key: COUCHDB-1994 URL: https://issues.apache.org/jira/browse/COUCHDB-1994 Project: CouchDB Issue Type: Task Components: Build System, Database Core, HTTP Interface, JavaScript View Server Reporter: Benoit Chesneau -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (COUCHDB-1994) merge rcouch with couchdb 1.6 in a branch
[
https://issues.apache.org/jira/browse/COUCHDB-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13974463#comment-13974463
]
Joan Touzet commented on COUCHDB-1994:
--
I see that {{make libs=shared}} is only supported on Darwin. Is that an
intentional choice?
https://github.com/apache/couchdb-couch-collate/blob/1994-merge-rcouch/rebar.config.script#L40-L45
merge rcouch with couchdb 1.6 in a branch
-
Key: COUCHDB-1994
URL: https://issues.apache.org/jira/browse/COUCHDB-1994
Project: CouchDB
Issue Type: Task
Components: Build System, Database Core, HTTP Interface, JavaScript
View Server
Reporter: Benoit Chesneau
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (COUCHDB-1994) merge rcouch with couchdb 1.6 in a branch
[
https://issues.apache.org/jira/browse/COUCHDB-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13974679#comment-13974679
]
Joan Touzet commented on COUCHDB-1994:
--
OK, I have checked in changes to allow a Windows build to complete. make rel
creates a release directory, but the result is not yet ready for prime time
(startup script is nonfunctional and DLLs are not yet copied to the right
places.) This will all change with the BigCouch merge so, if others can confirm
the build produces a functional Couch we can skip this for now.
After discussion with [~dch] and [~nicknorth] we've decided to punt on building
ICU and Spidermonkey in the build process for Windows. ICU upstream already
ships functional binary builds, and we have a pre-built Spidermonkey binary the
build depends upon. Right now this is hosted on my website but before release
we should move this to dist (or at least people.a.o).
The Windows build also does not support system binaries or static linking, and
does not link libcurl into couchjs.
Instructions:
1. Install Erlang from erlang.org (I tested against 16B03)
1. Install VS 2012 or 2013 Express Desktop.
1. Install python, pip install sphinx
1. As Administrator, run {{powershell Set-ExecutionPolicy Unrestricted}}
1. From the VS 201x x86 Native Tools Command Prompt, {{cd couchdb}} and
{{make}}
1. (Optional) As Administrator, run {{powershell Set-ExecutionPolicy
Restricted}}
Confirmation that I did not break the UNIX build(s) and that this Windows build
works would be most appreciated.
merge rcouch with couchdb 1.6 in a branch
-
Key: COUCHDB-1994
URL: https://issues.apache.org/jira/browse/COUCHDB-1994
Project: CouchDB
Issue Type: Task
Components: Build System, Database Core, HTTP Interface, JavaScript
View Server
Reporter: Benoit Chesneau
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (COUCHDB-1994) merge rcouch with couchdb 1.6 in a branch
[
https://issues.apache.org/jira/browse/COUCHDB-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13974698#comment-13974698
]
Joan Touzet commented on COUCHDB-1994:
--
Testing the static build on Debian 7.4 (Wheezy) failed when trying to download
the {{icu4c-4_4_2-src.tgz}} file. I have pushed a change to pull ICU and JS
from the official distribution sites for now, until we can get a proper mirror
on dist (or at worst people.apache.org).
merge rcouch with couchdb 1.6 in a branch
-
Key: COUCHDB-1994
URL: https://issues.apache.org/jira/browse/COUCHDB-1994
Project: CouchDB
Issue Type: Task
Components: Build System, Database Core, HTTP Interface, JavaScript
View Server
Reporter: Benoit Chesneau
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (COUCHDB-1994) merge rcouch with couchdb 1.6 in a branch
[ https://issues.apache.org/jira/browse/COUCHDB-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13974742#comment-13974742 ] Joan Touzet commented on COUCHDB-1994: -- OK, last thing for tonight - I've put the WIndows and Spidermonkey Windows build instructions at https://cwiki.apache.org/confluence/display/COUCHDB/Windows . merge rcouch with couchdb 1.6 in a branch - Key: COUCHDB-1994 URL: https://issues.apache.org/jira/browse/COUCHDB-1994 Project: CouchDB Issue Type: Task Components: Build System, Database Core, HTTP Interface, JavaScript View Server Reporter: Benoit Chesneau -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (COUCHDB-1994) merge rcouch with couchdb 1.6 in a branch
[
https://issues.apache.org/jira/browse/COUCHDB-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13973343#comment-13973343
]
Joan Touzet commented on COUCHDB-1994:
--
Debian 7.4 (Wheezy) I tried {{make}} followed by {{make rel}} and I get the
following error:
{code}
== rel (generate)
ERROR: Unable to generate spec: read file info
/usr/lib/erlang/man/man1/tasm.1.gz failed
ERROR: Unexpected error: rebar_abort
ERROR: generate failed while processing /home/joant/rcouch/couchdb/rel:
rebar_abort
make: *** [generate] Error 1
{code}
{{make check}} passes.
On my system, {{/usr/lib/erlang/man/man1/tasm.1.gz}} is a symlink to
{{ytasm.1.gz}} which doesn't exist. Reference:
https://github.com/basho/riak/issues/270 Weird bug.
merge rcouch with couchdb 1.6 in a branch
-
Key: COUCHDB-1994
URL: https://issues.apache.org/jira/browse/COUCHDB-1994
Project: CouchDB
Issue Type: Task
Components: Build System, Database Core, HTTP Interface, JavaScript
View Server
Reporter: Benoit Chesneau
--
This message was sent by Atlassian JIRA
(v6.2#6252)
