[jira] [Resolved] (COUCHDB-2532) Compact a given design document
[ https://issues.apache.org/jira/browse/COUCHDB-2532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Kocoloski resolved COUCHDB-2532. - Resolution: Not a Problem Hi Leon, when you compact a view group you compact the indexes generated by the MR functions in that group, not the design doc itself. If you examine the /db/_design/ddoc/_info resource before and after the view group compaction you should see the difference in disk consumption. Compact a given design document --- Key: COUCHDB-2532 URL: https://issues.apache.org/jira/browse/COUCHDB-2532 Project: CouchDB Issue Type: Bug Security Level: public(Regular issues) Components: Futon, HTTP Interface Reporter: Leon Kaiser Hello, when I send a compact-command with a path to a ViewDocument, the server returns that this command has been processed successfully (Ok=bool(true), Status=202). But when I open the same ViewDocument via Futon all former versions of the documents are still there. When I compact the whole database (sending a request without specifying a ViewDocument) I get the same response as well (Ok=bool(true), Status=202) and the ViewDocument as all other Documents will be compacted and their old versions are removed (they do not appear in Futon anymore) everything works fine. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (COUCHDB-2231) sudo service couchdb stop does not reliably stop CouchDB
Adam Kocoloski created COUCHDB-2231: --- Summary: sudo service couchdb stop does not reliably stop CouchDB Key: COUCHDB-2231 URL: https://issues.apache.org/jira/browse/COUCHDB-2231 Project: CouchDB Issue Type: Bug Security Level: public (Regular issues) Components: Infrastructure Reporter: Adam Kocoloski Reported by Marty Hu on user@ http://mail-archives.apache.org/mod_mbox/couchdb-user/201404.mbox/%3CCAPG1hyN5vjr8RgrncHbiqD3XqX3gDNPqHAKz1am9STthP15EUg%40mail.gmail.com%3E [~mmarino] points out that this is not the first time the issue has been reported, and linked to a gist that may be a workaround: https://gist.github.com/mgmarino/7601778 Possibly related to COUCHDB-1069 as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (COUCHDB-2182) Why doesn't couchdb support multiple keys requests to a reduce function using group_level ?
[ https://issues.apache.org/jira/browse/COUCHDB-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Kocoloski resolved COUCHDB-2182. - Resolution: Duplicate Hi Gabe, I'd like to close this issue in favor of COUCHDB-523. The functionality you're looking for will be included in the fix for that issue when it lands. Does that work for you? Why doesn't couchdb support multiple keys requests to a reduce function using group_level ? --- Key: COUCHDB-2182 URL: https://issues.apache.org/jira/browse/COUCHDB-2182 Project: CouchDB Issue Type: Question Security Level: public(Regular issues) Components: Database Core, HTTP Interface Reporter: Gabe Malicki Why doesn't couchdb support multiple keys requests to a reduce function using group_level ? I need this functionality in order to reduce the amount of network IO and latency in my system. Perhaps it would be possible to implement this with a warning about the cost of such a query. Here is my example real-world use case: I have a database of widgets that are being voted on by web users and I have a reduce function that computes different types of ranking for each widget based on the widget's numerical properties in conjunction with user votes (1 to 10). There are far too many widgets to sort in the client and couchdb does not allow the sorting of view query results by value. This means in order to be able to get the widgets sorted by their ranking I need to first write the reduce function output (score results for each widget) to a database so that I can later query on that data sorted by score. As new votes enter the system they are bulk_saved then a separate view reduce query is executed for each effected widget to calculate the new scores then those scores are bulk_saved into a db so that they can later be queried sorted by their various scores. Since couchdb doesn't allow querying multiple keys with my reduce function using group_level I'm having to make 20 HTTP GET requests if 20 different widgets were voted on instead of a single HTTP GET and all of this extra network io means I have to fire off a bunch of threads to block on network IO which is expensive and this cost becomes greater the more votes I need to process per minute. Adding multiple keys query with group_level would reduce the amount of CPU, latency, and bandwidth that I'm having to burn in order to achieve reduce function sorting by value. Of course if someone could figure out how to let me sort reduce output by value then that would save me even more resources. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (COUCHDB-2176) Map/Reduce views within views
[
https://issues.apache.org/jira/browse/COUCHDB-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13914949#comment-13914949
]
Adam Kocoloski commented on COUCHDB-2176:
-
It's been discussed a number of times on the dev@ list dating all the way back
to 2009, but I'm not aware of any pre-existing JIRA ticket. It's a significant
effort; some good news is that the work [~benoitc] did on adding sequence
indexes to views is quite likely foundational for this feature.
Map/Reduce views within views
-
Key: COUCHDB-2176
URL: https://issues.apache.org/jira/browse/COUCHDB-2176
Project: CouchDB
Issue Type: Wish
Security Level: public(Regular issues)
Reporter: Nolan Lawson
I don't know if this has already been discussed, but often with CouchDB I've
run into a situation where a single map/reduce view couldn't quite slice my
data in the way I needed.
For instance, say you want to order rows by the _value_ of an emit function,
rather than the key. E.g., you want to emit a certain key, reduce it using
{{_count}}, and then order that output by the counts. Currently you'd have
to stuff the output of the first view into another database (manually) and
then create a new view on top of that one.
It's also pretty common for apps to have different flavors of
detail/summary views, each one optimized for a different page on the web
site (e.g. my inbox, message summary, message with details/attachments,
message thread, etc.). In the past I've simply resorted to redundancy,
uploading the same data represented in different ways but all as documents in
separate databases, but this is a pain to manage.
Instead, I'd love it if the input of one view could simply be the output of
another view. This would create endless flexibility and obviate the need for
a lot of tinkering with the emit values (e.g. with linked documents). I'm
not sure what the complexity would be of introducing this into the CouchDB
code, but from a user's point of view it would definitely be nice to have.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (COUCHDB-1986) 04-replication-large-atts.t times out
[ https://issues.apache.org/jira/browse/COUCHDB-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13913195#comment-13913195 ] Adam Kocoloski commented on COUCHDB-1986: - [~kxepal] the stacktrace would be very useful if you have it. I checked to see if that binary is a string -- it's not. 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 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.1.5#6160)
[jira] [Commented] (COUCHDB-1606) Replicator leaves plaintext password in logs
[ https://issues.apache.org/jira/browse/COUCHDB-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13911044#comment-13911044 ] Adam Kocoloski commented on COUCHDB-1606: - I think setting the sensitive flag is the way to go. I don't recall offhand which processes receive that state, but it'd be easy enough to track down. Replicator leaves plaintext password in logs Key: COUCHDB-1606 URL: https://issues.apache.org/jira/browse/COUCHDB-1606 Project: CouchDB Issue Type: Bug Components: Logging, Replication Affects Versions: 1.2 Reporter: Nathan Vander Wilt Assignee: Bob Dionne Attachments: pwd log.txt While reviewing logs, I noticed that a password had been recorded in the logs as part of a replicator error. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (COUCHDB-1606) Replicator leaves plaintext password in logs
[ https://issues.apache.org/jira/browse/COUCHDB-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13911060#comment-13911060 ] Adam Kocoloski commented on COUCHDB-1606: - Agreed Replicator leaves plaintext password in logs Key: COUCHDB-1606 URL: https://issues.apache.org/jira/browse/COUCHDB-1606 Project: CouchDB Issue Type: Bug Components: Logging, Replication Affects Versions: 1.2 Reporter: Nathan Vander Wilt Assignee: Bob Dionne Attachments: pwd log.txt While reviewing logs, I noticed that a password had been recorded in the logs as part of a replicator error. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (COUCHDB-2059) CouchDB replicator sends urls that are too long for comfort
[
https://issues.apache.org/jira/browse/COUCHDB-2059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900282#comment-13900282
]
Adam Kocoloski commented on COUCHDB-2059:
-
Hmm, I'd have preferred to see this config option as part of the spec for a
replication job and not a server-level config. We're trying to address a
deficiency in a particular replication source here, but the config setting
needs to be applied on the server mediating the replication. I think it would
have been more obvious to do something like the following:
{code}
source : {
url : https://...;,
max_url_len: 1024
}
...
{code}
Related question: [~isaacs], did your proxy happen to return a {{414
Request-URI Too Long}} status? We ought to patch the replicator to respect
that return code and split up a request as necessary.
CouchDB replicator sends urls that are too long for comfort
---
Key: COUCHDB-2059
URL: https://issues.apache.org/jira/browse/COUCHDB-2059
Project: CouchDB
Issue Type: Bug
Security Level: public(Regular issues)
Components: Replication
Reporter: Isaac Z. Schlueter
Fix For: 1.7.0
I have my couchdb behind an TLS terminator. Like most HTTP servers, it has a
limit on how long URLs can be, and that limit is far smaller than the 6-12KB
urls that the CouchDB replicator is sending.
https://gist.github.com/isaacs/0010221834a3491d6481
http://cl.ly/image/3N192G293j1R
This is a bug, right?
For added frustration:
1. The replication never goes into a failed state. Just stays triggered
forever, doing nothing, hung at 77%.
2. The logs are indented with over 6000 spaces. I've been known to do some
crazy code formatting in my time, but this is too extreme, and makes reading
the log unnecessarily difficult.
Suggestion:
Limit the length of URLs that the replicator will use to something more
reasonable, such as 1024 bytes. If more data than that is required, send it
in the body of the request.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (COUCHDB-2059) CouchDB replicator sends urls that are too long for comfort
[ https://issues.apache.org/jira/browse/COUCHDB-2059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900400#comment-13900400 ] Adam Kocoloski commented on COUCHDB-2059: - Sounds reasonable to me, though I'll note that RFC2616 makes a more stringent recommendation: bq. Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths. http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.1 Not sure any such clients are still in the wild. CouchDB replicator sends urls that are too long for comfort --- Key: COUCHDB-2059 URL: https://issues.apache.org/jira/browse/COUCHDB-2059 Project: CouchDB Issue Type: Bug Security Level: public(Regular issues) Components: Replication Reporter: Isaac Z. Schlueter Fix For: 1.7.0 I have my couchdb behind an TLS terminator. Like most HTTP servers, it has a limit on how long URLs can be, and that limit is far smaller than the 6-12KB urls that the CouchDB replicator is sending. https://gist.github.com/isaacs/0010221834a3491d6481 http://cl.ly/image/3N192G293j1R This is a bug, right? For added frustration: 1. The replication never goes into a failed state. Just stays triggered forever, doing nothing, hung at 77%. 2. The logs are indented with over 6000 spaces. I've been known to do some crazy code formatting in my time, but this is too extreme, and makes reading the log unnecessarily difficult. Suggestion: Limit the length of URLs that the replicator will use to something more reasonable, such as 1024 bytes. If more data than that is required, send it in the body of the request. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (COUCHDB-2058) CouchDB Memory Leak - Beam.smp
[
https://issues.apache.org/jira/browse/COUCHDB-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900424#comment-13900424
]
Adam Kocoloski commented on COUCHDB-2058:
-
[~rohit12sh], when Paul was asking for the stats inside the VM he meant the
{{erlang:memory([atom, atom_used, processes, processes_used, binary, code,
ets]).}} invocation. So far every time you've posted that the output indicates
negligible RAM usage in the pure Erlang parts of the stack. Can you confirm
that at least one of your reports was taken when CouchDB was holding on to all
that RAM? It's a little hard to tell when reading the backlog.
CouchDB Memory Leak - Beam.smp
--
Key: COUCHDB-2058
URL: https://issues.apache.org/jira/browse/COUCHDB-2058
Project: CouchDB
Issue Type: Bug
Security Level: public(Regular issues)
Components: Database Core
Reporter: Rohit Sharma
Hello,
I am experiencing performance issue with CouchDB.
Use Case: I am working on a process that retrieves the data from RDBMS and
process them into JSON document and POST them to the CouchDB.
I am trying to POST around half a million documents, most of them in batches
(_bulk_doc) of 10,000 and have tried with batch of 5,000, 15,000, and 20,000.
Whole process takes around 90-100 minutes.
During the life of the process, Memory Consumption by CouchDB keeps on
growing and memory is not released when CouchDB has finished working.
So if the memory consumption by CouchDB was 60% at the time process finishes,
memory consumption will remain 60% and not reducing.
Subsequently, when the process starts running again. memory consumption is
Maxed out and CouchDB restarts itself. This restart fails the process that I
am running. Looking at the Syslogs , I see Out Of Memory Error by the CouchDB
process and killing statement.
The CouchDb process that has the issue is the beam.smp of Erlang.
At this point, I have tried upgrading the memory of the server to see if this
resolves the issue, unfortunately, the issue persists. Memory Leak is there
and Usage keeps on growing until CouchDB restarts/crashed.
I also have tried running garbage collection from Erlang command
(erlang:garbage_collect().) line but it didn't do anything.
At this point, I am out of ideas and not sure what is going on here. Any
input/suggestion is highly appreciated!
Env:
Platform: Linux (Red Hat release 6.4 (Santiago))
CouchDB: 1.3 and have tried with 1.5 as well
RAM: Tried with 2G, 4G, and 8G
CPU: 2 cores
Process:/usr/lib64/erlang/erts-5.8.5/bin/beam.smp -Bd -K true -A 4 -- -root
/usr/lib64/erlang
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (COUCHDB-2058) CouchDB Memory Leak - Beam.smp
[
https://issues.apache.org/jira/browse/COUCHDB-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900480#comment-13900480
]
Adam Kocoloski commented on COUCHDB-2058:
-
Thanks. That looks like a) pretty significant memory fragmentation or b) a
memory leak in a NIF. Paul left some comments about disabling C code; one
option that you could try is to configure
{{code}}
[couchdb]
file_compression = none
{{code}}
CouchDB Memory Leak - Beam.smp
--
Key: COUCHDB-2058
URL: https://issues.apache.org/jira/browse/COUCHDB-2058
Project: CouchDB
Issue Type: Bug
Security Level: public(Regular issues)
Components: Database Core
Reporter: Rohit Sharma
Hello,
I am experiencing performance issue with CouchDB.
Use Case: I am working on a process that retrieves the data from RDBMS and
process them into JSON document and POST them to the CouchDB.
I am trying to POST around half a million documents, most of them in batches
(_bulk_doc) of 10,000 and have tried with batch of 5,000, 15,000, and 20,000.
Whole process takes around 90-100 minutes.
During the life of the process, Memory Consumption by CouchDB keeps on
growing and memory is not released when CouchDB has finished working.
So if the memory consumption by CouchDB was 60% at the time process finishes,
memory consumption will remain 60% and not reducing.
Subsequently, when the process starts running again. memory consumption is
Maxed out and CouchDB restarts itself. This restart fails the process that I
am running. Looking at the Syslogs , I see Out Of Memory Error by the CouchDB
process and killing statement.
The CouchDb process that has the issue is the beam.smp of Erlang.
At this point, I have tried upgrading the memory of the server to see if this
resolves the issue, unfortunately, the issue persists. Memory Leak is there
and Usage keeps on growing until CouchDB restarts/crashed.
I also have tried running garbage collection from Erlang command
(erlang:garbage_collect().) line but it didn't do anything.
At this point, I am out of ideas and not sure what is going on here. Any
input/suggestion is highly appreciated!
Env:
Platform: Linux (Red Hat release 6.4 (Santiago))
CouchDB: 1.3 and have tried with 1.5 as well
RAM: Tried with 2G, 4G, and 8G
CPU: 2 cores
Process:/usr/lib64/erlang/erts-5.8.5/bin/beam.smp -Bd -K true -A 4 -- -root
/usr/lib64/erlang
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (COUCHDB-2061) Problem with indexing npmjs reposioty - replication.
[
https://issues.apache.org/jira/browse/COUCHDB-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900540#comment-13900540
]
Adam Kocoloski commented on COUCHDB-2061:
-
It is annoying that the {{os_process_timeout}} error doesn't point to the
offending doc. You can try elevating the timeout in your server config:
{code}
[couchdb]
os_process_timeout = 3
{code}
and see if that allows the indexer to crunch whatever document is giving you
trouble.
Problem with indexing npmjs reposioty - replication.
Key: COUCHDB-2061
URL: https://issues.apache.org/jira/browse/COUCHDB-2061
Project: CouchDB
Issue Type: Bug
Security Level: public(Regular issues)
Components: Replication
Reporter: Kris
When I start the replication npmjs from http://isaacs.iriscouch.com/registry/
I don't have any packages shown in gui. In the log i see message:
{code}
[Wed, 12 Feb 2014 09:55:04 GMT] [info] [0.169.0] Opening index for db:
registry idx: _design/ui sig: d219c0be7f48a555a4ad0137e9b2b600
[Wed, 12 Feb 2014 09:55:04 GMT] [info] [0.188.0] Starting index update for
db: registry idx: _design/ui
[Wed, 12 Feb 2014 09:55:04 GMT] [info] [0.166.0] 10.214.8.13 - - GET
/registry/_all_docs?limit=0 200
[Wed, 12 Feb 2014 09:55:04 GMT] [info] [0.138.0] 10.214.8.28 - - GET
/registry/_design/ui/images/logo.png 200
[Wed, 12 Feb 2014 09:55:04 GMT] [info] [0.195.0] OS Process #Port0.3541
Log :: function raised exception (new
TypeError(doc.versions[doc['dist-tags'].latest].tags is undefined,
undefined, 3)) with doc._id tilemap
[Wed, 12 Feb 2014 09:55:04 GMT] [info] [0.195.0] OS Process #Port0.3541
Log :: function raised exception (new
TypeError(doc.versions[doc['dist-tags'].latest].tags is undefined,
undefined, 3)) with doc._id illumina2bam-tools
[Wed, 12 Feb 2014 09:55:04 GMT] [info] [0.195.0] OS Process #Port0.3541
Log :: function raised exception (new
TypeError(doc.versions[doc['dist-tags'].latest].tags is undefined,
undefined, 3)) with doc._id kick
[Wed, 12 Feb 2014 09:55:04 GMT] [info] [0.195.0] OS Process #Port0.3541
Log :: function raised exception (new
TypeError(doc.versions[doc['dist-tags'].latest].tags is undefined,
undefined, 3)) with doc._id redis2json
[Wed, 12 Feb 2014 09:55:04 GMT] [info] [0.195.0] OS Process #Port0.3541
Log :: function raised exception (new
TypeError(doc.versions[doc['dist-tags'].latest].tags is undefined,
undefined, 3)) with doc._id touchit
[Wed, 12 Feb 2014 09:55:04 GMT] [info] [0.195.0] OS Process #Port0.3541
Log :: function raised exception (new
TypeError(doc.versions[doc['dist-tags'].latest].tags is undefined,
undefined, 3)) with doc._id node-request-caching
[Wed, 12 Feb 2014 09:55:04 GMT] [info] [0.195.0] OS Process #Port0.3541
Log :: function raised exception (new
TypeError(doc.versions[doc['dist-tags'].latest].tags is undefined,
undefined, 3)) with doc._id score
[Wed, 12 Feb 2014 09:55:04 GMT] [info] [0.195.0] OS Process #Port0.3541
Log :: function raised exception (new
TypeError(doc.versions[doc['dist-tags'].latest].tags is undefined,
undefined, 3)) with doc._id frst
[Wed, 12 Feb 2014 09:55:04 GMT] [info] [0.195.0] OS Process #Port0.3541
Log :: function raised exception (new
TypeError(doc.versions[doc['dist-tags'].latest].tags is undefined,
undefined, 3)) with doc._id caboose-redis
[Wed, 12 Feb 2014 09:55:04 GMT] [info] [0.195.0] OS Process #Port0.3541
Log :: function raised exception (new
TypeError(doc.versions[doc['dist-tags'].latest].tags is undefined,
undefined, 3)) with doc._id convoy-less
[Wed, 12 Feb 2014 09:55:04 GMT] [info] [0.195.0] OS Process #Port0.3541
Log :: function raised exception (new
TypeError(doc.versions[doc['dist-tags'].latest].tags is undefined,
undefined, 3)) with doc._id up-hook
[Wed, 12 Feb 2014 09:55:04 GMT] [info] [0.195.0] OS Process #Port0.3541
Log :: function raised exception (new
TypeError(doc.versions[doc['dist-tags'].latest].tags is undefined,
undefined, 3)) with doc._id connect-recaptcha
[Wed, 12 Feb 2014 09:55:04 GMT] [info] [0.195.0] OS Process #Port0.3541
Log :: function raised exception (new
TypeError(doc.versions[doc['dist-tags'].latest].tags is undefined,
undefined, 3)) with doc._id locksmith
[Wed, 12 Feb 2014 09:55:04 GMT] [info] [0.195.0] OS Process #Port0.3541
Log :: function raised exception (new
TypeError(doc.versions[doc['dist-tags'].latest].tags is undefined,
undefined, 3)) with doc._id sorta
[Wed, 12 Feb 2014 09:55:04 GMT] [info] [0.195.0] OS Process #Port0.3541
Log :: function raised exception (new
TypeError(doc.versions[doc['dist-tags'].latest].tags is undefined,
undefined, 3)) with doc._id wreq
[Wed, 12 Feb 2014 09:55:04 GMT] [info] [0.195.0] OS Process #Port0.3541
Log :: function raised exception (new
[jira] [Commented] (COUCHDB-2044) Plugin to Review and Resolve Conflicts
[ https://issues.apache.org/jira/browse/COUCHDB-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889921#comment-13889921 ] Adam Kocoloski commented on COUCHDB-2044: - Seems like a solid idea. If I have N 2 leaf revisions are you planning to do a pairwise comparison? Plugin to Review and Resolve Conflicts -- Key: COUCHDB-2044 URL: https://issues.apache.org/jira/browse/COUCHDB-2044 Project: CouchDB Issue Type: Improvement Security Level: public(Regular issues) Components: Fauxton, Plugins Reporter: Maximilian Alexander Thayer Hey gang! First issue :O As a developer, I want a way to visually review and by-hand resolve conflicts as they appear. I'm plotting to build an app to do that as a Fauxton plugin for reviewing and resolving document conflicts. Documenting that intention here, at the behest of Simon Metson. If you've done any work on anything like this, let me know, yeah? Thanks! -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (COUCHDB-2034) authentication_handlers does not accept complex arguments
[
https://issues.apache.org/jira/browse/COUCHDB-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13882127#comment-13882127
]
Adam Kocoloski commented on COUCHDB-2034:
-
You're quite right [~danielmoore]; I came to the same realization the morning
after I left this edit but never noted it on the ticket. I still think it would
be preferable to have explicit labels and separate out the definitions, so e.g.
{code}
[httpd]
authentication_handlers = my_auth, basic, cookie, oauth
[httpd.authentication_handlers]
basic = {couch_httpd_auth, default_authentication_handler}
cookie = {couch_httpd_auth, cookie_authentication_handler}
oauth = {couch_httpd_oauth, oauth_authentication_handler}
my_auth = {my_mod, my_fun, [ { one, two }, { three, four } ] }
{code}
which has the advantage of being backwards compatible with current syntax if we
want it to be.
authentication_handlers does not accept complex arguments
-
Key: COUCHDB-2034
URL: https://issues.apache.org/jira/browse/COUCHDB-2034
Project: CouchDB
Issue Type: Bug
Reporter: Daniel Moore
Assignee: Adam Kocoloski
I have written a custom authentication handler for couch, but when I use the
SpecArg syntax with embedded tuples, I get parse errors spinning up the
server. For instance, a config like:
{code}
[httpd]
authentication_handlers = {my_mod, my_fun, [ { one, two }, { three, four } ] }
{code}
Gives:
{code}
[error] [0.93.0] {error_report,0.30.0,
{0.93.0,supervisor_report,
[{supervisor,{local,couch_secondary_services}},
{errorContext,start_error},
{reason,
{'EXIT',
{{case_clause,
{error,
{1,erl_parse,[syntax error before: ,'.']}}},
[{couch_httpd,make_arity_1_fun,1,
[{file,couch_httpd.erl},{line,200}]},
{couch_httpd,'-set_auth_handlers/0-fun-0-',1,
[{file,couch_httpd.erl},{line,194}]},
{lists,map,2,[{file,lists.erl},{line,1224}]},
{couch_httpd,set_auth_handlers,0,
[{file,couch_httpd.erl},{line,193}]},
{couch_httpd,start_link,2,
[{file,couch_httpd.erl},{line,130}]},
{supervisor,do_start_child,2,
[{file,supervisor.erl},{line,310}]},
{supervisor,start_children,3,
[{file,supervisor.erl},{line,293}]},
{supervisor,init_children,2,
[{file,supervisor.erl},{line,259}]}]}}},
{offender,
[{pid,undefined},
{name,httpd},
{mfargs,{couch_httpd,start_link,[]}},
{restart_type,permanent},
{shutdown,brutal_kill},
{child_type,worker}]}]}}
{code}
This seems to be as a result of [using a
regex|https://github.com/apache/couchdb/blob/master/src/couchdb/couch_httpd.erl?source=c#L224-L225]
to split the tuples. Perhaps we could change the strategy to wrapping the
string with \[ and \] and parsing it altogether?
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (COUCHDB-1606) Replicator leaves plaintext password in logs
[
https://issues.apache.org/jira/browse/COUCHDB-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881064#comment-13881064
]
Adam Kocoloski commented on COUCHDB-1606:
-
Yes, this is a thing. The Erlang VM does have a robust fix for the issue; you
can have a process declare itself as sensitive:
{code}
process_flag(sensitive, true)
{code}
It does have some interesting ramifications:
{quote}
Set or clear the sensitive flag for the current process. When a process has
been marked as sensitive by calling process_flag(sensitive, true), features in
the run-time system that can be used for examining the data and/or inner
working of the process are silently disabled.
Features that are disabled include (but are not limited to) the following:
Tracing: Trace flags can still be set for the process, but no trace messages of
any kind will be generated. (If the sensitive flag is turned off, trace
messages will again be generated if there are any trace flags set.)
Sequential tracing: The sequential trace token will be propagated as usual, but
no sequential trace messages will be generated.
process_info/1,2 cannot be used to read out the message queue or the process
dictionary (both will be returned as empty lists).
Stack back-traces cannot be displayed for the process.
In crash dumps, the stack, messages, and the process dictionary will be omitted.
If \{save_calls,N\} has been set for the process, no function calls will be
saved to the call saving list. (The call saving list will not be cleared;
furthermore, send, receive, and timeout events will still be added to the list.)
{quote}
Replicator leaves plaintext password in logs
Key: COUCHDB-1606
URL: https://issues.apache.org/jira/browse/COUCHDB-1606
Project: CouchDB
Issue Type: Bug
Components: Logging, Replication
Affects Versions: 1.2
Reporter: Nathan Vander Wilt
Assignee: Bob Dionne
Attachments: pwd log.txt
While reviewing logs, I noticed that a password had been recorded in the logs
as part of a replicator error.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (COUCHDB-2031) Paths ending in '/' rewrite query string params incorrectly
[
https://issues.apache.org/jira/browse/COUCHDB-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Kocoloski resolved COUCHDB-2031.
-
Resolution: Fixed
No worries, thanks for the review.
Paths ending in '/' rewrite query string params incorrectly
---
Key: COUCHDB-2031
URL: https://issues.apache.org/jira/browse/COUCHDB-2031
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Reporter: Eric Drechsel
Problem is discussed in this [SO
thread|http://stackoverflow.com/questions/5059499/access-couch-db-database-url-through-rewritten-url-with-query-parameters].
To summarize, with
{code:title=rewrites.js}
[ { from: /dbname/*, to: ../../* },
{ from: /*, to: * } ]
{code}
/dbname/?foo=bar doesn't work; it rewrites to /dbname/_design/..?foo=bar
instead.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (COUCHDB-2034) authentication_handlers does not accept complex arguments
[
https://issues.apache.org/jira/browse/COUCHDB-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878190#comment-13878190
]
Adam Kocoloski commented on COUCHDB-2034:
-
Yeesh, that regex needs to go away. Your solution makes sense to me and has
the nice property of not breaking the config syntax.
authentication_handlers does not accept complex arguments
-
Key: COUCHDB-2034
URL: https://issues.apache.org/jira/browse/COUCHDB-2034
Project: CouchDB
Issue Type: Bug
Reporter: Daniel Moore
I have written a custom authentication handler for couch, but when I use the
SpecArg syntax with embedded tuples, I get parse errors spinning up the
server. For instance, a config like:
{code}
[httpd]
authentication_handlers = {my_mod, my_fun, [ { one, two }, { three, four } ] }
{code}
Gives:
{code}
[error] [0.93.0] {error_report,0.30.0,
{0.93.0,supervisor_report,
[{supervisor,{local,couch_secondary_services}},
{errorContext,start_error},
{reason,
{'EXIT',
{{case_clause,
{error,
{1,erl_parse,[syntax error before: ,'.']}}},
[{couch_httpd,make_arity_1_fun,1,
[{file,couch_httpd.erl},{line,200}]},
{couch_httpd,'-set_auth_handlers/0-fun-0-',1,
[{file,couch_httpd.erl},{line,194}]},
{lists,map,2,[{file,lists.erl},{line,1224}]},
{couch_httpd,set_auth_handlers,0,
[{file,couch_httpd.erl},{line,193}]},
{couch_httpd,start_link,2,
[{file,couch_httpd.erl},{line,130}]},
{supervisor,do_start_child,2,
[{file,supervisor.erl},{line,310}]},
{supervisor,start_children,3,
[{file,supervisor.erl},{line,293}]},
{supervisor,init_children,2,
[{file,supervisor.erl},{line,259}]}]}}},
{offender,
[{pid,undefined},
{name,httpd},
{mfargs,{couch_httpd,start_link,[]}},
{restart_type,permanent},
{shutdown,brutal_kill},
{child_type,worker}]}]}}
{code}
This seems to be as a result of [using a
regex|https://github.com/apache/couchdb/blob/master/src/couchdb/couch_httpd.erl?source=c#L224-L225]
to split the tuples. Perhaps we could change the strategy to wrapping the
string with \[ and \] and parsing it altogether?
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Assigned] (COUCHDB-2034) authentication_handlers does not accept complex arguments
[
https://issues.apache.org/jira/browse/COUCHDB-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Kocoloski reassigned COUCHDB-2034:
---
Assignee: Adam Kocoloski
authentication_handlers does not accept complex arguments
-
Key: COUCHDB-2034
URL: https://issues.apache.org/jira/browse/COUCHDB-2034
Project: CouchDB
Issue Type: Bug
Reporter: Daniel Moore
Assignee: Adam Kocoloski
I have written a custom authentication handler for couch, but when I use the
SpecArg syntax with embedded tuples, I get parse errors spinning up the
server. For instance, a config like:
{code}
[httpd]
authentication_handlers = {my_mod, my_fun, [ { one, two }, { three, four } ] }
{code}
Gives:
{code}
[error] [0.93.0] {error_report,0.30.0,
{0.93.0,supervisor_report,
[{supervisor,{local,couch_secondary_services}},
{errorContext,start_error},
{reason,
{'EXIT',
{{case_clause,
{error,
{1,erl_parse,[syntax error before: ,'.']}}},
[{couch_httpd,make_arity_1_fun,1,
[{file,couch_httpd.erl},{line,200}]},
{couch_httpd,'-set_auth_handlers/0-fun-0-',1,
[{file,couch_httpd.erl},{line,194}]},
{lists,map,2,[{file,lists.erl},{line,1224}]},
{couch_httpd,set_auth_handlers,0,
[{file,couch_httpd.erl},{line,193}]},
{couch_httpd,start_link,2,
[{file,couch_httpd.erl},{line,130}]},
{supervisor,do_start_child,2,
[{file,supervisor.erl},{line,310}]},
{supervisor,start_children,3,
[{file,supervisor.erl},{line,293}]},
{supervisor,init_children,2,
[{file,supervisor.erl},{line,259}]}]}}},
{offender,
[{pid,undefined},
{name,httpd},
{mfargs,{couch_httpd,start_link,[]}},
{restart_type,permanent},
{shutdown,brutal_kill},
{child_type,worker}]}]}}
{code}
This seems to be as a result of [using a
regex|https://github.com/apache/couchdb/blob/master/src/couchdb/couch_httpd.erl?source=c#L224-L225]
to split the tuples. Perhaps we could change the strategy to wrapping the
string with \[ and \] and parsing it altogether?
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (COUCHDB-2034) authentication_handlers does not accept complex arguments
[
https://issues.apache.org/jira/browse/COUCHDB-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878213#comment-13878213
]
Adam Kocoloski commented on COUCHDB-2034:
-
Wow, after seeing how much work the codebase does to establish a name for each
of these handlers I really wish we would have done something like the following
in the config
{code}
[httpd.authentication_handlers]
basic = {couch_httpd_auth, default_authentication_handler}
cookie = {couch_httpd_auth, cookie_authentication_handler}
oauth = {couch_httpd_oauth, oauth_authentication_handler}
my_auth = {my_mod, my_fun, [ { one, two }, { three, four } ] }
{code}
On a related note, it's not clear to me where {{#user_ctx.handler}} gets used.
That code calls the auth_name function which does yet another regex on the spec
string to try to come up with a unique name for the handler.
I'll see what I can do to fix the current bug but I may also submit a separate
patch to support the config section version.
authentication_handlers does not accept complex arguments
-
Key: COUCHDB-2034
URL: https://issues.apache.org/jira/browse/COUCHDB-2034
Project: CouchDB
Issue Type: Bug
Reporter: Daniel Moore
I have written a custom authentication handler for couch, but when I use the
SpecArg syntax with embedded tuples, I get parse errors spinning up the
server. For instance, a config like:
{code}
[httpd]
authentication_handlers = {my_mod, my_fun, [ { one, two }, { three, four } ] }
{code}
Gives:
{code}
[error] [0.93.0] {error_report,0.30.0,
{0.93.0,supervisor_report,
[{supervisor,{local,couch_secondary_services}},
{errorContext,start_error},
{reason,
{'EXIT',
{{case_clause,
{error,
{1,erl_parse,[syntax error before: ,'.']}}},
[{couch_httpd,make_arity_1_fun,1,
[{file,couch_httpd.erl},{line,200}]},
{couch_httpd,'-set_auth_handlers/0-fun-0-',1,
[{file,couch_httpd.erl},{line,194}]},
{lists,map,2,[{file,lists.erl},{line,1224}]},
{couch_httpd,set_auth_handlers,0,
[{file,couch_httpd.erl},{line,193}]},
{couch_httpd,start_link,2,
[{file,couch_httpd.erl},{line,130}]},
{supervisor,do_start_child,2,
[{file,supervisor.erl},{line,310}]},
{supervisor,start_children,3,
[{file,supervisor.erl},{line,293}]},
{supervisor,init_children,2,
[{file,supervisor.erl},{line,259}]}]}}},
{offender,
[{pid,undefined},
{name,httpd},
{mfargs,{couch_httpd,start_link,[]}},
{restart_type,permanent},
{shutdown,brutal_kill},
{child_type,worker}]}]}}
{code}
This seems to be as a result of [using a
regex|https://github.com/apache/couchdb/blob/master/src/couchdb/couch_httpd.erl?source=c#L224-L225]
to split the tuples. Perhaps we could change the strategy to wrapping the
string with \[ and \] and parsing it altogether?
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (COUCHDB-2031) Paths ending in '/' rewrite query string params incorrectly
[
https://issues.apache.org/jira/browse/COUCHDB-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13876097#comment-13876097
]
Adam Kocoloski commented on COUCHDB-2031:
-
[~benoitc] any interest in reading through this patch before I merge?
Paths ending in '/' rewrite query string params incorrectly
---
Key: COUCHDB-2031
URL: https://issues.apache.org/jira/browse/COUCHDB-2031
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Reporter: Eric Drechsel
Problem is discussed in this [SO
thread|http://stackoverflow.com/questions/5059499/access-couch-db-database-url-through-rewritten-url-with-query-parameters].
To summarize, with
{code:title=rewrites.js}
[ { from: /dbname/*, to: ../../* },
{ from: /*, to: * } ]
{code}
/dbname/?foo=bar doesn't work; it rewrites to /dbname/_design/..?foo=bar
instead.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (COUCHDB-2031) Paths ending in '/' rewrite query string params incorrectly
[
https://issues.apache.org/jira/browse/COUCHDB-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875760#comment-13875760
]
Adam Kocoloski commented on COUCHDB-2031:
-
Ah, the test in this case would probably be in JavaScript in the rewrites.js
file.
Paths ending in '/' rewrite query string params incorrectly
---
Key: COUCHDB-2031
URL: https://issues.apache.org/jira/browse/COUCHDB-2031
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Reporter: Eric Drechsel
Problem is discussed in this [SO
thread|http://stackoverflow.com/questions/5059499/access-couch-db-database-url-through-rewritten-url-with-query-parameters].
To summarize, with
{code:title=rewrites.js}
[ { from: /dbname/*, to: ../../* },
{ from: /*, to: * } ]
{code}
/dbname/?foo=bar doesn't work; it rewrites to /dbname/_design/..?foo=bar
instead.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (COUCHDB-2031) Paths ending in '/' rewrite query string params incorrectly
[
https://issues.apache.org/jira/browse/COUCHDB-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875806#comment-13875806
]
Adam Kocoloski commented on COUCHDB-2031:
-
So I added a basic test, but interestingly enough it fails when the DB name
contains an encoded / (the rewriter is unable to bind the path). I can
modify the rewrite rule in the test to look for the unencoded DB name and make
a request like
GET
/test_suite_db%2Fwith_slashes/_design/test/_rewrite/test_suite_db/with_slashes/foo
which works, but that seems a bit incongruous. Looking for feedback here.
Paths ending in '/' rewrite query string params incorrectly
---
Key: COUCHDB-2031
URL: https://issues.apache.org/jira/browse/COUCHDB-2031
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Reporter: Eric Drechsel
Problem is discussed in this [SO
thread|http://stackoverflow.com/questions/5059499/access-couch-db-database-url-through-rewritten-url-with-query-parameters].
To summarize, with
{code:title=rewrites.js}
[ { from: /dbname/*, to: ../../* },
{ from: /*, to: * } ]
{code}
/dbname/?foo=bar doesn't work; it rewrites to /dbname/_design/..?foo=bar
instead.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (COUCHDB-2031) Paths ending in '/' rewrite query string params incorrectly
[
https://issues.apache.org/jira/browse/COUCHDB-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875808#comment-13875808
]
Adam Kocoloski commented on COUCHDB-2031:
-
Meh, that's beside the point of this ticket. Updating the test to just use
/db/ as the match that provides the raw DB API rather than using the actual
DB name.
Paths ending in '/' rewrite query string params incorrectly
---
Key: COUCHDB-2031
URL: https://issues.apache.org/jira/browse/COUCHDB-2031
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Reporter: Eric Drechsel
Problem is discussed in this [SO
thread|http://stackoverflow.com/questions/5059499/access-couch-db-database-url-through-rewritten-url-with-query-parameters].
To summarize, with
{code:title=rewrites.js}
[ { from: /dbname/*, to: ../../* },
{ from: /*, to: * } ]
{code}
/dbname/?foo=bar doesn't work; it rewrites to /dbname/_design/..?foo=bar
instead.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (COUCHDB-2032) Include repo name in commits@ emails
Adam Kocoloski created COUCHDB-2032: --- Summary: Include repo name in commits@ emails Key: COUCHDB-2032 URL: https://issues.apache.org/jira/browse/COUCHDB-2032 Project: CouchDB Issue Type: Improvement Components: Infrastructure Reporter: Adam Kocoloski Now that we're in the brave new world of repo-per-application it'd be nice to include the name of the repository in the Subject header of emails sent to commits@. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (COUCHDB-2032) Include repo name in commits@ emails
[ https://issues.apache.org/jira/browse/COUCHDB-2032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Kocoloski updated COUCHDB-2032: Priority: Trivial (was: Major) Assignee: Paul Joseph Davis Include repo name in commits@ emails Key: COUCHDB-2032 URL: https://issues.apache.org/jira/browse/COUCHDB-2032 Project: CouchDB Issue Type: Improvement Components: Infrastructure Reporter: Adam Kocoloski Assignee: Paul Joseph Davis Priority: Trivial Now that we're in the brave new world of repo-per-application it'd be nice to include the name of the repository in the Subject header of emails sent to commits@. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (COUCHDB-2032) Include repo name in commits@ emails
[ https://issues.apache.org/jira/browse/COUCHDB-2032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875461#comment-13875461 ] Adam Kocoloski commented on COUCHDB-2032: - Following cordova's syntax makes sense to me in the absence of any compelling reason not to do so. Include repo name in commits@ emails Key: COUCHDB-2032 URL: https://issues.apache.org/jira/browse/COUCHDB-2032 Project: CouchDB Issue Type: Improvement Components: Infrastructure Reporter: Adam Kocoloski Assignee: Paul Joseph Davis Priority: Trivial Now that we're in the brave new world of repo-per-application it'd be nice to include the name of the repository in the Subject header of emails sent to commits@. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (COUCHDB-2031) Paths ending in '/' rewrite query string params incorrectly
[
https://issues.apache.org/jira/browse/COUCHDB-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875551#comment-13875551
]
Adam Kocoloski commented on COUCHDB-2031:
-
The rewriter is not really my area of expertise but it looks like the issue is
that the normalization code partitions paths based on / and then looks
specifically for .. when removing path parts, but we feed it an input that
already has the bound qs params tacked onto the code. I refactored a little
bit to normalize the path before appending the query string. Existing tests
pass, I haven't added one specifically for this bug yet.
Paths ending in '/' rewrite query string params incorrectly
---
Key: COUCHDB-2031
URL: https://issues.apache.org/jira/browse/COUCHDB-2031
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Reporter: Eric Drechsel
Problem is discussed in this [SO
thread|http://stackoverflow.com/questions/5059499/access-couch-db-database-url-through-rewritten-url-with-query-parameters].
To summarize, with
{code:title=rewrites.js}
[ { from: /dbname/*, to: ../../* },
{ from: /*, to: * } ]
{code}
/dbname/?foo=bar doesn't work; it rewrites to /dbname/_design/..?foo=bar
instead.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (COUCHDB-2002) Implement a hard cap on OS process count in couch_proc_manager
[ https://issues.apache.org/jira/browse/COUCHDB-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Kocoloski updated COUCHDB-2002: Summary: Implement a hard cap on OS process count in couch_proc_manager (was: Implement couch_proc_manager) Implement a hard cap on OS process count in couch_proc_manager -- Key: COUCHDB-2002 URL: https://issues.apache.org/jira/browse/COUCHDB-2002 Project: CouchDB Issue Type: Improvement Components: BigCouch Reporter: Volker Mische We need to implement the hard ceiling for capping the number of OS processes. We’ve started seeing a need for this at Cloudant with some work loads so motivation to fix this is high. The only failing etap is the assertion of this ceiling. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (COUCHDB-1946) Trying to replicate NPM grinds to a halt after 40GB
[ https://issues.apache.org/jira/browse/COUCHDB-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13857222#comment-13857222 ] Adam Kocoloski commented on COUCHDB-1946: - Hi [~indexzero], there are absolutely material differences for local vs. remote replications -- that's one axis I've been meaning to explore as soon as I have a chance to re-engage on this ticket. For example, I've not seen this happen on a replication to Cloudant (which has no real notion of a local replication). The other thing I'd love to see happen is a narrowing down of the list of affected versions; 1.2.0..1.5.0 is an awfully large changeset to bisect. Trying to replicate NPM grinds to a halt after 40GB --- Key: COUCHDB-1946 URL: https://issues.apache.org/jira/browse/COUCHDB-1946 Project: CouchDB Issue Type: Bug Components: Database Core Reporter: Marc Trudel Attachments: couch.log I have been able to replicate the Node.js NPM database until 40G or so, then I get this: https://gist.github.com/stelcheck/7723362 I one case I have gotten a flat-out OOM error, but I didn't take a dump of the log output at the time. CentOS6.4 with CouchDB 1.5 (also tried 1.3.1, but to no avail). Also tried to restart replication from scratch - twice - bot cases stalling at 40GB. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (COUCHDB-1963) Move from etap to eunit
[ https://issues.apache.org/jira/browse/COUCHDB-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13848670#comment-13848670 ] Adam Kocoloski commented on COUCHDB-1963: - +1 vote in support of this ticket 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 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.1.4#6159)
[jira] [Commented] (COUCHDB-154) Support gzip content in POST requests
[ https://issues.apache.org/jira/browse/COUCHDB-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13848674#comment-13848674 ] Adam Kocoloski commented on COUCHDB-154: [~rnewson] tossed a commit of mine up at https://git-wip-us.apache.org/repos/asf?p=couchdb.git;h=899a919 that adds this capability, but there's a follow-on commit to handle errors during decompression. I'll update the branch shortly. Support gzip content in POST requests - Key: COUCHDB-154 URL: https://issues.apache.org/jira/browse/COUCHDB-154 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Affects Versions: 0.9 Reporter: Ask Bjørn Hansen When sending large amounts of data to CouchDB it'd be nice to have support for Content-Encoding: gzip or Transfer-Encoding: gzip (in the client to server direction). -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (COUCHDB-154) Support gzip content in POST requests
[ https://issues.apache.org/jira/browse/COUCHDB-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13848678#comment-13848678 ] Adam Kocoloski commented on COUCHDB-154: OK, branch updated, should be good to go. Support gzip content in POST requests - Key: COUCHDB-154 URL: https://issues.apache.org/jira/browse/COUCHDB-154 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Affects Versions: 0.9 Reporter: Ask Bjørn Hansen When sending large amounts of data to CouchDB it'd be nice to have support for Content-Encoding: gzip or Transfer-Encoding: gzip (in the client to server direction). -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (COUCHDB-1946) Trying to replicate NPM grinds to a halt after 40GB
[
https://issues.apache.org/jira/browse/COUCHDB-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13840949#comment-13840949
]
Adam Kocoloski commented on COUCHDB-1946:
-
I played with setting the {{\{fullsweep_after, 0\}}} option on {{couch_file}}
and {{couch_stream}}. It didn't have much of an effect on {{couch_stream}}
(not surprising since I was already hibernating the server after each write,
but it reduced the memory consumption of the {{couch_file}} down to ~nothing.
The reason for the {{couch_stream}} refc binary memory consumption continues to
elude me. I think the next step may to head up the stack towards the
replicator processes. Still, progress.
Trying to replicate NPM grinds to a halt after 40GB
---
Key: COUCHDB-1946
URL: https://issues.apache.org/jira/browse/COUCHDB-1946
Project: CouchDB
Issue Type: Bug
Components: Database Core
Reporter: Marc Trudel
Attachments: couch.log
I have been able to replicate the Node.js NPM database until 40G or so, then
I get this:
https://gist.github.com/stelcheck/7723362
I one case I have gotten a flat-out OOM error, but I didn't take a dump of
the log output at the time.
CentOS6.4 with CouchDB 1.5 (also tried 1.3.1, but to no avail). Also tried to
restart replication from scratch - twice - bot cases stalling at 40GB.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (COUCHDB-1946) Trying to replicate NPM grinds to a halt after 40GB
[
https://issues.apache.org/jira/browse/COUCHDB-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839738#comment-13839738
]
Adam Kocoloski commented on COUCHDB-1946:
-
Hmm, this is certainly strange. Does restarting the replication after the
crash cause it to crash again?
If you happen to have an Erlang shell on the node when it's starts leaking
memory I'd be curious to see the output of something like
lists:reverse(lists:sort([{process_info(P, [memory,initial_call,dictionary]),
P} || P - processes()])).
Trying to replicate NPM grinds to a halt after 40GB
---
Key: COUCHDB-1946
URL: https://issues.apache.org/jira/browse/COUCHDB-1946
Project: CouchDB
Issue Type: Bug
Components: Database Core
Reporter: Marc Trudel
Attachments: couch.log
I have been able to replicate the Node.js NPM database until 40G or so, then
I get this:
https://gist.github.com/stelcheck/7723362
I one case I have gotten a flat-out OOM error, but I didn't take a dump of
the log output at the time.
CentOS6.4 with CouchDB 1.5 (also tried 1.3.1, but to no avail). Also tried to
restart replication from scratch - twice - bot cases stalling at 40GB.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (COUCHDB-1797) Query against a view w/ include_docs=true yields doc:null
[
https://issues.apache.org/jira/browse/COUCHDB-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13817387#comment-13817387
]
Adam Kocoloski commented on COUCHDB-1797:
-
I think that patch has too much of a performance impact to merge (it's a
gen_server:call per view row), but I do see a race condition here that could
lead to these {not_found, missing} / null results.
If you look at the code where we obtain the view group state:
https://github.com/apache/couchdb/blob/1.5.0/src/couch_mrview/src/couch_mrview.erl#L75
you can see that we already have the Db open. couch_mrivew ensures that the
index state we return is at a sequence = the sequence of the Db:
https://github.com/apache/couchdb/blob/1.5.0/src/couch_mrview/src/couch_mrview_util.erl#L41-L50
It's quite possible that couch_index had to fire off an updater to satisfy that
condition, and when the updater starts it gets the latest Db:
https://github.com/apache/couchdb/blob/1.5.0/src/couch_index/src/couch_index_updater.erl#L129
If updates landed in between opening the Db used by query_view and opening the
Db used by couch_index_updater then we can end up with updates in the view
index that are not yet accessible by the Db held by query_view. Attempts to
open these latest docs will then come back with {not_found, missing}.
Re-opening the Db in query_view after we receive the index state but before we
start the fold alleviates the performance impact, but it's still a race
condition. The {not_found, missing} errors will disappear, but in their place
we might end up with {not_found, deleted} errors or documents that are at a
newer revision than the revision that was included in the index.
A really strictly consistent solution would have to find a way to communicate
the exact #db used by the indexer back to the query handler. That's
non-trivial to say the least.
I'm not opposed to a single reopen in the query handler after we receive the
index state (maybe we can make it conditional on the sequence of the secondary
index being greater than the sequence of the original DB), but we should be
clear that it really just trades one inconsistency for another.
Query against a view w/ include_docs=true yields doc:null
-
Key: COUCHDB-1797
URL: https://issues.apache.org/jira/browse/COUCHDB-1797
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 1.3
Reporter: Marten Feldtmann
Priority: Critical
Attachments:
0001-fix-null-doc-or-doc-not-found-when-including-it-in-a.patch
I have a test system (CouchDB 1.3.0 under windows 7/64 Bit), where I insert
lots of documents(10) to get a regular flow of new incoming documents.
The database has also some views (25). Another task is reading documents from
a view, change some attributes and then the document should disappear from
the view (and appear in another view). Something like a state machine.
I do the following query against a view:
http://localhost:5984/test5/_design/ticketorggraphics/_view/waiting?limit=5include_docs=trueinclude_end=true
and get the following string:
{total_rows:9224,offset:0,rows:[
{id:92224c2862ef49c15f3d51e3e7283cde,key:ni13_1_2013101_20130518155518065,value:ni13_2013101_VsPercentResult_83519204509647,doc:{_id:92224c2862ef49c15f3d51e3e7283cde,_rev:1-6e8b57744c2b88f3d2dcad602e2e3353,distribution:global,type:ESTicketCreateOriginalGraphic,createdTS:20130518155518065,priority:1,eDayID:ni13,electionID:2013101,layout:ard2013,baseDocKey:ni13_2013101_VsPercentResult_83519204509647,_attachments:{bclitemsdata:{content_type:application/zip,revpos:1,digest:md5-sdff2jkxp4w6xsSlx5Yzxw==,length:4533,stub:true,
{id:92224c2862ef49c15f3d51e3e7285d38,key:ni13_1_2013101_20130518155518135,value:ni13_2013101_VsPercentResult_16771681663808,doc:{_id:92224c2862ef49c15f3d51e3e7285d38,_rev:1-05b92282ec5f2d1b6d56912760792702,distribution:global,type:ESTicketCreateOriginalGraphic,createdTS:20130518155518135,priority:1,eDayID:ni13,electionID:2013101,layout:ard2013,baseDocKey:ni13_2013101_VsPercentResult_16771681663808,_attachments:{bclitemsdata:{content_type:application/zip,revpos:1,digest:md5-sdff2jkxp4w6xsSlx5Yzxw==,length:4533,stub:true,
{id:92224c2862ef49c15f3d51e3e728c5e2,key:ni13_1_2013101_20130518155518413,value:ni13_2013101_VsPercentResult_10619936276742,doc:null},
[jira] [Created] (COUCHDB-1901) Replicator needs to retry multipart requests atomically
Adam Kocoloski created COUCHDB-1901: --- Summary: Replicator needs to retry multipart requests atomically Key: COUCHDB-1901 URL: https://issues.apache.org/jira/browse/COUCHDB-1901 Project: CouchDB Issue Type: Bug Components: Replication Reporter: Adam Kocoloski couch_replicator_httpc's retry mechanism interacts poorly with the multipart requests we use to transfer attachments during replication. In the case of PUTs, the replicator will retry a request even though it has already streamed part of the request body. For GETs, it can potentially interleave body data from the original response and the retried one. I put together a fix at https://github.com/cloudant/couch_replicator/pull/36 that disables the default httpc client retry mechanism for multipart requests and manages the retry logic atomically; i.e., it retries the original GET request if the GET or PUT fails, and it ensures that the original GET request is properly terminated during the retry. I'll push a version of that patch to the Apache repo now. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (COUCHDB-1901) Replicator needs to retry multipart requests atomically
[ https://issues.apache.org/jira/browse/COUCHDB-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Kocoloski updated COUCHDB-1901: Fix Version/s: 1.5.0 Assignee: Adam Kocoloski Replicator needs to retry multipart requests atomically --- Key: COUCHDB-1901 URL: https://issues.apache.org/jira/browse/COUCHDB-1901 Project: CouchDB Issue Type: Bug Components: Replication Reporter: Adam Kocoloski Assignee: Adam Kocoloski Fix For: 1.5.0 couch_replicator_httpc's retry mechanism interacts poorly with the multipart requests we use to transfer attachments during replication. In the case of PUTs, the replicator will retry a request even though it has already streamed part of the request body. For GETs, it can potentially interleave body data from the original response and the retried one. I put together a fix at https://github.com/cloudant/couch_replicator/pull/36 that disables the default httpc client retry mechanism for multipart requests and manages the retry logic atomically; i.e., it retries the original GET request if the GET or PUT fails, and it ensures that the original GET request is properly terminated during the retry. I'll push a version of that patch to the Apache repo now. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (COUCHDB-1901) Replicator needs to retry multipart requests atomically
[ https://issues.apache.org/jira/browse/COUCHDB-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13784223#comment-13784223 ] Adam Kocoloski commented on COUCHDB-1901: - I pushed a pull request at https://github.com/apache/couchdb/pull/95 which includes the work from the aforementioned Cloudant PR as well as some earlier fixes by [~paul.joseph.davis] regarding connection handling in the multipart workflow. Replicator needs to retry multipart requests atomically --- Key: COUCHDB-1901 URL: https://issues.apache.org/jira/browse/COUCHDB-1901 Project: CouchDB Issue Type: Bug Components: Replication Reporter: Adam Kocoloski Assignee: Adam Kocoloski Fix For: 1.5.0 couch_replicator_httpc's retry mechanism interacts poorly with the multipart requests we use to transfer attachments during replication. In the case of PUTs, the replicator will retry a request even though it has already streamed part of the request body. For GETs, it can potentially interleave body data from the original response and the retried one. I put together a fix at https://github.com/cloudant/couch_replicator/pull/36 that disables the default httpc client retry mechanism for multipart requests and manages the retry logic atomically; i.e., it retries the original GET request if the GET or PUT fails, and it ensures that the original GET request is properly terminated during the retry. I'll push a version of that patch to the Apache repo now. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (COUCHDB-1830) IO timeout not configurable
[ https://issues.apache.org/jira/browse/COUCHDB-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13689272#comment-13689272 ] Adam Kocoloski commented on COUCHDB-1830: - Thanks for this report. It looks like the timeout happens on a call to couch_index_updater:run/2. Perusing that gen_server implementation I don't see much at all that would cause the server to take 5 seconds to respond -- almost everything is async. Curious. IO timeout not configurable --- Key: COUCHDB-1830 URL: https://issues.apache.org/jira/browse/COUCHDB-1830 Project: CouchDB Issue Type: Bug Components: JavaScript View Server Affects Versions: 1.3 Reporter: Stefan Kögl Priority: Minor Labels: timeout I occasionally encounter the timeout shown in the log at https://gist.github.com/stefankoegl/5772860. According to [~janl] in #couchdb this is a generic gen_Server timeout (5s) and currently not configurable. As this might not be enough in some circumstances, there should probably be a setting for this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-808) Zero byte .compact file prevents compaction
[
https://issues.apache.org/jira/browse/COUCHDB-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13673117#comment-13673117
]
Adam Kocoloski commented on COUCHDB-808:
Thanks Jan, I should have thought of that.
Zero byte .compact file prevents compaction
---
Key: COUCHDB-808
URL: https://issues.apache.org/jira/browse/COUCHDB-808
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 0.11
Reporter: Robert Newson
Assignee: Adam Kocoloski
Fix For: 1.2
Couchdb can make a .compact file when the volume is almost out of disk
space and then crash before writing the header.
If you then clean some space and try to compact again, it won't ever work.
[Wed, 23 Jun 2010 16:11:59 GMT] [error] [emulator] Error in process
0.1976.0 with exit value:
{{badmatch,no_valid_header},[{couch_db_updater,start_copy_compact,1}]}
The presence of the invalid .compact file prevents it, and needs to be
manually removed.
Remedy: delete the .compact file if there is no valid header when _compact is
called for the second time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1736) Database aliases
[ https://issues.apache.org/jira/browse/COUCHDB-1736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13671787#comment-13671787 ] Adam Kocoloski commented on COUCHDB-1736: - In my opinion COUCHDB-1735 is superseded by this ticket. If we have an aliasing system then a rename can be something like an alias creation and deletion. In the description on COUCHDB-1735 Dave mentions that the BigCouch code may complicate this feature addition. I'm biased, but I actually think it provides a really nice place to implement it. In the BigCouch world every logical database has a partition table that lists the names and locations of the shard files that comprise it. That partition table is stored as a document in a special system DB which is replicated to every node in a cluster. I believe we can implement aliases as partition table documents that either point to the canonical partition table document for the DB (the ln option) or else list the original shard names explicitly (the cp option). Does that make sense? Database aliases Key: COUCHDB-1736 URL: https://issues.apache.org/jira/browse/COUCHDB-1736 Project: CouchDB Issue Type: Improvement Reporter: Dave Cottlehuber Labels: couchdb, erlang, gsoc2013 Support redirecting database names at HTTP layer. e.g. GET /foo is passed to /bar database internally. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1401) Add ability to configure (HTTP) log format (mod_log_config)
[ https://issues.apache.org/jira/browse/COUCHDB-1401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Kocoloski updated COUCHDB-1401: Component/s: Logging Add ability to configure (HTTP) log format (mod_log_config) --- Key: COUCHDB-1401 URL: https://issues.apache.org/jira/browse/COUCHDB-1401 Project: CouchDB Issue Type: Improvement Components: Logging Reporter: Timo Kissing I am sure there are many use cases, but in the one I am facing CouchDB is running behind a reverse proxy which means a lot of useful information is in prefixed, non-standard headers that are currently not logged. Would be great to have an equivalent to http://httpd.apache.org/docs/2.0/mod/mod_log_config.html in CouchDB -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-706) Add support for logging to syslog
[ https://issues.apache.org/jira/browse/COUCHDB-706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Kocoloski updated COUCHDB-706: --- Component/s: Logging Add support for logging to syslog - Key: COUCHDB-706 URL: https://issues.apache.org/jira/browse/COUCHDB-706 Project: CouchDB Issue Type: New Feature Components: Database Core, Infrastructure, Logging Reporter: Jan Lehnardt Priority: Minor Labels: easy Attachments: syslog.patch http://github.com/ngerakines/syslognif could be of help. Integrating this with CouchDB should be reasonably simple with some guidance and would be a good project for somebody who wants to start sending patches. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1676) Webkit and Node.js logging compatibility
[ https://issues.apache.org/jira/browse/COUCHDB-1676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Kocoloski updated COUCHDB-1676: Component/s: Logging Webkit and Node.js logging compatibility Key: COUCHDB-1676 URL: https://issues.apache.org/jira/browse/COUCHDB-1676 Project: CouchDB Issue Type: New Feature Components: JavaScript View Server, Logging Reporter: Jason Smith The log() function in the default query server is barely serviceable. People now expect console.log() support as with modern browsers and in Node.js. This ticket is to extend the user-facing JS API to feel more like Node.js (which presumably designed its API to feel right by some definition). 1. util.format() support compatible with Node.js. (It's like Perl's sprintf) 2. console.log() support compatible with Node.js. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1677) Dedicated query server log file
[ https://issues.apache.org/jira/browse/COUCHDB-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669318#comment-13669318 ] Adam Kocoloski commented on COUCHDB-1677: - Would love to see this happen. Dedicated query server log file --- Key: COUCHDB-1677 URL: https://issues.apache.org/jira/browse/COUCHDB-1677 Project: CouchDB Issue Type: New Feature Components: View Server Support Reporter: Jason Smith Admins should be able to configure an additional log file, which only contains logs coming from query servers (i.e. `log()` in the built-in JavaScript one). [log] query_server_file = js.log This creates an additional log file (relative to the dirname of _config/log/file) to which log messages from the query server are copied. (The original log file contents are unaffected by this feature.) The query_server_file has no prefix or formatting (such as timestamps). It should feel like a direct tap into console.log(). If people want to add structure or timestamps to their log file, they can do it in the application. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1786) Logs can be sent/received in json format.
[ https://issues.apache.org/jira/browse/COUCHDB-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Kocoloski updated COUCHDB-1786: Component/s: Logging Logs can be sent/received in json format. - Key: COUCHDB-1786 URL: https://issues.apache.org/jira/browse/COUCHDB-1786 Project: CouchDB Issue Type: Improvement Components: HTTP Interface, Logging Reporter: Garren Smith We couchdb logs are requested (http://127.0.0.1:5984/_log) they are currently returned in a text format. It would be nice to have the option of getting them returned in json format. This makes it easier to work with them in javascript or any other language as we would not need to do heavy parsing on the logs. I originally submitted this as a pull request (https://github.com/apache/couchdb/pull/39) but its more appropriate to have it as an issue. As this stage the code submitted is not good enough to be merged in. If someone else is interested in improving or rewriting this it would be great. If we could make this an http EventSource that would be great as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1278) Add Apache httpd-style common log access logging.
[ https://issues.apache.org/jira/browse/COUCHDB-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Kocoloski updated COUCHDB-1278: Component/s: Logging Add Apache httpd-style common log access logging. - Key: COUCHDB-1278 URL: https://issues.apache.org/jira/browse/COUCHDB-1278 Project: CouchDB Issue Type: New Feature Components: Logging Reporter: Jan Lehnardt This module introduces a new log file couch_access.log in the spirit of Apache httpd's access.log. The log format is specified here: http://en.wikipedia.org/wiki/Common_Log_Format The module defaults to the more commonly used `extended` format, but can be configured to use the standard log format as well. This is a new module rather than an extension to the couch_log module to allow easy addition. Ideally, this will be a plugin in the future. A note for chunked responses, the response body length reported is chunked rather than the number of bytes. The case is unspecified in the format description. Maybe the fix is keeping track of bytes sent in a chunked response, but I didn't want to make the first stab at this more complicated that it has to be. I'm happy to adjust. See the full diff here: https://github.com/janl/couchdb/commit/614091e49380b3afab3c34ff65e6d87623059b8b I'm not proposing this to be added to 1.1.x, but if anybody wants it, there's a patch here: https://github.com/janl/couchdb/commit/508af053257c074ec37c9bd658479cc21b8d20d4 (The only difference is the specification of the couch_access_log module on startup, as that moved from couch_server_sup.erl to couch_primary_services.erl) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1677) Dedicated query server log file
[ https://issues.apache.org/jira/browse/COUCHDB-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Kocoloski updated COUCHDB-1677: Component/s: Logging Dedicated query server log file --- Key: COUCHDB-1677 URL: https://issues.apache.org/jira/browse/COUCHDB-1677 Project: CouchDB Issue Type: New Feature Components: Logging, View Server Support Reporter: Jason Smith Admins should be able to configure an additional log file, which only contains logs coming from query servers (i.e. `log()` in the built-in JavaScript one). [log] query_server_file = js.log This creates an additional log file (relative to the dirname of _config/log/file) to which log messages from the query server are copied. (The original log file contents are unaffected by this feature.) The query_server_file has no prefix or formatting (such as timestamps). It should feel like a direct tap into console.log(). If people want to add structure or timestamps to their log file, they can do it in the application. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-814) Improve error logging
[
https://issues.apache.org/jira/browse/COUCHDB-814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Kocoloski updated COUCHDB-814:
---
Component/s: Logging
Improve error logging
-
Key: COUCHDB-814
URL: https://issues.apache.org/jira/browse/COUCHDB-814
Project: CouchDB
Issue Type: Improvement
Components: Logging, View Server Support
Affects Versions: 0.10
Environment: Ubuntu Lucid Lynx
Reporter: Julian Moritz
Priority: Minor
When defining the path to a view server and using a non-existing target, the
error message in my case was
[Sun, 04 Jul 2010 08:48:06 GMT] [error] [0.108.0] ** Generic server
0.108.0 terminating
** Last message in was {'EXIT',0.111.0,epipe}
** When Server state == {group_state,undefined,web,
{/var/lib/couchdb/0.10.0,web,
{group,
54,48,77,50,3,129,147,16,223,202,27,98,9,139,74,
233,
{db,0.71.0,0.72.0,nil,1278233277155316,
0.69.0,0.75.0,
{db_header,4,16,0,
{738330,{8,1}},
{739403,9},
nil,0,nil,nil,1000},
16,
{btree,0.69.0,
{738330,{8,1}},
#Funcouch_db_updater.8.117532479,
#Funcouch_db_updater.9.105507025,
#Funcouch_db_updater.7.32442936,
#Funcouch_db_updater.10.43662179},
{btree,0.69.0,
{739403,9},
#Funcouch_db_updater.11.41695917,
#Funcouch_db_updater.12.6934644,
#Funcouch_btree.5.124754102,
#Funcouch_db_updater.13.28245598},
{btree,0.69.0,nil,#Funcouch_btree.0.83553141,
#Funcouch_btree.1.30790806,
#Funcouch_btree.2.124754102,nil},
16,web,/var/lib/couchdb/0.10.0/web.couch,
[],[],nil,
{user_ctx,null,[]},
nil,1000,
[before_header,after_header,on_file_open]},
nil,_temp,python,[],
[{view,0,
[_temp],
def fun(doc):\n yield None,
doc,nil,[]}],
nil,0,0,nil,nil}},
{group,
54,48,77,50,3,129,147,16,223,202,27,98,9,139,74,233,
{db,0.71.0,0.72.0,nil,1278233277155316,
0.69.0,0.75.0,
{db_header,4,16,0,
{738330,{8,1}},
{739403,9},
nil,0,nil,nil,1000},
16,
{btree,0.69.0,
{738330,{8,1}},
#Funcouch_db_updater.8.117532479,
#Funcouch_db_updater.9.105507025,
#Funcouch_db_updater.7.32442936,
#Funcouch_db_updater.10.43662179},
{btree,0.69.0,
{739403,9},
#Funcouch_db_updater.11.41695917,
#Funcouch_db_updater.12.6934644,
#Funcouch_btree.5.124754102,
#Funcouch_db_updater.13.28245598},
{btree,0.69.0,nil,#Funcouch_btree.0.83553141,
#Funcouch_btree.1.30790806,
#Funcouch_btree.2.124754102,nil},
16,web,/var/lib/couchdb/0.10.0/web.couch,
[],[],nil,
{user_ctx,null,[]},
nil,1000,
[before_header,after_header,on_file_open]},
0.109.0,_temp,python,[],
[{view,0,
[_temp],
def fun(doc):\n yield None, doc,
{btree,0.109.0,nil,
#Funcouch_btree.3.83553141,
#Funcouch_btree.4.30790806,
#Funcouch_view.less_json_keys.2,
#Funcouch_view_group.11.46347864},
[]}],
{btree,0.109.0,nil,#Funcouch_btree.0.83553141,
#Funcouch_btree.1.30790806,
#Funcouch_btree.2.124754102,nil},
0,0,nil,nil},
0.111.0,nil,false,
[jira] [Updated] (COUCHDB-1626) BASIC auth password appear in log in plaintext during an error
[
https://issues.apache.org/jira/browse/COUCHDB-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Kocoloski updated COUCHDB-1626:
Component/s: Logging
Description:
During testing, I see in the log that the password use in BASIC Auth was hidden
by *.
But when i try a replication who tell a ERRConn. The stack trace of error
contain the password in plain-text.
And store in log file.
I doubt it's a debug feature.
I paste my couch log here: I hidden private info my self with A
Tue, 11 Dec 2012 13:46:14 GMT] [info] [0.379.0] Retrying HEAD request to
https://lucas-A-1:*@backup-1.AA.cc/lucas-A-1/ in
16.0 seconds due to error {conn_failed,{error,eoptions}}
[Tue, 11 Dec 2012 13:46:28 GMT] [info] [0.133.0] 10.0.0.23 - - POST
/_replicate 500
[Tue, 11 Dec 2012 13:46:28 GMT] [error] [0.389.0] ** Generic server
0.389.0 terminating
** Last message in was {'EXIT',0.379.0,killed}
** When Server state == {state,https://lucas--1:--HERE MY PASS IN
PLAINTEXT@
backup-1.A.cc/lucas-A-1/,
20,[],[],
{[],[]}}
** Reason for termination ==
** killed
[Tue, 11 Dec 2012 13:46:28 GMT] [error] [0.389.0] {error_report,0.31.0,
{0.389.0,crash_report,
[[{initial_call,
{couch_httpc_pool,init,['Argument__1']}},
{pid,0.389.0},
{registered_name,[]},
{error_info,
{exit,killed,
[{gen_server,terminate,6},
{proc_lib,init_p_do_apply,3}]}},
{ancestors,
[0.379.0,couch_rep_sup,
couch_primary_services,couch_server_sup,
0.32.0]},
{messages,[]},
{links,[]},
{dictionary,[]},
{trap_exit,true},
{status,running},
{heap_size,377},
{stack_size,24},
{reductions,496}],
[]]}}
Contact me on my account email for more information or here.
Best regards
Lucas
was:
During testing, I see in the log that the password use in BASIC Auth was hidden
by *.
But when i try a replication who tell a ERRConn. The stack trace of error
contain the password in plain-text.
And store in log file.
I doubt it's a debug feature.
I paste my couch log here: I hidden private info my self with A
Tue, 11 Dec 2012 13:46:14 GMT] [info] [0.379.0] Retrying HEAD request to
https://lucas-A-1:*@backup-1.AA.cc/lucas-A-1/ in
16.0 seconds due to error {conn_failed,{error,eoptions}}
[Tue, 11 Dec 2012 13:46:28 GMT] [info] [0.133.0] 10.0.0.23 - - POST
/_replicate 500
[Tue, 11 Dec 2012 13:46:28 GMT] [error] [0.389.0] ** Generic server
0.389.0 terminating
** Last message in was {'EXIT',0.379.0,killed}
** When Server state == {state,https://lucas--1:--HERE MY PASS IN
PLAINTEXT@
backup-1.A.cc/lucas-A-1/,
20,[],[],
{[],[]}}
** Reason for termination ==
** killed
[Tue, 11 Dec 2012 13:46:28 GMT] [error] [0.389.0] {error_report,0.31.0,
{0.389.0,crash_report,
[[{initial_call,
{couch_httpc_pool,init,['Argument__1']}},
{pid,0.389.0},
{registered_name,[]},
{error_info,
{exit,killed,
[{gen_server,terminate,6},
{proc_lib,init_p_do_apply,3}]}},
{ancestors,
[0.379.0,couch_rep_sup,
couch_primary_services,couch_server_sup,
0.32.0]},
{messages,[]},
{links,[]},
{dictionary,[]},
{trap_exit,true},
{status,running},
{heap_size,377},
{stack_size,24},
{reductions,496}],
[]]}}
Contact me on my account email for more information or here.
Best regards
Lucas
BASIC auth password appear in log in plaintext during an error
--
Key: COUCHDB-1626
URL: https://issues.apache.org/jira/browse/COUCHDB-1626
Project: CouchDB
[jira] [Updated] (COUCHDB-1169) Bad logging when the javascript view server crashes
[
https://issues.apache.org/jira/browse/COUCHDB-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Kocoloski updated COUCHDB-1169:
Component/s: Logging
Bad logging when the javascript view server crashes
---
Key: COUCHDB-1169
URL: https://issues.apache.org/jira/browse/COUCHDB-1169
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server, Logging
Affects Versions: 1.0.2
Environment: Fedora 15
Reporter: Thomas Vander Stichele
Attachments: view.input
I've been trying to rebuild my 1.0.x branch on Fedora 15. I have applied all
patches from the Fedora RPM, which among other things fixes the update to
libjs.
Now my view server terminates when I query a view:
[debug] [0.127.0] OS Process #Port0.2618 Input ::
[map_doc,{_id:b3d340d7aece621e8bf95f9545033aac,_rev:1-26ef6f671b08ce78d8b338ef70b6035c,updated:2011-05-01T20:29:00Z,end:null,complete:null,statuses:null,title:push
new version of flumotion for
f14,contexts:null,due:2011-05-06T00:00:00Z,recurrence:null,importance:null,references:null,projects:[flumotion],time:null,type:thing,start:2011-05-01T20:29:00Z,urgency:null,description:null}]
[error] [0.125.0] OS Process Error 0.127.0 ::
{os_process_error,{exit_status,139}}
[error] [emulator] Error in process 0.125.0 with exit value:
{{nocatch,{os_process_error,{exit_status,139}}},[{couch_os_process,prompt,2},{couch_query_servers,'-map_docs/2-fun-1-',2},{lists,map,2},{couch_query_servers,map_docs,2},{couch_view_updater,view_compute,2},{couch_view_updater...
This gives no clue whatsoever as to what is failing. After reading the code
and some painful debugging, I was able to reproduce at least some kind of
problem by hand:
[thomas@level 1.0.x]$
/home/thomas/dev/ext/couchdb/branches/1.0.x/bin/couchjs_dev
/home/thomas/dev/ext/couchdb/branches/1.0.x/share/server/main.jsUnable to
destroy invalid CouchHTTP instance.
[map_doc,{_id:b3d340d7aece621e8bf95f9545033aac,_rev:1-26ef6f671b08ce78d8b338ef70b6035c,updated:2011-05-01T20:29:00Z,end:null,complete:null,statuses:null,title:push
new version of flumotion for
f14,contexts:null,due:2011-05-06T00:00:00Z,recurrence:null,importance:null,references:null,projects:[flumotion],time:null,type:thing,start:2011-05-01T20:29:00Z,urgency:null,description:null}]
[error,unnamed_error,(new TypeError(\State.funs is undefined\,
\/home/thomas/dev/ext/couchdb/branches/1.0.x/share/server/main.js\, 1311))]
However, it keeps running. IIRC 139 means that the program got SIGSEGV ?
I'll try and replay all the requests to see if I can reproduce.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-974) Log noise after database deletion
[ https://issues.apache.org/jira/browse/COUCHDB-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Kocoloski updated COUCHDB-974: --- Component/s: Logging Log noise after database deletion - Key: COUCHDB-974 URL: https://issues.apache.org/jira/browse/COUCHDB-974 Project: CouchDB Issue Type: Improvement Components: Database Core, Logging Affects Versions: 1.0.1 Environment: Ubuntu 10.04.1 LTS, Erlang R13B03 Reporter: Stephen Lewis Priority: Minor Attachments: couch_log_noise.txt Our test database is deleted, recreated and repopulated before each of our app's tests runs. Although our test suite runs cleanly, we see noise in CouchDB's logs after some of the deletions - see attached file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1528) Error messages for malformed show functions are unhelpful
[
https://issues.apache.org/jira/browse/COUCHDB-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Kocoloski updated COUCHDB-1528:
Component/s: Logging
Error messages for malformed show functions are unhelpful
-
Key: COUCHDB-1528
URL: https://issues.apache.org/jira/browse/COUCHDB-1528
Project: CouchDB
Issue Type: Bug
Components: Database Core, HTTP Interface, Logging
Affects Versions: 1.2
Environment: Windows XP sp3
Reporter: Osher E
Labels: content-type, http-headers, show-function
h2. send headers on a Show Function causes badarg error
h3. Request
{code}
http://dev.server.com:5984/db/_design/app/_show/env_settings/app1-dev?callback=$r
{code}
h3. Response
{code}
500 Internal Server Error
Cache-Control:must-revalidate
Content-Length:44
Content-Type:text/plain; charset=utf-8
Date:Mon, 27 Aug 2012 13:22:14 GMT
Server:CouchDB/1.2.0 (Erlang OTP/R15B)
{error:unknown_error,reason:badarg}
{code}
h3. Log entries:
{code]
[Mon, 27 Aug 2012 12:58:50 GMT] [error] [0.6956.3] Badarg error in HTTP
request
[Mon, 27 Aug 2012 12:58:50 GMT] [info] [0.6956.3] Stacktrace:
[{erlang,binary_to_list,
[{[{Content-Type,
text/javascript}]}],
[]},
{couch_httpd_external,
'-parse_external_response/1-fun-0-',1,
[{file,
d:/relax/couchdb/src/couchdb/couch_httpd_external.erl},
{line,157}]},
{lists,map,2,
[{file,lists.erl},{line,1173}]},
{lists,map,2,
[{file,lists.erl},{line,1173}]},
{couch_httpd_external,
'-parse_external_response/1-fun-1-',2,
[{file,
d:/relax/couchdb/src/couchdb/couch_httpd_external.erl},
{line,156}]},
{lists,foldl,3,
[{file,lists.erl},{line,1197}]},
{couch_httpd_external,
send_external_response,2,
[{file,
d:/relax/couchdb/src/couchdb/couch_httpd_external.erl},
{line,129}]},
{couch_httpd_db,do_db_req,2,
[{file,
d:/relax/couchdb/src/couchdb/couch_httpd_db.erl},
{line,230}]}]
{code}
h2. more info
h3. The show function
{code}
function(doc, req){
var u
, urls = doc.uses
, out =
[ req.query.callback || callback
, ({app:\, doc.app ||
, \,env:\ , doc.env
, \,ver: , doc._rev.substr(0,doc._rev.indexOf(-))
, ,uses:{
];
for (u in urls)
out.push(u,:\,urls[u],\,,);
out[out.length-1] = }});;
start({headers: {Content-Type: text/javascript}});
out.forEach(send)
}
{code}
Tried also
{code}
out = out.join();
return {
headers:
{ Content-Type : text/javascript
, Content-Length: out.length
}
, body: out
}
{code}
and
{code}
{ Content-Type : text/javascript; charset=utf-8
, Content-Length: out.length
}
{code}
got same result
works only when the entire headers part is commented out.
h3. Sample document:
{code}
{
_id: app1-dev,
_rev: 10-269755da4f2c8ed771d9b301ec7d6163,
env: dev,
app: app1,
uses: {
front: http://dev.server.com/front/;,
auth: http://qas.server.com/auth/;,
back: http://dev.server.com/back/;
}
}
{code}
h3. configuration
produced with WindowsXP, couch 1.2.0, OTP R15.
I first noted the problem accessing through vhost + _rewrite. However, the
problem is reproduced also without.
*vhosts setting*
{code}
opm.dev.couch.com = /db/_design/app/_rewrite
{code}
*rewrite section*
{code}
, rewrites :
[ {from:/of/*, to:'_show/env_settings/*'}
, {from:/* , to:'*'}
]
{code}
h3. expected output (beautified)
{code}
$r(
{ app : app1
, env : dev
, ver : 10
, uses:
{ front: http://dev.server.com/front/;
, auth: http://qas.server.com/auth/;
, back: http://dev.server.com/back/;
}
}
)
{code}
--
This message
[jira] [Commented] (COUCHDB-1626) BASIC auth password appear in log in plaintext during an error
[
https://issues.apache.org/jira/browse/COUCHDB-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669329#comment-13669329
]
Adam Kocoloski commented on COUCHDB-1626:
-
Yeah, this is still an issue. One possible solution is to use
`process_flag(sensitive, true)` in processes where we know we're storing auth
credentials.
BASIC auth password appear in log in plaintext during an error
--
Key: COUCHDB-1626
URL: https://issues.apache.org/jira/browse/COUCHDB-1626
Project: CouchDB
Issue Type: Bug
Components: Build System, Infrastructure, Logging
Reporter: Lucas T
During testing, I see in the log that the password use in BASIC Auth was
hidden by *.
But when i try a replication who tell a ERRConn. The stack trace of error
contain the password in plain-text.
And store in log file.
I doubt it's a debug feature.
I paste my couch log here: I hidden private info my self with A
Tue, 11 Dec 2012 13:46:14 GMT] [info] [0.379.0] Retrying HEAD request to
https://lucas-A-1:*@backup-1.AA.cc/lucas-A-1/ in
16.0 seconds due to error {conn_failed,{error,eoptions}}
[Tue, 11 Dec 2012 13:46:28 GMT] [info] [0.133.0] 10.0.0.23 - - POST
/_replicate 500
[Tue, 11 Dec 2012 13:46:28 GMT] [error] [0.389.0] ** Generic server
0.389.0 terminating
** Last message in was {'EXIT',0.379.0,killed}
** When Server state == {state,https://lucas--1:--HERE MY PASS IN
PLAINTEXT@
backup-1.A.cc/lucas-A-1/,
20,[],[],
{[],[]}}
** Reason for termination ==
** killed
[Tue, 11 Dec 2012 13:46:28 GMT] [error] [0.389.0] {error_report,0.31.0,
{0.389.0,crash_report,
[[{initial_call,
{couch_httpc_pool,init,['Argument__1']}},
{pid,0.389.0},
{registered_name,[]},
{error_info,
{exit,killed,
[{gen_server,terminate,6},
{proc_lib,init_p_do_apply,3}]}},
{ancestors,
[0.379.0,couch_rep_sup,
couch_primary_services,couch_server_sup,
0.32.0]},
{messages,[]},
{links,[]},
{dictionary,[]},
{trap_exit,true},
{status,running},
{heap_size,377},
{stack_size,24},
{reductions,496}],
[]]}}
Contact me on my account email for more information or here.
Best regards
Lucas
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1805) Grouping on reduce views tests for equality rather than ICU equivalence
[ https://issues.apache.org/jira/browse/COUCHDB-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669343#comment-13669343 ] Adam Kocoloski commented on COUCHDB-1805: - [~pjdavis1970] reminds me that we support raw collation on views, so the right fix here needs to carry that config information all the way through to the row grouping. Grouping on reduce views tests for equality rather than ICU equivalence --- Key: COUCHDB-1805 URL: https://issues.apache.org/jira/browse/COUCHDB-1805 Project: CouchDB Issue Type: Bug Reporter: Adam Kocoloski If I emit keys from two documents that are distinct but compare equal from ICU's point of view, a group=true query over the view will show two distinct rows. I think the expected behavior is that the rows are combined when ICU collation says the keys compare equal. I think part of the fix is to modify the group_rows_fun to call out to ICU instead of doing a simple == comparison: https://github.com/apache/couchdb/blob/48dc96/src/couch_mrview/src/couch_mrview.erl#L354-L363 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (COUCHDB-1256) Incremental requests to _changes can skip revisions
[
https://issues.apache.org/jira/browse/COUCHDB-1256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Kocoloski closed COUCHDB-1256.
---
Incremental requests to _changes can skip revisions
---
Key: COUCHDB-1256
URL: https://issues.apache.org/jira/browse/COUCHDB-1256
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 0.10, 0.10.1, 0.10.2, 0.11.1, 0.11.2, 1.0, 1.0.1, 1.0.2,
1.0.3, 1.1
Environment: confirmed on Apache CouchDB 1.1.0, bug appears to be
present in 1.0.3 and trunk
Reporter: Adam Kocoloski
Assignee: Adam Kocoloski
Priority: Blocker
Fix For: 1.1.1, 1.2, 1.2.1
Attachments: jira-1256-test.diff
Requests to _changes with style=all_docssince=N (requests made by the
replicator) are liable to suppress revisions of a document. The following
sequence of curl commands demonstrates the bug:
curl -X PUT localhost:5985/revseq
{ok:true}
curl -X PUT -Hcontent-type:application/json localhost:5985/revseq/foo -d
'{a:123}'
{ok:true,id:foo,rev:1-0dc33db52a43872b6f3371cef7de0277}
curl -X PUT -Hcontent-type:application/json localhost:5985/revseq/bar -d
'{a:456}'
{ok:true,id:bar,rev:1-cc609831f0ca66e8cd3d4c1e0d98108a}
% stick a conflict revision in foo
curl -X PUT -Hcontent-type:application/json
localhost:5985/revseq/foo?new_edits=false -d
'{_rev:1-cc609831f0ca66e8cd3d4c1e0d98108a, a:123}'
{ok:true,id:foo,rev:1-cc609831f0ca66e8cd3d4c1e0d98108a}
% request without since= gives the expected result
curl -Hcontent-type:application/json
localhost:5985/revseq/_changes?style=all_docs
{results:[
{seq:2,id:bar,changes:[{rev:1-cc609831f0ca66e8cd3d4c1e0d98108a}]},
{seq:3,id:foo,changes:[{rev:1-cc609831f0ca66e8cd3d4c1e0d98108a},{rev:1-0dc33db52a43872b6f3371cef7de0277}]}
],
last_seq:3}
% request starting from since=2 suppresses revision
1-0dc33db52a43872b6f3371cef7de0277 of foo
macbook:~ (master) $ curl
localhost:5985/revseq/_changes?style=all_docs\since=2
{results:[
{seq:3,id:foo,changes:[{rev:1-cc609831f0ca66e8cd3d4c1e0d98108a}]}
],
last_seq:3}
I believe the fix is something like this (though we could refactor further
because Style is unused):
diff --git a/src/couchdb/couch_db.erl b/src/couchdb/couch_db.erl
index e8705be..65aeca3 100644
--- a/src/couchdb/couch_db.erl
+++ b/src/couchdb/couch_db.erl
@@ -1029,19 +1029,7 @@ changes_since(Db, Style, StartSeq, Fun, Acc) -
changes_since(Db, Style, StartSeq, Fun, [], Acc).
changes_since(Db, Style, StartSeq, Fun, Options, Acc) -
-Wrapper = fun(DocInfo, _Offset, Acc2) -
-#doc_info{revs=Revs} = DocInfo,
-DocInfo2 =
-case Style of
-main_only -
-DocInfo;
-all_docs -
-% remove revs before the seq
-DocInfo#doc_info{revs=[RevInfo ||
-#rev_info{seq=RevSeq}=RevInfo - Revs, StartSeq
RevSeq]}
-end,
-Fun(DocInfo2, Acc2)
-end,
+Wrapper = fun(DocInfo, _Offset, Acc2) - Fun(DocInfo, Acc2) end,
{ok, _LastReduction, AccOut} = couch_btree:fold(by_seq_btree(Db),
Wrapper, Acc, [{start_key, StartSeq + 1}] ++ Options),
{ok, AccOut}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (COUCHDB-1058) Design doc attachments cannot start with an underscore
[ https://issues.apache.org/jira/browse/COUCHDB-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Kocoloski closed COUCHDB-1058. --- Design doc attachments cannot start with an underscore -- Key: COUCHDB-1058 URL: https://issues.apache.org/jira/browse/COUCHDB-1058 Project: CouchDB Issue Type: Bug Affects Versions: 1.0.2 Reporter: Adam Kocoloski Priority: Minor Fix For: 1.0.3, 1.1 We throw an error if someone tries to request an attachment like that: https://github.com/apache/couchdb/commit/347015 I think the following fix might be preferable: https://github.com/cloudant/chttpd/commit/741a83 It'll send a 404 if the user tries an unknown action, unless there happens to be an attachment with that same name. I suppose we could also just disallow attachment names that start with an underscore, like we do for document IDs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (COUCHDB-1055) Timing-related failures in 172-os-daemon-errors.t
[
https://issues.apache.org/jira/browse/COUCHDB-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Kocoloski closed COUCHDB-1055.
---
Timing-related failures in 172-os-daemon-errors.t
-
Key: COUCHDB-1055
URL: https://issues.apache.org/jira/browse/COUCHDB-1055
Project: CouchDB
Issue Type: Bug
Affects Versions: 1.2
Reporter: Adam Kocoloski
Assignee: Paul Joseph Davis
Priority: Minor
Fix For: 1.2
I see quite a few of these on Hudson. Here's one that happened when the
daemon simply does init:stop(). It seems to happen more often when the
server is executing two jobs at once.
# Daemon dies on boot.
ok 8 - Daemon port is a port.
ok 9 - Daemon name was set correctly.
ok 10 - Command name was set correctly.
ok 11 - Kill command was set.
not ok 12 - Daemon has been halted.
---
description: Daemon has been halted.
found: running
wanted: halted
...
not ok 13 - Errors have been disabled.
---
description: Errors have been disabled.
found: [{1296,674759,844395}]
wanted: nil
...
not ok 14 - Buffer has been switched off.
---
description: Buffer has been switched off.
found: []
wanted: nil
...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (COUCHDB-558) Validate Content-MD5 request headers on uploads
[ https://issues.apache.org/jira/browse/COUCHDB-558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Kocoloski closed COUCHDB-558. -- Validate Content-MD5 request headers on uploads --- Key: COUCHDB-558 URL: https://issues.apache.org/jira/browse/COUCHDB-558 Project: CouchDB Issue Type: Improvement Components: Database Core, HTTP Interface Reporter: Adam Kocoloski Assignee: Paul Joseph Davis Fix For: 0.11 Attachments: jira-couchdb-558-10th-try-trunk.patch, jira-couchdb-558-4th-try.patch, jira-couchdb-558-5th-try.patch, jira-couchdb-558-6th-try-trunk.patch, jira-couchdb-558-7th-try-trunk.patch, jira-couchdb-558-8th-try-trunk.patch, jira-couchdb-558-9th-try-trunk.patch, jira-couchdb-558-for-trunk-2nd-try.patch, jira-couchdb-558-for-trunk-3rd-try.patch, jira-couchdb-558-for-trunk.patch, run.tpl.patch We could detect in-flight data corruption if a client sends a Content-MD5 header along with the data and Couch validates the MD5 on arrival. RFC1864 - The Content-MD5 Header Field http://www.faqs.org/rfcs/rfc1864.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (COUCHDB-559) 0.9.1 pushing to 0.10.0 fails b/c of list_to_existing_atom(disk_format_version).
[ https://issues.apache.org/jira/browse/COUCHDB-559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Kocoloski closed COUCHDB-559. -- 0.9.1 pushing to 0.10.0 fails b/c of list_to_existing_atom(disk_format_version). -- Key: COUCHDB-559 URL: https://issues.apache.org/jira/browse/COUCHDB-559 Project: CouchDB Issue Type: Bug Components: Replication Affects Versions: 0.10 Reporter: Adam Kocoloski Fix For: 0.9.2 The atom disk_format_version doesn't appear in 0.9.1, but in 0.10.0 it's part of the info returned by GET /dbname. If an 0.9.1 server tries to push to 0.10.0, it'll fail trying to decode disk_format_version into an existing atom. Not sure at this point about the best workaround. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (COUCHDB-840) be more relaxed about verifying SSL certificate chains
[ https://issues.apache.org/jira/browse/COUCHDB-840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Kocoloski closed COUCHDB-840. -- be more relaxed about verifying SSL certificate chains -- Key: COUCHDB-840 URL: https://issues.apache.org/jira/browse/COUCHDB-840 Project: CouchDB Issue Type: Improvement Affects Versions: 1.0 Reporter: Adam Kocoloski Fix For: 1.0.1 Attachments: COUCHDB-840.patch The new Erlang SSL implementation (which we use to consume _changes) has a default verification depth of 1. This causes pull replication from an SSL-wrapped server to fail if the server has an intermediate certificate in its chain. Intermediate certificates are pretty common especially at the cheaper end, e.g. GoDaddy certs. OpenSSL uses a default depth of 9; I think we should do the same. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-755) use exported functions when registering for config changes / db updates to allow hot upgrading
[ https://issues.apache.org/jira/browse/COUCHDB-755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669361#comment-13669361 ] Adam Kocoloski commented on COUCHDB-755: The following two OTP applications replace couch_config and couch_db_update and only allow exported functions as callbacks: https://github.com/cloudant/config https://github.com/cloudant/couch_event use exported functions when registering for config changes / db updates to allow hot upgrading -- Key: COUCHDB-755 URL: https://issues.apache.org/jira/browse/COUCHDB-755 Project: CouchDB Issue Type: Improvement Components: Database Core Affects Versions: 0.11 Reporter: Adam Kocoloski This is a common idiom in our current codebase: couch_config:register(fun(couchdb, os_process_timeout, NewTimeout) - couch_os_process:set_timeout(Pid, list_to_integer(NewTimeout)) end), It proves problematic for hot code upgrades. The issue is that the anonymous fun is held by the couch_config process but belongs to the module in which it is defined (here, couch_external_server.erl). If an expert user loads a new version of couch_external_server, the anonymous fun will belong to the 'old' version of the module. If she upgrades the module again, couch_config will be killed. That's no good. The solution is to export the function that handles the configuration change or db update event. For instance -export(config_change/3). ... couch_config:register(fun ?MODULE:config_change/3), ... config_change(couchdb, os_process_timeout, NewTimeout) - couch_os_process:set_timeout(Pid, list_to_integer(NewTimeout)). I have a patch for this that we've been using for some time in Cloudant, just need to clean it up and apply it to trunk. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (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
]
Adam Kocoloski reassigned COUCHDB-523:
--
Assignee: Adam Kocoloski (was: Joan Touzet)
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: Adam Kocoloski
Priority: Minor
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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-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:comment-tabpanelfocusedCommentId=13669369#comment-13669369
]
Adam Kocoloski commented on COUCHDB-523:
Will rebase my old patch on master and post it for review now.
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: Adam Kocoloski
Priority: Minor
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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1751) Provide internal and user-facing statistics
[ https://issues.apache.org/jira/browse/COUCHDB-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Kocoloski updated COUCHDB-1751: Skill Level: New Contributors Level (Easy) Provide internal and user-facing statistics --- Key: COUCHDB-1751 URL: https://issues.apache.org/jira/browse/COUCHDB-1751 Project: CouchDB Issue Type: Improvement Reporter: Dave Cottlehuber Labels: couchdb, erlang, gsoc2013, html, javascript, nodejs, rest Support pluggable statistics approaches, both for internal (VM couch metrics), and external/user-facing ones (query types, user access patterns). Measure All the Things. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1751) Provide internal and user-facing statistics
[ https://issues.apache.org/jira/browse/COUCHDB-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669380#comment-13669380 ] Adam Kocoloski commented on COUCHDB-1751: - I think it's worth evaluating Folsom as the metrics collection and exporting engine: https://github.com/boundary/folsom Provide internal and user-facing statistics --- Key: COUCHDB-1751 URL: https://issues.apache.org/jira/browse/COUCHDB-1751 Project: CouchDB Issue Type: Improvement Reporter: Dave Cottlehuber Labels: couchdb, erlang, gsoc2013, html, javascript, nodejs, rest Support pluggable statistics approaches, both for internal (VM couch metrics), and external/user-facing ones (query types, user access patterns). Measure All the Things. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (COUCHDB-721) possible data corruption after upgrade compaction
[
https://issues.apache.org/jira/browse/COUCHDB-721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Kocoloski reassigned COUCHDB-721:
--
Assignee: Dirkjan Ochtman
Do you happen to remember if there was any resolution here?
possible data corruption after upgrade compaction
---
Key: COUCHDB-721
URL: https://issues.apache.org/jira/browse/COUCHDB-721
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 0.11
Reporter: Timothy Smith
Assignee: Dirkjan Ochtman
Problem report filed on behalf of dev@couchdb.apache.org e-mail, subject
Compaction issue after upgrade 0.10.1-0.11.0.
So this morning I went to upgrade one of my servers to 0.11. Installed
it, fixed up the config files, then restarted CouchDB. It picked up on
my databases just fine, so everything looked good. I tried some views,
and it had to re-index all of my ddocs (which I found surprising, but
okay). After that I went and compacted the database, then the views.
However, later today I got some exception mails from my web
application. It appears that something has gotten confused. For
example, take this document:
{_id: page-22, _rev: 2-1835830930, lb: null, content: blah blah
yadda, type: page, _deleted_conflicts: [4-4212453249,
2-1982019940, 2-1964049796, 2-1096626370]}
Note all the _deleted_conflicts. However, this is the document
returned by a view (which emits(doc.lb, doc))! When I actually request
this document, I get this:
{_id:page-22,_rev:4-4212453249} (it would be helpful to have a
member _deleted:true, or something, to show that it's not just empty,
but that something was there before).
Requesting the 2-1835830930 revision results in the complete document,
as shown above.
So, that got me pretty scared, because I thought I lost my document
(and my site actually started failing)! What would be the best way to
fix up my database? And do we have any diagnosis on what the cause of
this is? I'm happy I deployed this on a less-critical site first, and
wouldn't want to deploy at work unless we figure out what's going on
here.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (COUCHDB-53) Incorporating JSearch to CouchDB
[
https://issues.apache.org/jira/browse/COUCHDB-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Kocoloski closed COUCHDB-53.
-
Incorporating JSearch to CouchDB
Key: COUCHDB-53
URL: https://issues.apache.org/jira/browse/COUCHDB-53
Project: CouchDB
Issue Type: New Feature
Components: Full-Text Search
Environment: JSearch is developed in Java
Reporter: Jun Rao
Assignee: Paul Joseph Davis
Priority: Minor
Attachments: jsearch_full.tgz
JSearch is a prototype that we developed for indexing and searching Json
documents, and we are enthusiastic about contributing it to CouchDB. JSearch
converts a given Json document to a Lucene document for indexing. The
conversion is lossless and preserves all structural information in the
original Json document. We achieve that by storing the encoding of Json
structures in the payload of the posting list in a Lucene index. JSearch has
a simple query language that combines fulltext search and structural
querying. To qualify as a match, a document has to match both the JSON
structures as well as the Boolean constraints specified in the query. Suppose
that we have indexed the following two JSON documents:
d1={ A: [ { B: b1, C: c1 },
{ B: b2, C: c2 },
]
}
d2={ A: [ { B: b1, C: c2 },
{ B: b2, C: c1 },
]
}
One can issue the following two JSeach queries.
P={ A: [ { B: b1 C: c1 } ] }
Q={ A: [ { B: b1} {C: c1 } ] }
Query P ( specifies conjunction) matches d1, but not d2. The reason is
that d2 doesn't have the proper B and C fields within the same JSON object.
On the other hand, query Q matches both d1 and d2, since it doesn't require
the B field and the C field to be in the same JSON object.
Here is a summary of the querying features in JSearch
1. arbitrary conjunctive and disjunctive constraints
2. text search on atomic values of string type
3. range constraints on atomic values (only those of string and long types
are currently supported)
4. document level matching
The easiest way to know more about JSeach is to give it a try. Download the
attached tgz file. Follow the readme file in it and try some of the examples.
The attachment also includes all Java source code (I can provide more
technical details if needed). I am very interested in your feedback. Does
JSearch fit into CouchDB? What other features are needed? How should JSearch
be integrated (from Jan's mail, it seems that some infrastructure is already
in-place)? Thanks,
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-527) Add a check to see that the driver directory exists
[ https://issues.apache.org/jira/browse/COUCHDB-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Kocoloski updated COUCHDB-527: --- Priority: Minor (was: Major) Issue Type: Improvement (was: Bug) Summary: Add a check to see that the driver directory exists (was: add a check to see that the driver directory exists) Not a Bug. Add a check to see that the driver directory exists --- Key: COUCHDB-527 URL: https://issues.apache.org/jira/browse/COUCHDB-527 Project: CouchDB Issue Type: Improvement Components: Database Core Reporter: Glenn Rempe Assignee: Paul Joseph Davis Priority: Minor Adding ticket as reminder per Paul Davis. Should be assigned to him. add a check to see that the driver directory exists 'Eh, $PREFIX/lib/couchdb-$(VERSION/priv/lib' and mention in couch_server_sup.erl just before couch_util:start_driver() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-886) Add option to set query options, defined in rewrites.json, as default
[
https://issues.apache.org/jira/browse/COUCHDB-886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Kocoloski updated COUCHDB-886:
---
Issue Type: Improvement (was: Bug)
Not a Bug.
Add option to set query options, defined in rewrites.json, as default
-
Key: COUCHDB-886
URL: https://issues.apache.org/jira/browse/COUCHDB-886
Project: CouchDB
Issue Type: Improvement
Components: Database Core
Reporter: Henrik Skupin
Assignee: Benoit Chesneau
With the latest version of CouchDB the URL parameters are not taken into
account when the rewrites.json file specifies the same ones for the
appropriate entry. See the following example:
{
from : /general/reports,
to : _list/general_reports/general_reportsByDate,
query : {
descending : true,
limit : 51
}
}
default values: http://mozmill.hskupin.info/general/reports
custom values: http://mozmill.hskupin.info/general/reports?limit=10
Whether which URL you are loading, the values from rewrites.json are always
used. Once the limit entry gets removed from that file, the URL parameter is
used and 10 rows are displayed.
As proposed by Benoit query entries should be explicitly allowed to have a
default value. Otherwise the value from rewrites.json has the priority.
query: {
key: { value: :var, default: 1}
}
Can true be used instead of a number? It could be confusing this way,
especially when the value is also a number.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-982) [PATCH] couchdb won't work with debug version of spidermonkey
[
https://issues.apache.org/jira/browse/COUCHDB-982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Kocoloski updated COUCHDB-982:
---
Component/s: (was: Database Core)
JavaScript View Server
[PATCH] couchdb won't work with debug version of spidermonkey
-
Key: COUCHDB-982
URL: https://issues.apache.org/jira/browse/COUCHDB-982
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 1.0.1
Reporter: Petr Běhan
Priority: Minor
Steps to reproduce:
1) configure spidermonkey with --enable-debug --enable-threadsafe and compile
it
2) make couchdb use it (in my case install it as system-wide library, or
through LD_LIBRARY_PATH)
3) restart couchdb server
4) attempt to query any view via http
Observed behaviour:
View query returns nothing, server pegs all CPUs, top shows nothing (spawned
children die too fast to register on top) and /var/log/couchdb/couch.log
starts filling with lines similar to [Wed, 08 Dec 2010 21:59:37 GMT] [error]
[0.205.0] OS Process Error 0.1056.0 ::
{os_process_error,{exit_status,134}} at rate of about 70 errors per second
(which itself is a separate bug in my opinion, it should attempt to call the
child once, and if it fails, stop further attempts and notify client of
http/500 error)
Problem is in incorrect use of JS_DestroyContext call. JSAPI documentation
says that the context being destroyed may or may not be inside active
request. But it doesn't explicitly mention that the calling thread MUST be
set as current for the context. In src/couchdb/priv/couch_js/main.c, the
macro FINISH_REQUEST incorrectly calls JS_ClearContextThread, which is
intended to TRANSFER the context to another thread instead. The
JS_DestroyContext call then triggers spidermonkey assert.
Since JS_NewContext automatically associates the new context with the
calling thread., I think the thread stuff should be completely dropped from
both SETUP_REQUEST and FINISH_REQUEST macros and let spidermonkey take care
of itself (unless there are plans to add threads to couch_js in future).
Following simple patch fixes couchdb on my system:
--- src/couchdb/priv/couch_js/main.c.orig 2010-12-09 00:40:40.0
+0100
+++ src/couchdb/priv/couch_js/main.c2010-12-09 01:03:34.0 +0100
@@ -23,11 +23,9 @@
#ifdef JS_THREADSAFE
#define SETUP_REQUEST(cx) \
-JS_SetContextThread(cx); \
JS_BeginRequest(cx);
#define FINISH_REQUEST(cx) \
-JS_EndRequest(cx); \
-JS_ClearContextThread(cx);
+JS_EndRequest(cx);
#else
#define SETUP_REQUEST(cx)
#define FINISH_REQUEST(cx)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-808) Zero byte .compact file prevents compaction
[
https://issues.apache.org/jira/browse/COUCHDB-808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Kocoloski resolved COUCHDB-808.
Resolution: Fixed
Assignee: Adam Kocoloski
This was fixed in the course of working on COUCHDB-968:
https://github.com/apache/couchdb/commit/4137a8eb9b2b
I'd like to select 1.2.0 as the fix version but JIRA won't let me. Github says
that's the first tag including the above commit.
Zero byte .compact file prevents compaction
---
Key: COUCHDB-808
URL: https://issues.apache.org/jira/browse/COUCHDB-808
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 0.11
Reporter: Robert Newson
Assignee: Adam Kocoloski
Couchdb can make a .compact file when the volume is almost out of disk
space and then crash before writing the header.
If you then clean some space and try to compact again, it won't ever work.
[Wed, 23 Jun 2010 16:11:59 GMT] [error] [emulator] Error in process
0.1976.0 with exit value:
{{badmatch,no_valid_header},[{couch_db_updater,start_copy_compact,1}]}
The presence of the invalid .compact file prevents it, and needs to be
manually removed.
Remedy: delete the .compact file if there is no valid header when _compact is
called for the second time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1446) Config settings input validation
[ https://issues.apache.org/jira/browse/COUCHDB-1446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Kocoloski updated COUCHDB-1446: Issue Type: Improvement (was: Bug) Config settings input validation Key: COUCHDB-1446 URL: https://issues.apache.org/jira/browse/COUCHDB-1446 Project: CouchDB Issue Type: Improvement Components: Database Core Affects Versions: 1.2 Reporter: Jason Smith Assignee: Jason Smith Priority: Minor Labels: config Today I received a bug report from a user who thought CouchDB might be relaxing and evaluate an arithmetic expression in the config. (That makes sense, since it seems to evaluate erlang terms elsewhere.) https://getsatisfaction.com/iriscouch/topics/my_couchdb_is_broken_after_putting_a_badarg_for_a_configuration_value It would be nice for CouchDB to validate config input, particularly when bad values permanently take it offline. (In this case, it returns 500 for all subsequent requests.) IMO, a good bang-for-buck is to have three basic value types: 1. String 2. Erlang tuple 3. Integer And each setting knows what type it must be. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1797) Query against a view w/ include_docs=true yields doc:null
[
https://issues.apache.org/jira/browse/COUCHDB-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Kocoloski updated COUCHDB-1797:
Summary: Query against a view w/ include_docs=true yields doc:null (was:
Query against a view creates a questionable result)
Query against a view w/ include_docs=true yields doc:null
-
Key: COUCHDB-1797
URL: https://issues.apache.org/jira/browse/COUCHDB-1797
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 1.3
Reporter: Marten Feldtmann
Priority: Critical
I have a test system (CouchDB 1.3.0 under windows 7/64 Bit), where I insert
lots of documents(10) to get a regular flow of new incoming documents.
The database has also some views (25). Another task is reading documents from
a view, change some attributes and then the document should disappear from
the view (and appear in another view). Something like a state machine.
I do the following query against a view:
http://localhost:5984/test5/_design/ticketorggraphics/_view/waiting?limit=5include_docs=trueinclude_end=true
and get the following string:
{total_rows:9224,offset:0,rows:[
{id:92224c2862ef49c15f3d51e3e7283cde,key:ni13_1_2013101_20130518155518065,value:ni13_2013101_VsPercentResult_83519204509647,doc:{_id:92224c2862ef49c15f3d51e3e7283cde,_rev:1-6e8b57744c2b88f3d2dcad602e2e3353,distribution:global,type:ESTicketCreateOriginalGraphic,createdTS:20130518155518065,priority:1,eDayID:ni13,electionID:2013101,layout:ard2013,baseDocKey:ni13_2013101_VsPercentResult_83519204509647,_attachments:{bclitemsdata:{content_type:application/zip,revpos:1,digest:md5-sdff2jkxp4w6xsSlx5Yzxw==,length:4533,stub:true,
{id:92224c2862ef49c15f3d51e3e7285d38,key:ni13_1_2013101_20130518155518135,value:ni13_2013101_VsPercentResult_16771681663808,doc:{_id:92224c2862ef49c15f3d51e3e7285d38,_rev:1-05b92282ec5f2d1b6d56912760792702,distribution:global,type:ESTicketCreateOriginalGraphic,createdTS:20130518155518135,priority:1,eDayID:ni13,electionID:2013101,layout:ard2013,baseDocKey:ni13_2013101_VsPercentResult_16771681663808,_attachments:{bclitemsdata:{content_type:application/zip,revpos:1,digest:md5-sdff2jkxp4w6xsSlx5Yzxw==,length:4533,stub:true,
{id:92224c2862ef49c15f3d51e3e728c5e2,key:ni13_1_2013101_20130518155518413,value:ni13_2013101_VsPercentResult_10619936276742,doc:null},
{id:b02d128d88188d78ef7f3478586c349b,key:ni13_2_2013101_20130518155203924,value:ni13_2013101_VsPercentResult_46202583943140,doc:{_id:b02d128d88188d78ef7f3478586c349b,_rev:1-bd2a2bfb1f7461e6b3ec6d4d106e08e4,distribution:global,type:ESTicketCreateOriginalGraphic,createdTS:20130518155203924,priority:2,eDayID:ni13,electionID:2013101,layout:ard2013,baseDocKey:ni13_2013101_VsPercentResult_46202583943140,_attachments:{bclitemsdata:{content_type:application/zip,revpos:1,digest:md5-ErSTxuEaSHZrIJ276ANdOQ==,length:4533,stub:true,
{id:b02d128d88188d78ef7f3478586c72a1,key:ni13_2_2013101_20130518155204124,value:ni13_2013101_VsPercentResult_91455901404013,doc:{_id:b02d128d88188d78ef7f3478586c72a1,_rev:1-6f702cff1d12f992d745fc19be84b846,distribution:global,type:ESTicketCreateOriginalGraphic,createdTS:20130518155204124,priority:2,eDayID:ni13,electionID:2013101,layout:ard2013,baseDocKey:ni13_2013101_VsPercentResult_91455901404013,_attachments:{bclitemsdata:{content_type:application/zip,revpos:1,digest:md5-L9UXpNNRUyk/LSlzAyEsXQ==,length:4533,stub:true
]}
Please notice, that the doc attribute of the third item in the rows attribute
has the value null. That means, that the view entry has no belonging
document
This seems to indicate an inconsistency within the database.
I can not say, when this error happens, but I know, that it will happen in my
test run.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-1316) Error in the validate_doc_update function of the _users db
[
https://issues.apache.org/jira/browse/COUCHDB-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Kocoloski resolved COUCHDB-1316.
-
Resolution: Fixed
In COUCHDB-1511 we ended up requiring a doc.roles field in the validation
function.
Error in the validate_doc_update function of the _users db
--
Key: COUCHDB-1316
URL: https://issues.apache.org/jira/browse/COUCHDB-1316
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 1.1
Reporter: Daniel Truemper
Assignee: Filipe Manana
Priority: Trivial
Hi!
In the validate_doc_update method of the _users database is a small error. On
the one hand it seems that the `roles` attribute of the user doc is not
required:
if (newDoc.roles !isArray(newDoc.roles)) {
throw({forbidden: 'doc.roles must be an array'});
}
On the other hand the function iterates over the roles:
// no system roles in users db
for (var i = 0; i newDoc.roles.length; i++) {
if (newDoc.roles[i][0] === '_') {
throw({
forbidden:
'No system roles (starting with underscore) in users db.'
});
}
}
So, is the roles field required? If so, then throwing a real error would be
nice since I only get a stack trace from CouchDB. If it is not required,
checking it's presence before iterating over it would be necessary.
I am kind of lost in all the new Git handling and such. Would it be
appropriate to open a Github Pull Request? Or should I add a patch to this
issue? Depending on the answer to the roles question I could provide a patch
since it is trivial enough for me I guess :)
Cheers,
Daniel
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1489) Drop useless view indexing jobs
[ https://issues.apache.org/jira/browse/COUCHDB-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Kocoloski updated COUCHDB-1489: Issue Type: Improvement (was: Bug) Agreed that this makes sense as an Improvement. Drop useless view indexing jobs --- Key: COUCHDB-1489 URL: https://issues.apache.org/jira/browse/COUCHDB-1489 Project: CouchDB Issue Type: Improvement Components: Database Core, HTTP Interface Reporter: Jordi Boggiano Priority: Minor On a large database, if you change the view code and query it to check, it starts reindexing (which can take a long time), if you do another change and check again, you end up with two indexing jobs in process. Now this would make sense if the first client is still sitting there waiting for a response, but if it's not the job should be canceled automatically IMO. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-723) ?attachments=true fails when using a _show
[ https://issues.apache.org/jira/browse/COUCHDB-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669749#comment-13669749 ] Adam Kocoloski commented on COUCHDB-723: Yeah, the _show handler hardcodes `[conflicts]` as the option list when opening the document. I don't see any reason why it should be so restrictive. ?attachments=true fails when using a _show -- Key: COUCHDB-723 URL: https://issues.apache.org/jira/browse/COUCHDB-723 Project: CouchDB Issue Type: Bug Components: Database Core Affects Versions: 0.11 Environment: 0.11 built from SVN on Ubuntu 9.10 Reporter: Cliff Stanford Priority: Minor Labels: _show, attachments If a document has an attachment and is displayed as: http://couch.may.be:5984/jira/testdoc?attachments=true then the base64 of the attachment is returned. http://couch.may.be:5984/jira/_design/test/_show/debug/testdoc?attachments=true the stub : true is shown. The above URLs are live and demonstrate the problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-537) reduce string
[ https://issues.apache.org/jira/browse/COUCHDB-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669754#comment-13669754 ] Adam Kocoloski commented on COUCHDB-537: Current status is that master ignores trailing characters (whitespace or otherwise) when looking for builtins. It still doesn't do anything polite when a user sets reduce: _randomthing. reduce string - Key: COUCHDB-537 URL: https://issues.apache.org/jira/browse/COUCHDB-537 Project: CouchDB Issue Type: Bug Components: Database Core Affects Versions: 0.10 Environment: ubuntu from source 0.10 Reporter: greg tappero Priority: Trivial Attachments: 0001-Incorrect-builtin-function-names-now-throw-an-error-.patch, 0001-Incorrect-builtin-function-names-now-throw-an-error-.patch For a simple reduce as _sum if i add a space after _sum it crashes. Don't know how likely it is to add a space by mistake maybe the input could be trimed ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1769) Duplicates in View indexes
[
https://issues.apache.org/jira/browse/COUCHDB-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13668349#comment-13668349
]
Adam Kocoloski commented on COUCHDB-1769:
-
[~stefankoegl] when you see one of these crashes can you check if _all_docs
and/or _changes has multiple entries for the docid in question?
Duplicates in View indexes
--
Key: COUCHDB-1769
URL: https://issues.apache.org/jira/browse/COUCHDB-1769
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 1.3
Reporter: Stefan Kögl
Attachments: duplicate.log
The compaction of a view (created with CouchDB 1.3) failed due to
view_duplicate_id. The database to which the view belongs was created with
1.2.x but compacted (with the 0-byte-compact-file trick) with 1.3.
A full log of the failed compaction can be found at
https://friendpaste.com/1AL050bzwyLCa9KJUKJw1u
I experienced the same behaviour already with previous versions but assumed
it might be gone with 1.3, but this seems not to be the case.
When such duplicates happen (and appear during compaction), they seem to be
at the beginning of the view index. The view in question has the following
_info:
{noformat}
{name:listeners,view_index:{signature:854a8065b438b3e53fcdbbe0a79a8e80,language:javascript,disk_size:2679632207,data_size:1026614011,update_seq:58353111,purge_seq:0,updater_running:false,compact_running:false,waiting_commit:false,waiting_clients:0}}
{noformat}
Compaction stopped with a 39M large .compact.view file.
Also the problem seems to happen only one some machines.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1769) Duplicates in View indexes
[
https://issues.apache.org/jira/browse/COUCHDB-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13668578#comment-13668578
]
Adam Kocoloski commented on COUCHDB-1769:
-
Thanks! The lack of emits is not necessarily significant; the dupes are
detected one level up, as it were, and we record information about each doc at
that level regardless of the number of emits.
On the other hand the results from _all_docs and _changes are interesting. In
the past I'm fairly certain that we'd *always* observe dupes in at least one of
those indexes.
Duplicates in View indexes
--
Key: COUCHDB-1769
URL: https://issues.apache.org/jira/browse/COUCHDB-1769
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 1.3
Reporter: Stefan Kögl
Attachments: duplicate.log
The compaction of a view (created with CouchDB 1.3) failed due to
view_duplicate_id. The database to which the view belongs was created with
1.2.x but compacted (with the 0-byte-compact-file trick) with 1.3.
A full log of the failed compaction can be found at
https://friendpaste.com/1AL050bzwyLCa9KJUKJw1u
I experienced the same behaviour already with previous versions but assumed
it might be gone with 1.3, but this seems not to be the case.
When such duplicates happen (and appear during compaction), they seem to be
at the beginning of the view index. The view in question has the following
_info:
{noformat}
{name:listeners,view_index:{signature:854a8065b438b3e53fcdbbe0a79a8e80,language:javascript,disk_size:2679632207,data_size:1026614011,update_seq:58353111,purge_seq:0,updater_running:false,compact_running:false,waiting_commit:false,waiting_clients:0}}
{noformat}
Compaction stopped with a 39M large .compact.view file.
Also the problem seems to happen only one some machines.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1769) Duplicates in View indexes
[
https://issues.apache.org/jira/browse/COUCHDB-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13668610#comment-13668610
]
Adam Kocoloski commented on COUCHDB-1769:
-
Hmm, that's what I get for doing this from memory ... it seems like we do
optimize away the entries to the btree in the case where a doc doesn't emit
anything.
The other weird bit is that I thought we had fixed up couch_btree to disallow
duplicate keys altogether by now. Need to dig in on this a bit more.
Duplicates in View indexes
--
Key: COUCHDB-1769
URL: https://issues.apache.org/jira/browse/COUCHDB-1769
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 1.3
Reporter: Stefan Kögl
Attachments: duplicate.log
The compaction of a view (created with CouchDB 1.3) failed due to
view_duplicate_id. The database to which the view belongs was created with
1.2.x but compacted (with the 0-byte-compact-file trick) with 1.3.
A full log of the failed compaction can be found at
https://friendpaste.com/1AL050bzwyLCa9KJUKJw1u
I experienced the same behaviour already with previous versions but assumed
it might be gone with 1.3, but this seems not to be the case.
When such duplicates happen (and appear during compaction), they seem to be
at the beginning of the view index. The view in question has the following
_info:
{noformat}
{name:listeners,view_index:{signature:854a8065b438b3e53fcdbbe0a79a8e80,language:javascript,disk_size:2679632207,data_size:1026614011,update_seq:58353111,purge_seq:0,updater_running:false,compact_running:false,waiting_commit:false,waiting_clients:0}}
{noformat}
Compaction stopped with a 39M large .compact.view file.
Also the problem seems to happen only one some machines.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1805) Grouping on reduce views tests for equality rather than ICU equivalence
Adam Kocoloski created COUCHDB-1805: --- Summary: Grouping on reduce views tests for equality rather than ICU equivalence Key: COUCHDB-1805 URL: https://issues.apache.org/jira/browse/COUCHDB-1805 Project: CouchDB Issue Type: Bug Reporter: Adam Kocoloski If I emit keys from two documents that are distinct but compare equal from ICU's point of view, a group=true query over the view will show two distinct rows. I think the expected behavior is that the rows are combined when ICU collation says the keys compare equal. I think part of the fix is to modify the group_rows_fun to call out to ICU instead of doing a simple == comparison: https://github.com/apache/couchdb/blob/48dc96/src/couch_mrview/src/couch_mrview.erl#L354-L363 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-1799) Session cookie not updated when calling rewrites
[ https://issues.apache.org/jira/browse/COUCHDB-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Kocoloski resolved COUCHDB-1799. - Resolution: Fixed Assignee: Adam Kocoloski Merged, thanks! Session cookie not updated when calling rewrites Key: COUCHDB-1799 URL: https://issues.apache.org/jira/browse/COUCHDB-1799 Project: CouchDB Issue Type: Bug Components: HTTP Interface Affects Versions: 1.3 Reporter: Martin Higham Assignee: Adam Kocoloski Normally a new AuthSession cookie is issued when 10% of the cookie life time is exceed. This does not happen when making a call via a _rewrite rule -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1800) [admins] not rewritten to correct file with -A configuration directory
[ https://issues.apache.org/jira/browse/COUCHDB-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Kocoloski updated COUCHDB-1800: Skill Level: Committers Level (Medium to Hard) Good report, thanks. It's reasonably difficult to fix this one in the current couch_config_writer framework. [admins] not rewritten to correct file with -A configuration directory -- Key: COUCHDB-1800 URL: https://issues.apache.org/jira/browse/COUCHDB-1800 Project: CouchDB Issue Type: Bug Components: Database Core Reporter: James Dingwall I am starting couch 1.3.0 with: -a default.ini -a local.ini -A local.d If my local.d contains two files such that one contains [admins] admin = somepassword and a second [couchdb] database_dir = /some/path view_index_dir = /another/path When the [admins] section is rewritten with the crypted password it does not end up in the file where the original [admins] section was defined therefore leaving the plaintext password still available. i.e. the resulting files are: [admins] admin = somepassword and [couchdb] directory_dir = /some/path view_index_dir = /another/path [admins] admin = crypted password -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1777) 409 response vs persitent connection
[ https://issues.apache.org/jira/browse/COUCHDB-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13642904#comment-13642904 ] Adam Kocoloski commented on COUCHDB-1777: - Cool. That's a different (and significantly more complex) code path. The most likely scenario is that CouchDB/mochiweb believes it has not received all bytes on the connection at the time it issues the 409 Conflict response, in which case it will definitely close the connection. I agree that adding a Connection: close response header in that case is a polite thing to do. 409 response vs persitent connection Key: COUCHDB-1777 URL: https://issues.apache.org/jira/browse/COUCHDB-1777 Project: CouchDB Issue Type: Bug Components: Database Core Reporter: Marek Kowalski CouchDB closes the persistent client connection after responding with 409 code. This behavior is not necessarily against the RFC 2616, although it makes it more complicated to use pipelining. If its really necessary to close the connection, it would be nice to at least put the Connection: close in the response headers. If the connection can be closed without informing client that this is going to happen, the client might start writing the new request to the connection. Again, according RFC 2616, this situation should be handled by the client, although the header could be added as a courtesy. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1777) 409 response vs persitent connection
[ https://issues.apache.org/jira/browse/COUCHDB-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13642511#comment-13642511 ] Adam Kocoloski commented on COUCHDB-1777: - Interesting. I can't think of any good reason why CouchDB would force the connection to close. CouchDB relies directly on mochiweb for connection management and its rules for determining whether to keep the connection are fairly straightforward. Marek, is this a PUT request with a plain JSON body or something more exotic like a multipart upload? 409 response vs persitent connection Key: COUCHDB-1777 URL: https://issues.apache.org/jira/browse/COUCHDB-1777 Project: CouchDB Issue Type: Bug Components: Database Core Reporter: Marek Kowalski CouchDB closes the persistent client connection after responding with 409 code. This behavior is not necessarily against the RFC 2616, although it makes it more complicated to use pipelining. If its really necessary to close the connection, it would be nice to at least put the Connection: close in the response headers. If the connection can be closed without informing client that this is going to happen, the client might start writing the new request to the connection. Again, according RFC 2616, this situation should be handled by the client, although the header could be added as a courtesy. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1643) Switch to V8
[ https://issues.apache.org/jira/browse/COUCHDB-1643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13552000#comment-13552000 ] Adam Kocoloski commented on COUCHDB-1643: - Does anyone know how V8 handles the anonymous function issue? Switch to V8 Key: COUCHDB-1643 URL: https://issues.apache.org/jira/browse/COUCHDB-1643 Project: CouchDB Issue Type: Improvement Components: JavaScript View Server Reporter: Jan Lehnardt I’d like to propose that we switch to the V8 JavaScript engine to mitigate the various issues we have with SpiderMonkey. This ticket acts as the meta-issue where we can discuss whether we all agree and what needs doing. individual tasks then can get their own tickets. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1643) Switch to V8
[ https://issues.apache.org/jira/browse/COUCHDB-1643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13552005#comment-13552005 ] Adam Kocoloski commented on COUCHDB-1643: - Ah, sorry, I'm referring to COUCHDB-1397 Switch to V8 Key: COUCHDB-1643 URL: https://issues.apache.org/jira/browse/COUCHDB-1643 Project: CouchDB Issue Type: Improvement Components: JavaScript View Server Reporter: Jan Lehnardt I’d like to propose that we switch to the V8 JavaScript engine to mitigate the various issues we have with SpiderMonkey. This ticket acts as the meta-issue where we can discuss whether we all agree and what needs doing. individual tasks then can get their own tickets. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1346) CouchDB hangs during start of view indexing
[
https://issues.apache.org/jira/browse/COUCHDB-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13510055#comment-13510055
]
Adam Kocoloski commented on COUCHDB-1346:
-
[~janl] I was running it from Chrome installed locally on the Windows EC2
instance.
CouchDB hangs during start of view indexing
---
Key: COUCHDB-1346
URL: https://issues.apache.org/jira/browse/COUCHDB-1346
Project: CouchDB
Issue Type: Bug
Components: View Server Support
Affects Versions: 1.3
Environment: Windows 7 Enterprise only, not able to replicate on Mac
OS X.
Erlang R14B03 + crypto patches.
Mozilla Javascript 1.8.5
Reporter: Dave Cottlehuber
Assignee: Adam Kocoloski
Priority: Blocker
Labels: Windows
Fix For: 1.3
[info] [0.20499.0] Opening index for db: test_suite_db idx:
f4421bf4e9c9bf2acb3db91bca9e9adc sig: d5c87ad33242b181f86be2139cbccd96
[info] [0.20504.0] Starting index update for db: test_suite_db idx:
f4421bf4e9c9bf2acb3db91bca9e9adc
[info] [0.20334.0] 172.16.40.1 - - POST /test_suite_db/_temp_view 500
[info] [0.20513.0] 172.16.40.1 - - GET
/_utils/couch_tests.html?script/couch_tests.js 200
[info] [0.20514.0] 172.16.40.1 - - GET /_utils/index.html 200
[info] [0.20060.0] 172.16.40.1 - - DELETE /test_suite_db_a/ 200
[info] [0.20407.0] 172.16.40.1 - - GET /test_suite_reports/ 404
[info] [0.20058.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20071.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20069.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20484.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20364.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20062.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20388.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20345.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20072.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20059.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20061.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20472.0] 172.16.40.1 - - DELETE /test_suite_db/ 200
[error] [0.20050.0] ** Generic server couch_index_server terminating
** Last message in was {'$gen_cast',{reset_indexes,test_suite_db}}
** When Server state == {st,../var/lib/couchdb}
** Reason for termination ==
** {{case_clause,{error,eacces}},
[{couch_file,'-nuke_dir/2-fun-0-',3},
{lists,foreach,2},
{couch_file,nuke_dir,2},
{couch_index_server,handle_cast,2},
{gen_server,handle_msg,5},
{proc_lib,init_p_do_apply,3}]}
=ERROR REPORT 23-Nov-2011::21:17:14 ===
** Generic server couch_index_server terminating
** Last message in was {'$gen_cast',{reset_indexes,test_suite_db}}
** When Server state == {st,../var/lib/couchdb}
** Reason for termination ==
** {{case_clause,{error,eacces}},
[{couch_file,'-nuke_dir/2-fun-0-',3},
{lists,foreach,2},
{couch_file,nuke_dir,2},
{couch_index_server,handle_cast,2},
{gen_server,handle_msg,5},
{proc_lib,init_p_do_apply,3}]}
[error] [0.20050.0] {error_report,0.19957.0,
{0.20050.0,crash_report,
[[{initial_call,
{couch_index_server,init,['Argument__1']}},
{pid,0.20050.0},
{registered_name,couch_index_server},
{error_info,
{exit,
{{case_clause,{error,eacces}},
[{couch_file,'-nuke_dir/2-fun-0-',3},
{lists,foreach,2},
{couch_file,nuke_dir,2},
{couch_index_server,handle_cast,2},
{gen_server,handle_msg,5},
{proc_lib,init_p_do_apply,3}]},
[{gen_server,terminate,6},
{proc_lib,init_p_do_apply,3}]}},
{ancestors,
[couch_secondary_services,couch_server_sup,
0.19958.0]},
{messages,
[{'$gen_cast',
{reset_indexes,test_suite_db_a}}]},
{links,[0.20051.0,0.20026.0]},
{dictionary,[]},
{trap_exit,true},
{status,running},
{heap_size,1597},
{stack_size,24},
[jira] [Commented] (COUCHDB-1346) CouchDB hangs during start of view indexing
[
https://issues.apache.org/jira/browse/COUCHDB-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13508271#comment-13508271
]
Adam Kocoloski commented on COUCHDB-1346:
-
I did some more reading and log-based debugging this morning. We're doing
something rather screwy. It turns out the the individual view index processes
are *already* monitoring their parent DB; when we delete the DB, the index is
automatically closed:
https://github.com/apache/couchdb/blob/bde29b/src/couch_index/src/couch_index.erl#L80
https://github.com/apache/couchdb/blob/bde29b/src/couch_index/src/couch_index.erl#L296-L300
The handler for that 'DOWN' message will invoke the gen_server's terminate
function, which closes the file descriptor cleanly. So that's A Good Thing.
Unfortunately, we don't always let that cleanup run to completion, because
we've got this separate DB update notification listener:
https://github.com/apache/couchdb/blob/bde29b/src/couch_index/src/couch_index_server.erl#L159-L168
The couch_index processes do not trap exits, so when the reset_indexes function
calls shutdown_sync it terminates the couch_index process immediately,
bypassing any additional cleanup that we wanted to do. The patch I wrote
allows for the termination to finish cleanly.
It seems to me that even with the existing shutdown_sync invocation we'd
eventually close all the file descriptors because of exit signal propagation,
but at that point we may be racing the process that tries to delete them (and
when we lose, we hang). The clean shutdown avoids that race.
CouchDB hangs during start of view indexing
---
Key: COUCHDB-1346
URL: https://issues.apache.org/jira/browse/COUCHDB-1346
Project: CouchDB
Issue Type: Bug
Components: View Server Support
Affects Versions: 1.3
Environment: Windows 7 Enterprise only, not able to replicate on Mac
OS X.
Erlang R14B03 + crypto patches.
Mozilla Javascript 1.8.5
Reporter: Dave Cottlehuber
Assignee: Adam Kocoloski
Priority: Blocker
Labels: Windows
Fix For: 1.3
[info] [0.20499.0] Opening index for db: test_suite_db idx:
f4421bf4e9c9bf2acb3db91bca9e9adc sig: d5c87ad33242b181f86be2139cbccd96
[info] [0.20504.0] Starting index update for db: test_suite_db idx:
f4421bf4e9c9bf2acb3db91bca9e9adc
[info] [0.20334.0] 172.16.40.1 - - POST /test_suite_db/_temp_view 500
[info] [0.20513.0] 172.16.40.1 - - GET
/_utils/couch_tests.html?script/couch_tests.js 200
[info] [0.20514.0] 172.16.40.1 - - GET /_utils/index.html 200
[info] [0.20060.0] 172.16.40.1 - - DELETE /test_suite_db_a/ 200
[info] [0.20407.0] 172.16.40.1 - - GET /test_suite_reports/ 404
[info] [0.20058.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20071.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20069.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20484.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20364.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20062.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20388.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20345.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20072.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20059.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20061.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20472.0] 172.16.40.1 - - DELETE /test_suite_db/ 200
[error] [0.20050.0] ** Generic server couch_index_server terminating
** Last message in was {'$gen_cast',{reset_indexes,test_suite_db}}
** When Server state == {st,../var/lib/couchdb}
** Reason for termination ==
** {{case_clause,{error,eacces}},
[{couch_file,'-nuke_dir/2-fun-0-',3},
{lists,foreach,2},
{couch_file,nuke_dir,2},
{couch_index_server,handle_cast,2},
{gen_server,handle_msg,5},
{proc_lib,init_p_do_apply,3}]}
=ERROR REPORT 23-Nov-2011::21:17:14 ===
** Generic server couch_index_server terminating
** Last message in was {'$gen_cast',{reset_indexes,test_suite_db}}
** When Server state == {st,../var/lib/couchdb}
** Reason for termination ==
** {{case_clause,{error,eacces}},
[{couch_file,'-nuke_dir/2-fun-0-',3},
{lists,foreach,2},
{couch_file,nuke_dir,2},
{couch_index_server,handle_cast,2},
{gen_server,handle_msg,5},
{proc_lib,init_p_do_apply,3}]}
[error] [0.20050.0] {error_report,0.19957.0,
{0.20050.0,crash_report,
[[{initial_call,
{couch_index_server,init,['Argument__1']}},
{pid,0.20050.0},
{registered_name,couch_index_server},
{error_info,
[jira] [Commented] (COUCHDB-1346) CouchDB hangs during start of view indexing
[
https://issues.apache.org/jira/browse/COUCHDB-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13508146#comment-13508146
]
Adam Kocoloski commented on COUCHDB-1346:
-
I took a closer look at this ticket today and came up with the patch below to
ensure that view index files are closed before we attempt to nuke the directory
when executing a reset_indexes call. [~dch] helped me load the patch on a test
Windows instance at EC2, and we confirmed that the patch allows the basics
entry in the test suite to run to completion when it hadn't before. So, yay
for that.
Unfortunately, we're noticing frequent hangs in other portions of the test
suite, including but not limited to the design_options test. My observations
from an evening running tests:
* The design_options test always passes with the log level set to debug.
* When the level is set to info the test often hangs, and the Erlang VM seems
to hang as well.
* The hang often occurs on the second invocation of the test.
* The hang occurs with _and_ without my patch.
That last point is rather crucial. [~dch] indicated that the test had been
passing, but I can't seem to make that happen even with a stock build of the
HEAD of 1.3.x. My current recommendation is to review and apply this patch as
it only improves matters during my testing. That being said, I'd love to
understand the root cause of these hangs when debug logging is disabled.
{code:diff}
diff --git a/src/couch_index/src/couch_index_server.erl
b/src/couch_index/src/couch_index_server.erl
index 48fa8e4..bc1fce7 100644
--- a/src/couch_index/src/couch_index_server.erl
+++ b/src/couch_index/src/couch_index_server.erl
@@ -160,7 +160,9 @@ reset_indexes(DbName, Root) -
% shutdown all the updaters and clear the files, the db got changed
Fun = fun({_, {DDocId, Sig}}) -
[{_, Pid}] = ets:lookup(?BY_SIG, {DbName, Sig}),
-couch_util:shutdown_sync(Pid),
+MRef = erlang:monitor(process, Pid),
+gen_server:cast(Pid, delete),
+receive {'DOWN', MRef, _, _, _} - ok end,
rem_from_ets(DbName, Sig, DDocId, Pid)
end,
lists:foreach(Fun, ets:lookup(?BY_DB, DbName)),
{code}
CouchDB hangs during start of view indexing
---
Key: COUCHDB-1346
URL: https://issues.apache.org/jira/browse/COUCHDB-1346
Project: CouchDB
Issue Type: Bug
Components: View Server Support
Affects Versions: 1.3
Environment: Windows 7 Enterprise only, not able to replicate on Mac
OS X.
Erlang R14B03 + crypto patches.
Mozilla Javascript 1.8.5
Reporter: Dave Cottlehuber
Assignee: Adam Kocoloski
Priority: Blocker
Labels: Windows
Fix For: 1.3
[info] [0.20499.0] Opening index for db: test_suite_db idx:
f4421bf4e9c9bf2acb3db91bca9e9adc sig: d5c87ad33242b181f86be2139cbccd96
[info] [0.20504.0] Starting index update for db: test_suite_db idx:
f4421bf4e9c9bf2acb3db91bca9e9adc
[info] [0.20334.0] 172.16.40.1 - - POST /test_suite_db/_temp_view 500
[info] [0.20513.0] 172.16.40.1 - - GET
/_utils/couch_tests.html?script/couch_tests.js 200
[info] [0.20514.0] 172.16.40.1 - - GET /_utils/index.html 200
[info] [0.20060.0] 172.16.40.1 - - DELETE /test_suite_db_a/ 200
[info] [0.20407.0] 172.16.40.1 - - GET /test_suite_reports/ 404
[info] [0.20058.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20071.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20069.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20484.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20364.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20062.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20388.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20345.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20072.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20059.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20061.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20472.0] 172.16.40.1 - - DELETE /test_suite_db/ 200
[error] [0.20050.0] ** Generic server couch_index_server terminating
** Last message in was {'$gen_cast',{reset_indexes,test_suite_db}}
** When Server state == {st,../var/lib/couchdb}
** Reason for termination ==
** {{case_clause,{error,eacces}},
[{couch_file,'-nuke_dir/2-fun-0-',3},
{lists,foreach,2},
{couch_file,nuke_dir,2},
{couch_index_server,handle_cast,2},
{gen_server,handle_msg,5},
{proc_lib,init_p_do_apply,3}]}
=ERROR REPORT 23-Nov-2011::21:17:14 ===
** Generic server couch_index_server terminating
** Last message in was {'$gen_cast',{reset_indexes,test_suite_db}}
** When Server state == {st,../var/lib/couchdb}
** Reason for termination ==
**
[jira] [Commented] (COUCHDB-1593) Raise erlang/OTP minimum version to R13B04
[ https://issues.apache.org/jira/browse/COUCHDB-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13506536#comment-13506536 ] Adam Kocoloski commented on COUCHDB-1593: - The challenge with the backport that Benoit identified will come if an Ubuntu maintainer wants to update the version of CouchDB in lucid-backports from 1.0.1 to something more modern. I don't think depending on a third party Erlang outside of the Ubuntu ecosystem will be kosher. The ESL package would be perfectly fine for a user who wanted to build CouchDB 1.3 from our release artifact on an Ubuntu 10.04 system. Raise erlang/OTP minimum version to R13B04 -- Key: COUCHDB-1593 URL: https://issues.apache.org/jira/browse/COUCHDB-1593 Project: CouchDB Issue Type: Improvement Reporter: Robert Newson Assignee: Robert Newson Priority: Blocker Fix For: 1.3 Let's ensure that all 1.3.0 installations have snappy and ejson by insisting that all builds use R13B04 or higher. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1593) Raise erlang/OTP minimum version to R13B04
[ https://issues.apache.org/jira/browse/COUCHDB-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13506003#comment-13506003 ] Adam Kocoloski commented on COUCHDB-1593: - Sadly Ubuntu 10.04 LTS uses 13B03. I know there's a newer LTS out there but I'd wager 10.04 is still pretty popular. I wonder if we could finagle a backport of something better? Raise erlang/OTP minimum version to R13B04 -- Key: COUCHDB-1593 URL: https://issues.apache.org/jira/browse/COUCHDB-1593 Project: CouchDB Issue Type: Improvement Reporter: Robert Newson Assignee: Robert Newson Priority: Blocker Fix For: 1.3 Let's ensure that all 1.3.0 installations have snappy and ejson by insisting that all builds use R13B04 or higher. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (COUCHDB-1346) CouchDB hangs during start of view indexing
[
https://issues.apache.org/jira/browse/COUCHDB-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Kocoloski reassigned COUCHDB-1346:
---
Assignee: Adam Kocoloski (was: Dave Cottlehuber)
CouchDB hangs during start of view indexing
---
Key: COUCHDB-1346
URL: https://issues.apache.org/jira/browse/COUCHDB-1346
Project: CouchDB
Issue Type: Bug
Components: View Server Support
Affects Versions: 1.3
Environment: Windows 7 Enterprise only, not able to replicate on Mac
OS X.
Erlang R14B03 + crypto patches.
Mozilla Javascript 1.8.5
Reporter: Dave Cottlehuber
Assignee: Adam Kocoloski
Priority: Blocker
Labels: Windows
Fix For: 1.3
[info] [0.20499.0] Opening index for db: test_suite_db idx:
f4421bf4e9c9bf2acb3db91bca9e9adc sig: d5c87ad33242b181f86be2139cbccd96
[info] [0.20504.0] Starting index update for db: test_suite_db idx:
f4421bf4e9c9bf2acb3db91bca9e9adc
[info] [0.20334.0] 172.16.40.1 - - POST /test_suite_db/_temp_view 500
[info] [0.20513.0] 172.16.40.1 - - GET
/_utils/couch_tests.html?script/couch_tests.js 200
[info] [0.20514.0] 172.16.40.1 - - GET /_utils/index.html 200
[info] [0.20060.0] 172.16.40.1 - - DELETE /test_suite_db_a/ 200
[info] [0.20407.0] 172.16.40.1 - - GET /test_suite_reports/ 404
[info] [0.20058.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20071.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20069.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20484.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20364.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20062.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20388.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20345.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20072.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20059.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20061.0] 172.16.40.1 - - DELETE /test_suite_db/ 404
[info] [0.20472.0] 172.16.40.1 - - DELETE /test_suite_db/ 200
[error] [0.20050.0] ** Generic server couch_index_server terminating
** Last message in was {'$gen_cast',{reset_indexes,test_suite_db}}
** When Server state == {st,../var/lib/couchdb}
** Reason for termination ==
** {{case_clause,{error,eacces}},
[{couch_file,'-nuke_dir/2-fun-0-',3},
{lists,foreach,2},
{couch_file,nuke_dir,2},
{couch_index_server,handle_cast,2},
{gen_server,handle_msg,5},
{proc_lib,init_p_do_apply,3}]}
=ERROR REPORT 23-Nov-2011::21:17:14 ===
** Generic server couch_index_server terminating
** Last message in was {'$gen_cast',{reset_indexes,test_suite_db}}
** When Server state == {st,../var/lib/couchdb}
** Reason for termination ==
** {{case_clause,{error,eacces}},
[{couch_file,'-nuke_dir/2-fun-0-',3},
{lists,foreach,2},
{couch_file,nuke_dir,2},
{couch_index_server,handle_cast,2},
{gen_server,handle_msg,5},
{proc_lib,init_p_do_apply,3}]}
[error] [0.20050.0] {error_report,0.19957.0,
{0.20050.0,crash_report,
[[{initial_call,
{couch_index_server,init,['Argument__1']}},
{pid,0.20050.0},
{registered_name,couch_index_server},
{error_info,
{exit,
{{case_clause,{error,eacces}},
[{couch_file,'-nuke_dir/2-fun-0-',3},
{lists,foreach,2},
{couch_file,nuke_dir,2},
{couch_index_server,handle_cast,2},
{gen_server,handle_msg,5},
{proc_lib,init_p_do_apply,3}]},
[{gen_server,terminate,6},
{proc_lib,init_p_do_apply,3}]}},
{ancestors,
[couch_secondary_services,couch_server_sup,
0.19958.0]},
{messages,
[{'$gen_cast',
{reset_indexes,test_suite_db_a}}]},
{links,[0.20051.0,0.20026.0]},
{dictionary,[]},
{trap_exit,true},
{status,running},
{heap_size,1597},
{stack_size,24},
{reductions,12211}],
[{neighbour,
[jira] [Commented] (COUCHDB-1583) improve the flow control in ibrowse streams
[ https://issues.apache.org/jira/browse/COUCHDB-1583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13488134#comment-13488134 ] Adam Kocoloski commented on COUCHDB-1583: - Thanks for opening this ticket Bob. Sorry for not firing off a topic branch sooner. When we started using the new replicator internally at Cloudant we noticed that long-running replications would ultimately consume a ton of memory on the node mediating the replication and crash. I tracked it down to the mailbox for the process consuming the _changes feed over HTTP, and from there to a misuse of ibrowse's stream_next API. Admittedly the API is super-confusing; it should have a big read warning box telling you that you may receive multiple messages for each invocation of the function. The patch is working well for us, and given that the commit landed directly on master I'm going to go ahead and resolve this one. improve the flow control in ibrowse streams --- Key: COUCHDB-1583 URL: https://issues.apache.org/jira/browse/COUCHDB-1583 Project: CouchDB Issue Type: Improvement Components: Replication Reporter: Bob Dionne Assignee: Adam Kocoloski Fix For: 1.3 The flow control in ibrowse's async response streams is tricky. We call stream_next to pull more data off the socket, but it seems that ibrowse will sometimes split that data into multiple messages. If we call stream_next for each message we process we end up with an overflowing mailbox. This commit[1] changes the consumer so that it clears out the mailbox before calling stream_next. [1] 8ccf696f833a0f0a453d -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-1583) improve the flow control in ibrowse streams
[ https://issues.apache.org/jira/browse/COUCHDB-1583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Kocoloski resolved COUCHDB-1583. - Resolution: Fixed improve the flow control in ibrowse streams --- Key: COUCHDB-1583 URL: https://issues.apache.org/jira/browse/COUCHDB-1583 Project: CouchDB Issue Type: Improvement Components: Replication Reporter: Bob Dionne Assignee: Adam Kocoloski Fix For: 1.3 The flow control in ibrowse's async response streams is tricky. We call stream_next to pull more data off the socket, but it seems that ibrowse will sometimes split that data into multiple messages. If we call stream_next for each message we process we end up with an overflowing mailbox. This commit[1] changes the consumer so that it clears out the mailbox before calling stream_next. [1] 8ccf696f833a0f0a453d -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1249) Documentation for view function in jquery.couch.js needs work
[ https://issues.apache.org/jira/browse/COUCHDB-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Kocoloski updated COUCHDB-1249: Fix Version/s: (was: 1.1) 1.2 Update FixFor Documentation for view function in jquery.couch.js needs work - Key: COUCHDB-1249 URL: https://issues.apache.org/jira/browse/COUCHDB-1249 Project: CouchDB Issue Type: Bug Components: JavaScript View Server Affects Versions: 1.1 Reporter: Mike McKay Priority: Minor Labels: documentation Fix For: 1.2 Original Estimate: 5m Remaining Estimate: 5m patch here: http://pastie.org/2378357 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-1292) validate_doc_update: function(n,o,u){}
[
https://issues.apache.org/jira/browse/COUCHDB-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Kocoloski resolved COUCHDB-1292.
-
Resolution: Not A Problem
Hi Gert, the wiki is user-editable, no need for a commit bit.
validate_doc_update: function(n,o,u){}
Key: COUCHDB-1292
URL: https://issues.apache.org/jira/browse/COUCHDB-1292
Project: CouchDB
Issue Type: Improvement
Components: Database Core
Affects Versions: 1.2
Environment: linux
Reporter: gert cuykens
Priority: Trivial
Labels: couchdb
Original Estimate: 24h
Remaining Estimate: 24h
Assign a function instead of a string to make validation handler consistent
with the update handlers
consistent = updates: { hello: function(d,r) {} }
consistent = validate_doc_update: function(n,o,u){}
inconsistent = validate_doc_update: function(n,o,u){}
http://wiki.apache.org/couchdb/Document_Update_Handlers
http://wiki.apache.org/couchdb/Document_Update_Validation
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1278) Add Apache httpd-style common log access logging.
[ https://issues.apache.org/jira/browse/COUCHDB-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13104516#comment-13104516 ] Adam Kocoloski commented on COUCHDB-1278: - Hi Jan, I took a look at https://github.com/janl/couchdb/commit/614091. I'm not sure I understand how the error_logger process is involved. Your clients are writing to the disk_log directly, but you've got a couch_access_log gen_event hanging on the error_logger event manager. That event handler listens for couch_access events and logs them to stdout, but I don't see any couch_access events being generated. You're also making the error_logger process subscribe to disk_log notifications, and removing the couch_access_log handler if you get any (expecting that the event_sup thinger will restart it). Looking over Filipe's recent changes to couch_log I can see that most of my comments apply there as well. Perhaps he can shed some light on the design here. Add Apache httpd-style common log access logging. - Key: COUCHDB-1278 URL: https://issues.apache.org/jira/browse/COUCHDB-1278 Project: CouchDB Issue Type: New Feature Reporter: Jan Lehnardt This module introduces a new log file couch_access.log in the spirit of Apache httpd's access.log. The log format is specified here: http://en.wikipedia.org/wiki/Common_Log_Format The module defaults to the more commonly used `extended` format, but can be configured to use the standard log format as well. This is a new module rather than an extension to the couch_log module to allow easy addition. Ideally, this will be a plugin in the future. A note for chunked responses, the response body length reported is chunked rather than the number of bytes. The case is unspecified in the format description. Maybe the fix is keeping track of bytes sent in a chunked response, but I didn't want to make the first stab at this more complicated that it has to be. I'm happy to adjust. See the full diff here: https://github.com/janl/couchdb/commit/614091e49380b3afab3c34ff65e6d87623059b8b I'm not proposing this to be added to 1.1.x, but if anybody wants it, there's a patch here: https://github.com/janl/couchdb/commit/508af053257c074ec37c9bd658479cc21b8d20d4 (The only difference is the specification of the couch_access_log module on startup, as that moved from couch_server_sup.erl to couch_primary_services.erl) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1270) Rewrite the view engine
[ https://issues.apache.org/jira/browse/COUCHDB-1270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13099564#comment-13099564 ] Adam Kocoloski commented on COUCHDB-1270: - I agree with Benoit that defining a custom behaviour seems like the right approach instead of couch_index_api. I guess that'd require some mucking with the build system to ensure that the compiler knows the behaviour spec? It's not a blocker from my perspective, but I would like to see it happen. I haven't been too impressed with supervisors that dynamically add children. I'd love it if we didn't have to implement our own supervision trees everywhere, but I think that might be something we tackle in a separate ticket. Rewrite the view engine --- Key: COUCHDB-1270 URL: https://issues.apache.org/jira/browse/COUCHDB-1270 Project: CouchDB Issue Type: Improvement Components: JavaScript View Server Reporter: Paul Joseph Davis Attachments: 0001-Minor-changes-for-new-indexing-engine.patch, 0002-Create-the-couch_index-application.patch, 0003-Create-the-couch_mrview-application.patch, 0004-Remove-the-old-view-engine.patch The view engine has been creaky and cluttered. As shown by GeoCouch, adding new indexers basically involves copying the entire view engine and hacking the parts that are different. In short, the opposite of good engineering. Over the last couple weeks I've refactored the view engine and reimplemented the map/reduce view engine. These changes are 100% internal and no external behavior has changed. Performance is just a tiny bit better than trunk. I did do some playing trying to improve view update times and there are some dances we could do, but for the time being I wanted to keep the same general architecture for updates so that the changes are minimal. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
