Re: Releasing 0.11, Request for Comments
See my last comment on https://issues.apache.org/jira/browse/COUCHDB-597 I would 3 3 3 to see this make it.
[jira] Updated: (COUCHDB-597) Replication tasks crash.
[
https://issues.apache.org/jira/browse/COUCHDB-597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Randall Leeds updated COUCHDB-597:
--
Attachment: couchdb_597.patch
I believe this patch fixes most of the problems we're seeing here.
The solution, as discussed, is to remove the inactivity_timeout from options
passed to ibrowse and handle timeouts manually (here using the timer module).
In my testing, I could mostly reproduce timeouts caused by not reading data
from ibrowse fast enough. In other words, replicating from a remote database
was terminating because processing the changes was taking a long time to
complete and the socket would be inactive while couch_rep_changes_feed had a
full queue of rows. Therefore, a timeout is not set unless the missing revs
server is waiting for more changes.
Timeouts should still occur if the socket is idle and the local queue of
received changes is empty. Errors should be caught appropriately such that real
problems still bubble.
I implemented retry logic for attachments in a manner similar to
couch_rep_httpc. I had to add some after statements now that the
inactivity_timeout is not set.
The patch applies cleanly to trunk and 0.11.x, so please review!!! I think this
would be a very good patch to get into 0.11 so long as Noah hasn't built the
artifacts yet.
Replication tasks crash.
Key: COUCHDB-597
URL: https://issues.apache.org/jira/browse/COUCHDB-597
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 0.11
Reporter: Robert Newson
Attachments: couchdb_597.patch
If I kick off 10 replication tasks in quick succession, occasionally one or
two of the replication tasks will die and not be resumed. It seems that the
stat tracking is a little buggy, and under stress can eventually cause a
permanent failure of the supervised replication task;
[Fri, 11 Dec 2009 19:00:08 GMT] [error] [0.80.0] {error_report,0.30.0,
{0.80.0,supervisor_report,
[{supervisor,{local,couch_rep_sup}},
{errorContext,shutdown_error},
{reason,killed},
{offender,
[{pid,0.6700.11},
{name,fcbb13200a1618cf983b347f4d2c9835+create_target},
{mfa,
{gen_server,start_link,
[couch_rep,
[fcbb13200a1618cf983b347f4d2c9835,
{[{create_target,true},
{source,http://node:5984/perf-p2;},
{target,perf-p2}]},
{user_ctx,null,[_admin]}],
[]]}},
{restart_type,temporary},
{shutdown,1},
{child_type,worker}]}]}}
[Fri, 11 Dec 2009 19:00:08 GMT] [error] [emulator] Error in process
0.6705.11 with exit value:
{badarg,[{ets,insert,[stats_hit_table,{{couchdb,open_os_files},-1}]},{couch_stats_collector,decrement,1}]}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: lazy start of couch_icu_driver
I have just worked out a patch on branch 0.11.x. On Thu, Feb 25, 2010 at 1:36 PM, Jan Lehnardt j...@apache.org wrote: Do you have a patch to add that behaviour? :) Cheers Jan -- -- Li Zhengji
[jira] Created: (COUCHDB-671) Futon changes data when starting to edit
Futon changes data when starting to edit Key: COUCHDB-671 URL: https://issues.apache.org/jira/browse/COUCHDB-671 Project: CouchDB Issue Type: Bug Components: Futon Affects Versions: 0.11 Environment: Linux (Ubuntu 9.10), Chromium/Firefox Reporter: Matt Goodall Double-clicking a value in the document editor sometimes modifies the data. 1. Create a new document. 2. Add a field and enter one\ntwo\nthree (including the double quotes) as the value, click the tick. Should see three lines of text displayed. 3. Double-click the value to edit. Three lines collapse into one and \n are replaced with a single space! 4. Click green tick without making any changes. \n have been discarded. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Releasing 0.11, Request for Comments
And I just this morning noticed a request from Matt Goodall about 0.11 Futon storage. On 25 Feb 2010, at 10:06, Randall Leeds wrote: See my last comment on https://issues.apache.org/jira/browse/COUCHDB-597 I would 3 3 3 to see this make it.
Re: Windows 0.11 snapshot
Might want to get this fixed for the release Mark. The release artefact should have an sha1 and md5 hash in the same directory. Check the Verifying Releases section here: http://couchdb.apache.org/downloads.html Your files will need to pass this. On 25 Feb 2010, at 03:37, Mark Hammond wrote: On 25/02/2010 1:51 PM, Nicholas Orr wrote: The md5 file is expecting the file to be in a dir called windows - might want to update the md5 :) The md5 is auto-generated by the Makefile in the 'etc' directory - I'll make a fix for that as I find time (and patches welcome in the meantime ;) Cheers, Mark
Re: Releasing 0.11, Request for Comments
On 25 February 2010 11:35, Noah Slater nsla...@tumbolia.org wrote: And I just this morning noticed a request from Matt Goodall about 0.11 Futon storage. The Futon Storage issue, COUCHDB-668, is fixed in master/trunk. The one I'm really concerned about now is COUCHDB-671 [1], Futon changes data when starting to edit, and, to a lesser degree, COUCHDB-667 [2], Futon implicit typing when adding/editing fields is flawed, although the two issues are quite closely related. - Matt [1] https://issues.apache.org/jira/browse/COUCHDB-671 [2] https://issues.apache.org/jira/browse/COUCHDB-667
Re: Releasing 0.11, Request for Comments
If not asking too much, I would also like to see https://issues.apache.org/jira/browse/COUCHDB-639in 0.11. It's a follow up to the attachment compression feature and also fixes the problem with push replication when docs have large attachments (ticket 163 related also). cheers On Thu, Feb 25, 2010 at 12:35 PM, Noah Slater nsla...@tumbolia.org wrote: And I just this morning noticed a request from Matt Goodall about 0.11 Futon storage. On 25 Feb 2010, at 10:06, Randall Leeds wrote: See my last comment on https://issues.apache.org/jira/browse/COUCHDB-597 I would 3 3 3 to see this make it. -- Filipe David Manana, fdman...@gmail.com PGP key - http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xC569452B Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men.
Re: Releasing 0.11, Request for Comments
I second this emotion. :) On Thu, Feb 25, 2010 at 5:06 AM, Randall Leeds randall.le...@gmail.com wrote: See my last comment on https://issues.apache.org/jira/browse/COUCHDB-597 I would 3 3 3 to see this make it.
[jira] Created: (COUCHDB-672) info-message contains invalid URL when using IPv6
info-message contains invalid URL when using IPv6 - Key: COUCHDB-672 URL: https://issues.apache.org/jira/browse/COUCHDB-672 Project: CouchDB Issue Type: Improvement Affects Versions: 0.10 Environment: Linux midna 2.6.32.8-midna-2 #2 SMP Tue Feb 16 20:27:34 CET 2010 x86_64 GNU/Linux Reporter: Michael Stapelberg When starting, CouchDB prints the following message: [info] [0.1.0] Apache CouchDB has started on http://:::5985/ As you can see, I am listening on ::, the equivalent to 0.0.0.0 on IPv4. However, in URLs, you got to use square brackets around the IPv6 address to make the program able to distinguish IP and port. Thus, the URL has to look like this: http://[::]:5985/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Releasing 0.11, Request for Comments
On Feb 25, 2010, at 9:15 AM, Jan Lehnardt wrote: On 25 Feb 2010, at 04:43, Robert Newson wrote: I second this emotion. :) On Thu, Feb 25, 2010 at 5:06 AM, Randall Leeds randall.le...@gmail.com wrote: See my last comment on https://issues.apache.org/jira/browse/COUCHDB-597 I would 3 3 3 to see this make it. There's a ton of patches I'd like to see in CouchDB, but we'll never release anything if don't make a cut somewhere. 0.11 has been in the making for 9 months now and really needs to get out there so we can find and fix all the bugs that users find so 1.0 becomes a grand release. If you are concerned that yourfavouritepatch doesn't make it into 1.0: After 0.11 is released we'll only fix bugs in that branch and eventually cut 1.0 from it. If you think a new feature should be in 1.0 that is not in 0.11, call for a vote for that patch. Be prepared that it should be simple enough and should have tests and not break anything. If yourfavouritepatch is a bugfix, there's no need for a vote for a commit. Agreed. I'd further say that I consider the replicator to be the one place I'm happy to see enhancements introduced between 0.11 and 1.0. The replicator is decoupled from the rest of CouchDB, so changes here aren't likely to introduce instabilities. I'd also be fine to see enhancements to Futon made between 0.11 and 1.0. Again, nothing here is likely to negatively impact active CouchDB users, or otherwise cause instabilities. So really all of the patches brought up in the last few hours are good candidates for 1.0. Chris Cheers Jan --
Re: Request from the wiki gardener
Have you self-appointed as a wiki gnome? If so, wonderful! Thank you. Maybe one of the first things you could do is set up a wiki gnome page, and form a team of go-to people for the wiki. Nothing like knowing the people doing most of the work in one area, forming a bit of a community around it. On 25 Feb 2010, at 18:32, Sebastian Cohnen wrote: Hey couch-devs, I identified security as an imported topic that needs some (more) attention in the wiki (there has been a bunch of new features in this area recently). Unfortunately I have only minimal knowledge of CouchDB's security concepts (and even less what feature is available in which version). Basically I would like to ask the committers for some input on that topic - texts on overview, references... Currently I'm thinking of a structure for a new Security-wiki page to have smth. like a portal for this topic where all kinds of wiki pages and related material can be referenced. The available information on the security topic seems rather scattered over the wik atm. Thoughts? // The Gardener (alias tisba) and btw: please feel free to point me to any (other) topic that needs some gardening.
[jira] Commented: (COUCHDB-673) Filtered replication
[
https://issues.apache.org/jira/browse/COUCHDB-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12838447#action_12838447
]
Filipe Manana commented on COUCHDB-673:
---
Forgot to mention: JS explicit tests added and all of the existing JS and Etap
tests pass.
cheers
Filtered replication
Key: COUCHDB-673
URL: https://issues.apache.org/jira/browse/COUCHDB-673
Project: CouchDB
Issue Type: New Feature
Components: Replication
Affects Versions: 0.11
Environment: trunk / 0.11
Reporter: Filipe Manana
Attachments: filtered-replication.patch
The following patch adds support for filtered replication.
A replication object can now have 2 more optional fields: filter and
query_params.
Example:
{
source : sourceDB,
target : targetDB,
filter : mydesign/myfilter,
query_params : {
param1 : value,
param2 : int_value
// etc...
}
}
The filter must exist in the source DB, and it's the same type of filter as
used by the _changes handler. The parameter query_params is used for
adding fields to the req.query object passed as the second parameter to the
filter function (like the query string parameters passed to _changes).
The patch also does a refactoring of the _changes handler, allowing that code
be used not only as an HTTP API but also as an internal API. The replicator
now uses this internal API, allowing us to avoid copy-pasting code and have
all the features of _changes available to the replicator.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Request from the wiki gardener
Hey couch-devs, I identified security as an imported topic that needs some (more) attention in the wiki (there has been a bunch of new features in this area recently). Unfortunately I have only minimal knowledge of CouchDB's security concepts (and even less what feature is available in which version). Basically I would like to ask the committers for some input on that topic - texts on overview, references... Currently I'm thinking of a structure for a new Security-wiki page to have smth. like a portal for this topic where all kinds of wiki pages and related material can be referenced. The available information on the security topic seems rather scattered over the wik atm. Thoughts? // The Gardener (alias tisba) and btw: please feel free to point me to any (other) topic that needs some gardening.
Re: lazy start of couch_icu_driver
On Feb 25, 2010, at 2:07 AM, Li Zhengji wrote: I have just worked out a patch on branch 0.11.x. Awesome, if you can put it onto Jira here, we'll review it: http://issues.apache.org/jira/browse/COUCHDB Thanks, Chris On Thu, Feb 25, 2010 at 1:36 PM, Jan Lehnardt j...@apache.org wrote: Do you have a patch to add that behaviour? :) Cheers Jan -- -- Li Zhengji
Re: Releasing 0.11, Request for Comments
So really all of the patches brought up in the last few hours are good candidates for 1.0. +1
Re: Releasing 0.11, Request for Comments
+1 Cut it! On Feb 25, 2010 12:08 PM, Paul Davis paul.joseph.da...@gmail.com wrote: So really all of the patches brought up in the last few hours are good candidates for 1.0. +1
Re: Releasing 0.11, Request for Comments
Send $1 to nsla...@tumbolia.org and I will cut it. On 25 Feb 2010, at 20:13, Randall Leeds wrote: +1 Cut it! On Feb 25, 2010 12:08 PM, Paul Davis paul.joseph.da...@gmail.com wrote: So really all of the patches brought up in the last few hours are good candidates for 1.0. +1
Re: Windows 0.11 snapshot
On 26/02/2010 4:22 AM, Juhani Ränkimies wrote: Hi, There's a new variation of the file versioning scheme and I'd appreciate if you'd check it out. Binary: http://github.com/juranki/couchdb/downloads Source: http://github.com/juranki/couchdb I'm not sure exactly what you are asking me to check out. That fork has patches specific to the Windows build process? Patches not specific to windows but which you think are worthwhile anyway? Something else? Either way, a description of what you are trying to show us is probably helpful... Cheers, Mark
[jira] Commented: (COUCHDB-549) include_docs=true doesn't honour conflicts=true
[ https://issues.apache.org/jira/browse/COUCHDB-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12838614#action_12838614 ] Jens Alfke commented on COUCHDB-549: This actually goes back to 0.10.0. From some historical evidence (a unit test in the CouchObjC library that used to work but now breaks) it looks like this changed sometime after 0.8. Is this considered a bug to be fixed, or just a design limitation? include_docs=true doesn't honour conflicts=true --- Key: COUCHDB-549 URL: https://issues.apache.org/jira/browse/COUCHDB-549 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Affects Versions: 0.11 Reporter: Brian Candler Priority: Minor When you read a view and use the option 'include_docs=true' to get the source document in each result row, the option 'conflicts=true' is not honoured. You do not see a _conflicts member in the document, even if it is in a conflicting state. This feature request could be expanded in a couple of directions: 1. Make include_docs=true honour *all* options which a straightforward GET would honour - e.g. revs, revs_info, open_revs. Maybe this would be straightforward if they shared the same code path and options processing. 2. It has been suggested that 'conflicts=true' could be the default anyway. That is, whenever you retrieve a document, you get a _conflicts member if it is in a conflicting state, without having to ask for it. This would be unlikely to break things, but would make it less likely that conflicts would go unnoticed, and it would simplify the API a little. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-673) Filtered replication
[
https://issues.apache.org/jira/browse/COUCHDB-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Anderson closed COUCHDB-673.
--
Resolution: Fixed
committed in r916518
Thanks Filipe!
Filtered replication
Key: COUCHDB-673
URL: https://issues.apache.org/jira/browse/COUCHDB-673
Project: CouchDB
Issue Type: New Feature
Components: Replication
Affects Versions: 0.11
Environment: trunk / 0.11
Reporter: Filipe Manana
Attachments: filtered-replication.patch
The following patch adds support for filtered replication.
A replication object can now have 2 more optional fields: filter and
query_params.
Example:
{
source : sourceDB,
target : targetDB,
filter : mydesign/myfilter,
query_params : {
param1 : value,
param2 : int_value
// etc...
}
}
The filter must exist in the source DB, and it's the same type of filter as
used by the _changes handler. The parameter query_params is used for
adding fields to the req.query object passed as the second parameter to the
filter function (like the query string parameters passed to _changes).
The patch also does a refactoring of the _changes handler, allowing that code
be used not only as an HTTP API but also as an internal API. The replicator
now uses this internal API, allowing us to avoid copy-pasting code and have
all the features of _changes available to the replicator.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Windows 0.11 snapshot
On Fri, Feb 26, 2010 at 1:06 AM, Mark Hammond mhamm...@skippinet.com.au wrote: On 26/02/2010 4:22 AM, Juhani Ränkimies wrote: Hi, There's a new variation of the file versioning scheme and I'd appreciate if you'd check it out. Binary: http://github.com/juranki/couchdb/downloads Source: http://github.com/juranki/couchdb I'm not sure exactly what you are asking me to check out. That fork has patches specific to the Windows build process? Patches not specific to windows but which you think are worthwhile anyway? Something else? Either way, a description of what you are trying to show us is probably helpful... Cheers, Mark The branch is an experiment, trying to find a solution for the compaction and db-delete problems on windows There is one patch specific to the windows build process; for the case when path to inno setup contains spaces. http://github.com/juranki/couchdb/commit/0d5ec88f08a0519fdf9521730361c6da0c3d4cb4 -juhani
