[jira] Commented: (COUCHDB-719) Bad escaping in Futon view document list
[ https://issues.apache.org/jira/browse/COUCHDB-719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12851312#action_12851312 ] Dirkjan Ochtman commented on COUCHDB-719: - Also, I'm pretty sure this is a regression from 0.10.1. Bad escaping in Futon view document list Key: COUCHDB-719 URL: https://issues.apache.org/jira/browse/COUCHDB-719 Project: CouchDB Issue Type: Bug Components: Futon Affects Versions: 0.11 Reporter: Dirkjan Ochtman Priority: Minor Fix For: 0.11.1 I have a database where document ID's include '' and ''. When I browse the database, Futon shows 'lt;' for the key (double-escaping the actual value). On the other hand, for the ID just below that, the entire value is missing, suggesting that it's not escaped at all in that case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-719) Bad escaping in Futon view document list
Bad escaping in Futon view document list Key: COUCHDB-719 URL: https://issues.apache.org/jira/browse/COUCHDB-719 Project: CouchDB Issue Type: Bug Components: Futon Affects Versions: 0.11 Reporter: Dirkjan Ochtman Priority: Minor Fix For: 0.12 I have a database where document ID's include '' and ''. When I browse the database, Futon shows 'lt;' for the key (double-escaping the actual value). On the other hand, for the ID just below that, the entire value is missing, suggesting that it's not escaped at all in that case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-719) Bad escaping in Futon view document list
[ https://issues.apache.org/jira/browse/COUCHDB-719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dirkjan Ochtman updated COUCHDB-719: Fix Version/s: (was: 0.12) 0.11.1 Bad escaping in Futon view document list Key: COUCHDB-719 URL: https://issues.apache.org/jira/browse/COUCHDB-719 Project: CouchDB Issue Type: Bug Components: Futon Affects Versions: 0.11 Reporter: Dirkjan Ochtman Priority: Minor Fix For: 0.11.1 I have a database where document ID's include '' and ''. When I browse the database, Futon shows 'lt;' for the key (double-escaping the actual value). On the other hand, for the ID just below that, the entire value is missing, suggesting that it's not escaped at all in that case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (COUCHDB-716) CouchDB fails to start, just hangs.
On Tue, Mar 30, 2010 at 12:45 PM, Robert Dionne dio...@dionne-associates.com wrote: I'm curious if it's starting the dependent apps. It might be a bad build. Can you try: couch_app:start(_,[]). That's an underscore and a period at the end you should change your font if you need to explain ;)
[jira] Updated: (COUCHDB-700) Performance Regression for view generation in 0.11
[ https://issues.apache.org/jira/browse/COUCHDB-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrik Thostrup Jensen updated COUCHDB-700: --- Fix Version/s: 0.12 Affects Version/s: (was: 0.10) 0.11 Performance Regression for view generation in 0.11 -- Key: COUCHDB-700 URL: https://issues.apache.org/jira/browse/COUCHDB-700 Project: CouchDB Issue Type: Improvement Components: Database Core Affects Versions: 0.11 Environment: Ubuntu 9.04: Stock CouchDB 0.10 / Own build of CoucDB 0.11 branch. Reporter: Henrik Thostrup Jensen Fix For: 0.12 Attachments: couchdb_011_view_speedup.diff Copied from mail to dev at March 15, 2010: I have a synthetic benchmark for view generation over 70K documents. In stock CouchDB 0.10, the view will be checkpointed about 15-17 times. Around 9 times with the batch_save_size and batch_save_interval set to 1. CouchDB 0.11 on the other hand performs a whopping 108/109 checkpoints of the view. Due to shadow B-trees this generates significantly larger view files (2-3x much) and more time is spend writing to disk. Generating the view takes roughly twice as long in 0.11 as it does in 0.10. I've tracked down the problem to the new view generation architecture; particularly the small sizes of the work queues defined in couch_view_updater.erl. The attached patch decreases the number of checkpoints to around 15, and makes view generation slightly faster than 0.10. It basically increases the size of the write queue. Inserting a 500 ms sleep in do_writes increased the performance a bit more, but that is not a nice or right solution. I suspect the patch is not the completely right solution (tm), as a lot checkpoints are performed initially whereafter it backs off and starts to take longer time/revisions between the checkpoints. I suspect that the code is just writing repeatedly and as writes start to take longer time, more revisions are added per checkpoint. Though I am not really sure of this. Still, it is a 2 line patch, and it significantly increases view generation performance. I'd very much like to see this in 0.11, to avoid a rather large performance regression between 0.10 and 0.11. If 0.11 comes out as it is, we would either have to stick with 0.10 or build our own patched 0.11. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (COUCHDB-716) CouchDB fails to start, just hangs.
thanks for thinking of me, I'm getting new glasses next week anyway so I should be ok. On Mar 30, 2010, at 7:18 AM, Benoit Chesneau wrote: On Tue, Mar 30, 2010 at 12:45 PM, Robert Dionne dio...@dionne-associates.com wrote: I'm curious if it's starting the dependent apps. It might be a bad build. Can you try: couch_app:start(_,[]). That's an underscore and a period at the end you should change your font if you need to explain ;)
Please fix #665 for CouchDB 1.0
Hi! Before the release of CouchDB 1.0, it would be great if you could fix #665. The patch is very simple, as it is just the missing 'inet6' option which prevents replication to work via IPv6. Merging/testing the patch is also very simple and should not take longer than 15 minutes. If you have any questions, please just ask (and please CC me, as I am not on this list). Best regards, Michael
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.
Cheers,
Dirkjan
[jira] Commented: (COUCHDB-716) CouchDB fails to start, just hangs.
[ https://issues.apache.org/jira/browse/COUCHDB-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12851458#action_12851458 ] Victor Igumnov commented on COUCHDB-716: I am fairly sure solaris is a well supported target. If this was the case then couchdb 0.10.1 would not work. CouchDB fails to start, just hangs. --- Key: COUCHDB-716 URL: https://issues.apache.org/jira/browse/COUCHDB-716 Project: CouchDB Issue Type: Bug Components: Database Core Affects Versions: 0.11 Environment: opensolaris/snv98 Reporter: Victor Igumnov CouchDB 0.10.x works well while CouchDB 0.11 fails to start, it just hangs with no debug information. I have used truss to trace the execution to the hang point. Truss debug info http://temp.fabulously40.com/~victori/couch.txt Pstack info on the hanged process http://temp.fabulously40.com/~victori/couchdb-pstack.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Compaction issue after upgrade 0.10.1-0.11.0
I'm interested in your problem, which might be related to something Simon
Eisenmann was seeing. Can you put the database and the server log file
somewhere I can access it?
-Damien
On Mar 30, 2010, at 8:19 AM, Dirkjan Ochtman wrote:
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.
Cheers,
Dirkjan
[jira] Commented: (COUCHDB-707) Proposal for Filter Views
[ https://issues.apache.org/jira/browse/COUCHDB-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12851512#action_12851512 ] Luke Burton commented on COUCHDB-707: - I'll have a crack at implementing something simple. At the very least, it's worth conducting the experiment! Proposal for Filter Views --- Key: COUCHDB-707 URL: https://issues.apache.org/jira/browse/COUCHDB-707 Project: CouchDB Issue Type: New Feature Components: JavaScript View Server Affects Versions: 0.11 Reporter: Luke Burton A common operation I find myself performing repeatedly is: * request a view (maybe with some basic filter like keys or a range of keys) * in my client, filter this view based on some complex criteria, leaving me with a small set of document IDs (complex as in array intersections, compound boolean operations, other stuff not possible in the HTTP view API) * go back to Couch and fetch the complete documents for these IDs. List Views almost get me to the point of doing this purely in Couch. I can enumerate over a view and do some complex things with it. But I can't output entire documents, unless I use the include_docs=true flag which murders the performance of the list view.Apparently because the entire view is fetched with including docs, THEN passed on to the list view JS. Typically my complex filter criteria is contained in the view itself, so there is no need to fetch the entire document until I know I have a match. In summary, a Filter View would execute some arbitrary JavaScript on each view row, with access to HTTP request parameters, and return true for rows that match. The output would be a list of IDs for whom the function returned true. include_docs=true would include the matching documents. Performance would certainly not be as good as fetching a raw view, but it would indisputably be better than fetching the entire view over HTTP to a client, deserializing the JSON, doing some stuff, then making another HTTP request, and deserializing more JSON. I looked at the various entry points for list views in the Couch source. Unfortunately it will take me some time to come up to speed with the source (if I ever have the time ...), and I hope that what I'm asking for could be a simple extension to the List Views for someone very familiar with this area. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-716) CouchDB fails to start, just hangs.
[ https://issues.apache.org/jira/browse/COUCHDB-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12851587#action_12851587 ] Randall Leeds commented on COUCHDB-716: --- It looks like there should be another trailing } in there to close the application record. Is this a copy/paste mistake? If not, can you try adding } to the end of couch.app? CouchDB fails to start, just hangs. --- Key: COUCHDB-716 URL: https://issues.apache.org/jira/browse/COUCHDB-716 Project: CouchDB Issue Type: Bug Components: Database Core Affects Versions: 0.11 Environment: opensolaris/snv98 Reporter: Victor Igumnov CouchDB 0.10.x works well while CouchDB 0.11 fails to start, it just hangs with no debug information. I have used truss to trace the execution to the hang point. Truss debug info http://temp.fabulously40.com/~victori/couch.txt Pstack info on the hanged process http://temp.fabulously40.com/~victori/couchdb-pstack.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-716) CouchDB fails to start, just hangs.
[ https://issues.apache.org/jira/browse/COUCHDB-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12851588#action_12851588 ] Paul Joseph Davis commented on COUCHDB-716: --- Also the modules section is empty which is probably the real issue. Trying to track it down on IRC. CouchDB fails to start, just hangs. --- Key: COUCHDB-716 URL: https://issues.apache.org/jira/browse/COUCHDB-716 Project: CouchDB Issue Type: Bug Components: Database Core Affects Versions: 0.11 Environment: opensolaris/snv98 Reporter: Victor Igumnov CouchDB 0.10.x works well while CouchDB 0.11 fails to start, it just hangs with no debug information. I have used truss to trace the execution to the hang point. Truss debug info http://temp.fabulously40.com/~victori/couch.txt Pstack info on the hanged process http://temp.fabulously40.com/~victori/couchdb-pstack.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-721) possible data corruption after upgrade compaction
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
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.
-
You can reply to this email to add a comment to the issue online.
Re: Compaction issue after upgrade 0.10.1-0.11.0
On Tue, Mar 30, 2010 at 10:53 AM, Damien Katz dam...@apache.org wrote: I'm interested in your problem, which might be related to something Simon Eisenmann was seeing. Can you put the database and the server log file somewhere I can access it? This problem has been converted into a JIRA issue: https://issues.apache.org/jira/browse/COUCHDB-721 Tim -- If you're not part of the solution, you're part of the precipitate
Re: (lack of) couchdb windows binaries
On 30/03/2010 5:00 PM, Noah Slater wrote: On 30 Mar 2010, at 01:58, Mark Hammond wrote: I understand that - however, the Windows issues are well known, have existed forever and has never before been raised as a blocker for a windows binary. If I knew it would be considered as such I would not have invested any further efforts in Windows binaries until the windows issues were resolved. If you're happy preparing the binary, I am happy to call a vote on it. Great - it can be found at http://people.apache.org/~mhammond/dist/0.11.0/ ... As above, I have no interest in, or knowledge of the issues here, so I will leave the honours to someone who does (or at least someone who has enough grasp of this to consider it a problem.) Actually, I think you're the only person with enough knowledge to handle this. You're not expected to know anything about the law. The purpose of the list is for people with the technical knowledge to ask the people with the legal knowledge what the best way forward is. If you start a thread on legal telling them how the Windows binary is constructed, and asking them if that is okay, that should be all that you have to do. Sorry, but this needs to be undertaken by someone who actually believes there is an issue and can articulate it. This person also needs to understand the couchdb dependencies on any platform (Windows is no different in this regard) and understands the concept of a binary release. While I meet the last 2 criteria, I don't meet the first. So please let me be completely clear and explicitly decline for the 3rd time :) Cheers, Mark
Re: (lack of) couchdb windows binaries
On Wed, Mar 31, 2010 at 4:03 AM, Mark Hammond skippy.hamm...@gmail.com wrote: On 30/03/2010 5:00 PM, Noah Slater wrote: On 30 Mar 2010, at 01:58, Mark Hammond wrote: I understand that - however, the Windows issues are well known, have existed forever and has never before been raised as a blocker for a windows binary. If I knew it would be considered as such I would not have invested any further efforts in Windows binaries until the windows issues were resolved. If you're happy preparing the binary, I am happy to call a vote on it. Great - it can be found at http://people.apache.org/~mhammond/dist/0.11.0/ This is a relief. Thank you. I was rather worried for a while. Providing binaries is a critical for CouchDB adoption on windows. And the build should definitely be part of the release process, IMO. Otherwise there's a risk of getting stuck in a chicken and egg situation: crippling bugs - don't release - not enough users complaining about the bugs - nobody fixes the bugs. Cheers! -juhani
