[jira] Closed: (COUCHDB-647) Zero size DB files are created, which make CouchDB crash.
[ https://issues.apache.org/jira/browse/COUCHDB-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Anderson closed COUCHDB-647. -- Resolution: Fixed this was fixed in r959791 thanks! > Zero size DB files are created, which make CouchDB crash. > - > > Key: COUCHDB-647 > URL: https://issues.apache.org/jira/browse/COUCHDB-647 > Project: CouchDB > Issue Type: Bug >Affects Versions: 0.9.1, 0.10 > Environment: Ubuntu Hardy >Reporter: eric casteleijn >Priority: Critical > Attachments: couch_file_logging.patch > > > Our production server crashed with the following fragment in the error log > http://friendpaste.com/3VfsxGrH2XxvkqE3XQA4oy > It appears that this is due to a corrupted or zero size database file. > Chris Anderson suggested the attached patch to improve the logging in this > case. > doppler came up with a script that reproduces the crash: > touch > /Applications/CouchDBX-0.10.1-R13B03-Leopard.app/Contents/Resources/couchdbx-core/couchdb/var/lib/couchdb/test.couch > while true ; do curl -X GET http://localhost:5984/test ; done > NOTE: On the server that crashed we do not manipulate database files in any > other way than calling the REST interface, so it is still a mystery how zero > sized dbs get created. I will investigate by digging through the logs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: 1.0 Vote
On Sat, Jul 3, 2010 at 1:13 AM, Jan Lehnardt wrote: > > On 29 Jun 2010, at 16:38, Noah Slater wrote: > >> >> On 29 Jun 2010, at 15:20, J Chris Anderson wrote: >> >>> So I went through both trunk and 0.11.x looking for things that are out of >>> place. I fixed one small thing in 0.11.x, and as far as I'm concerned it is >>> ready for release. >>> >>> For trunk, I think there are a couple of small patches that Adam wants to >>> hold back for 1.1. There is also the Windows stuff, which looks like we >>> should wait for, before cutting 1.0. >> >> I am waiting for a go command, so just let me know. >> >> Please can everyone check that "make distcheck" is working for them. >> >> Let's try to avoid the test failures again for this release. > > Works for me on 0.11.x and trunk and Mac OS X 10.6.4 and Ubuntu Karmic. > > Would love to see more people sending in results here :) > > Cheers > Jan > -- > > works for me on openbsd 4.7-current (erlang R13b04), macosx 10.6.4 (erlang R13b04 & R14a) and ubuntu lucid (erlang R13b04), - benoit
Re: 1.0 Vote
Oh yeah, missed that. Added a patch to fix the problem. Thanks Juhani. -Damien On Jul 2, 2010, at 5:53 PM, Randall Leeds wrote: > I'm concerned about Juhani's comment: > > "DB deletion still failed occationally when the previous .delete file > for the db still existed. Adding a uuid to the .delete filename fixed > that." > > This seems like a smart thing to add to couch_file:delete. I don't > know how various systems deal with renaming to a file that exists. > > make distcheck succeeds for 0.11.x and trunk. > > -Randall
Re: 1.0 Vote
I'm concerned about Juhani's comment: "DB deletion still failed occationally when the previous .delete file for the db still existed. Adding a uuid to the .delete filename fixed that." This seems like a smart thing to add to couch_file:delete. I don't know how various systems deal with renaming to a file that exists. make distcheck succeeds for 0.11.x and trunk. -Randall
Re: 1.0 Vote
OS X 10.6.4 Erlang 13B04 make distcheck is fine On Jul 2, 2010, at 7:13 PM, Jan Lehnardt wrote: > > On 29 Jun 2010, at 16:38, Noah Slater wrote: > >> >> On 29 Jun 2010, at 15:20, J Chris Anderson wrote: >> >>> So I went through both trunk and 0.11.x looking for things that are out of >>> place. I fixed one small thing in 0.11.x, and as far as I'm concerned it is >>> ready for release. >>> >>> For trunk, I think there are a couple of small patches that Adam wants to >>> hold back for 1.1. There is also the Windows stuff, which looks like we >>> should wait for, before cutting 1.0. >> >> I am waiting for a go command, so just let me know. >> >> Please can everyone check that "make distcheck" is working for them. >> >> Let's try to avoid the test failures again for this release. > > Works for me on 0.11.x and trunk and Mac OS X 10.6.4 and Ubuntu Karmic. > > Would love to see more people sending in results here :) > > Cheers > Jan > -- >
Re: 1.0 Vote
On 29 Jun 2010, at 16:38, Noah Slater wrote: > > On 29 Jun 2010, at 15:20, J Chris Anderson wrote: > >> So I went through both trunk and 0.11.x looking for things that are out of >> place. I fixed one small thing in 0.11.x, and as far as I'm concerned it is >> ready for release. >> >> For trunk, I think there are a couple of small patches that Adam wants to >> hold back for 1.1. There is also the Windows stuff, which looks like we >> should wait for, before cutting 1.0. > > I am waiting for a go command, so just let me know. > > Please can everyone check that "make distcheck" is working for them. > > Let's try to avoid the test failures again for this release. Works for me on 0.11.x and trunk and Mac OS X 10.6.4 and Ubuntu Karmic. Would love to see more people sending in results here :) Cheers Jan --
[jira] Commented: (COUCHDB-720) Pull replication fails due to "401 Authentication required" while push replication works fine
[
https://issues.apache.org/jira/browse/COUCHDB-720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12884795#action_12884795
]
Jochen Kempf commented on COUCHDB-720:
--
Daniel,
I tried your configuration with a complete new server setup and indeed I do not
get couchdb errors anymore when triggering a pull replication.
However, I still cannot do pull replication when the source db has design
documents in it.
Once it hits a design document a 301 http response is returned and the
replication process just freezes.
Here is a typical log entry:
[Fri, 02 Jul 2010 20:02:28 GMT] [info] [<0.1132.0>] 201.215.36.77 - - 'GET'
/rrhh_jobs/_design%2FJob?open_revs=["2854-eee80115b5b381b4f55a44b8cdd6dafb"]&revs=true&latest=true
301
I deactivated authentication in couchdb setting...
authentication_handlers = {couch_httpd_auth, null_authentication_handler}
What else can I do to make pull replication work?
> Pull replication fails due to "401 Authentication required" while push
> replication works fine
> -
>
> Key: COUCHDB-720
> URL: https://issues.apache.org/jira/browse/COUCHDB-720
> Project: CouchDB
> Issue Type: Bug
> Components: Futon, HTTP Interface, Replication
>Affects Versions: 0.10.1, 0.11
> Environment: Remote server having Nginx reverse proxy and basic
> authentication enabled
>Reporter: Jochen Kempf
>Priority: Blocker
>
> Pull replication fails using both Futon Replicator and http request throwing
> an "401 Authentication required" error. This just happens when design
> documents are existent.
> Push replication on the other hand works fine.
> See used code here: http://gist.github.com/364072
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (COUCHDB-393) Cannot discover currently running http port if ini file specifies port 0
[ https://issues.apache.org/jira/browse/COUCHDB-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benoit Chesneau resolved COUCHDB-393. - Fix Version/s: 1.0 Resolution: Fixed committed in last trunk. > Cannot discover currently running http port if ini file specifies port 0 > > > Key: COUCHDB-393 > URL: https://issues.apache.org/jira/browse/COUCHDB-393 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface >Affects Versions: 0.9 > Environment: Ubuntu 9.04 >Reporter: Stuart Langridge >Assignee: Noah Slater >Priority: Blocker > Fix For: 0.12, 1.0 > > Attachments: couch_uri.patch, couchctl.patch > > > It is currently not possible, if the ini file specifies port 0 as the http > port (so that the OS chooses a random port) to discover which port the OS > actually chose. > It would be nice if the currently running port was made available in the > statusline output (couchdb -s), but a log statement would be adequate; some > way that an external script can discover which port a running CouchDB is > listening on. > Edited discussion from #couchdb: > aquarius: well at a glance it appears couch_http passes the 0 to > mochiweb_http which passes it to the mochiweb_socket_server, which passes it > to gen_tcp, an erlang module that lets the underlying OS assign it. > mochiweb_socket_server then grabs that port and stores it. It has a get > method to retrieve properties but that needs to be exposed to mochiweb_http > so it would take a little work to do it. It's probably a JIRA ticket, unless > someone else sees a quicker approach > bitdiddle: you got that far and didn't find it? > davisp: is there a better way to find the port? > oh, is that not the bind port? > I was just thinking a log statement > davisp: the problem is if you specify 0 as the bind port (so the > OS chooses a port), how do you find out what was chosen? > aquarius: you have to look at the port returned by the socket > aquarius: in other words, CouchDB was never written to do that > AFAIK > davisp: I found it, just needs some work to expose it > aquarius: and by do that, I mean, we never put in a statement to log > that > mochiweb_http is the module that needs to bubble it up > davisp: I don't really mind whether it's a log statement or it's > exposed to couchdb -s (the latter seems tidier to me, but whichever), I just > want to be able to start couch on port 0 and then later find out which port > got chosen :) > aquarius: for the time being you can use something like netstat or > lsof, but we'll get a log statement in there or something -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-489) Ability to set continous replication from Futon
[ https://issues.apache.org/jira/browse/COUCHDB-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Anderson closed COUCHDB-489. -- Resolution: Fixed this got fixed in the lead up to 1.0 > Ability to set continous replication from Futon > --- > > Key: COUCHDB-489 > URL: https://issues.apache.org/jira/browse/COUCHDB-489 > Project: CouchDB > Issue Type: Improvement > Components: Futon, Replication >Affects Versions: 0.12 > Environment: Mac OS 10 >Reporter: David Coallier >Priority: Minor > Fix For: 0.12 > > Attachments: COUCHDB-489.2.patch, COUCHDB-489.3.patch, > COUCHDB-489.patch, COUCHDB-489.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > This patch gives you the ability to set continous replication from Futon when > replicating to another server. There are 2 typeof(undefined) that you can see > in the code which are there to make sure that adding a new parameter to > CouchDB.replicate doesn't break legacy code and other parts of the system > that may be using it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-776) _replicator DB
[ https://issues.apache.org/jira/browse/COUCHDB-776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12884768#action_12884768 ] Chris Anderson commented on COUCHDB-776: This applies cleaning and all tests pass for me. And it looks stable. I think it will be worth waiting to apply this until after 1.0 is branched, not because I have any worries about the stability, but because I have a feeling people will be have useful feedback about some of the validation rules, and maybe other details about the API. I think it'd be healthy for the feature to sit in trunk and get some feedback before going into a release. > _replicator DB > -- > > Key: COUCHDB-776 > URL: https://issues.apache.org/jira/browse/COUCHDB-776 > Project: CouchDB > Issue Type: New Feature > Components: Replication > Environment: trunk >Reporter: Filipe Manana >Assignee: Filipe Manana > > As discussed in the mailing list thread "_replicator DB" (May) - > http://mail-archives.apache.org/mod_mbox/couchdb-dev/201005.mbox/%3caanlktilfnng9fuxuxjb5cazo6__mjaogpiw4xtuzp...@mail.gmail.com%3e > The patch follows. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Futon regression
On Jul 2, 2010, at 9:13 AM, Robert Newson wrote: > It's a bit more subtle. If you exclusively single click to edit, the > patch works. Try double-clicking one field's value first (I was > changing the documents _id value). Now you can't edit other field > values. > whoops! The goal with this was to make it possible to use Futon on mobile browsers, but I didn't realize it would effect other non-config pages. If I can't find an easy fix to avoid the regression I'll back the change out. Chris > B. > > On Fri, Jul 2, 2010 at 5:06 PM, Robert Newson wrote: >> From this commit on, it's no longer possible to edit the values of new >> fields in Futon using Firefox; >> >> git bisect ftw >> >> be39860688e01e0d0749fdbefdd226d790133219 is the first bad commit >> commit be39860688e01e0d0749fdbefdd226d790133219 >> Author: John Christopher Anderson >> Date: Thu Jul 1 21:25:48 2010 + >> >>click to edit config in Futon instead of double click. thanks Aaron Miller >> >>git-svn-id: https://svn.apache.org/repos/asf/couchdb/tr...@959788 >> 13f79535-47bb-0310-9956-ffa450edef68 >> >> :04 04 29993a9574837b7332021aeba2f02427dc892064 >> 8dc6299868dcdd68ba4833aa8708dab987b013aa M share >>
[jira] Updated: (COUCHDB-776) _replicator DB
[ https://issues.apache.org/jira/browse/COUCHDB-776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana updated COUCHDB-776: -- Attachment: (was: replicator_db.patch) > _replicator DB > -- > > Key: COUCHDB-776 > URL: https://issues.apache.org/jira/browse/COUCHDB-776 > Project: CouchDB > Issue Type: New Feature > Components: Replication > Environment: trunk >Reporter: Filipe Manana >Assignee: Filipe Manana > > As discussed in the mailing list thread "_replicator DB" (May) - > http://mail-archives.apache.org/mod_mbox/couchdb-dev/201005.mbox/%3caanlktilfnng9fuxuxjb5cazo6__mjaogpiw4xtuzp...@mail.gmail.com%3e > The patch follows. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-776) _replicator DB
[ https://issues.apache.org/jira/browse/COUCHDB-776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12884748#action_12884748 ] Filipe Manana commented on COUCHDB-776: --- Most up to date patch (for trunk) at: http://github.com/fdmanana/couchdb/compare/_replicator_db > _replicator DB > -- > > Key: COUCHDB-776 > URL: https://issues.apache.org/jira/browse/COUCHDB-776 > Project: CouchDB > Issue Type: New Feature > Components: Replication > Environment: trunk >Reporter: Filipe Manana > > As discussed in the mailing list thread "_replicator DB" (May) - > http://mail-archives.apache.org/mod_mbox/couchdb-dev/201005.mbox/%3caanlktilfnng9fuxuxjb5cazo6__mjaogpiw4xtuzp...@mail.gmail.com%3e > The patch follows. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COUCHDB-776) _replicator DB
[ https://issues.apache.org/jira/browse/COUCHDB-776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana reassigned COUCHDB-776: - Assignee: Filipe Manana > _replicator DB > -- > > Key: COUCHDB-776 > URL: https://issues.apache.org/jira/browse/COUCHDB-776 > Project: CouchDB > Issue Type: New Feature > Components: Replication > Environment: trunk >Reporter: Filipe Manana >Assignee: Filipe Manana > > As discussed in the mailing list thread "_replicator DB" (May) - > http://mail-archives.apache.org/mod_mbox/couchdb-dev/201005.mbox/%3caanlktilfnng9fuxuxjb5cazo6__mjaogpiw4xtuzp...@mail.gmail.com%3e > The patch follows. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Futon regression
It's a bit more subtle. If you exclusively single click to edit, the patch works. Try double-clicking one field's value first (I was changing the documents _id value). Now you can't edit other field values. B. On Fri, Jul 2, 2010 at 5:06 PM, Robert Newson wrote: > From this commit on, it's no longer possible to edit the values of new > fields in Futon using Firefox; > > git bisect ftw > > be39860688e01e0d0749fdbefdd226d790133219 is the first bad commit > commit be39860688e01e0d0749fdbefdd226d790133219 > Author: John Christopher Anderson > Date: Thu Jul 1 21:25:48 2010 + > > click to edit config in Futon instead of double click. thanks Aaron Miller > > git-svn-id: https://svn.apache.org/repos/asf/couchdb/tr...@959788 > 13f79535-47bb-0310-9956-ffa450edef68 > > :04 04 29993a9574837b7332021aeba2f02427dc892064 > 8dc6299868dcdd68ba4833aa8708dab987b013aa M share >
Futon regression
>From this commit on, it's no longer possible to edit the values of new fields in Futon using Firefox; git bisect ftw be39860688e01e0d0749fdbefdd226d790133219 is the first bad commit commit be39860688e01e0d0749fdbefdd226d790133219 Author: John Christopher Anderson Date: Thu Jul 1 21:25:48 2010 + click to edit config in Futon instead of double click. thanks Aaron Miller git-svn-id: https://svn.apache.org/repos/asf/couchdb/tr...@959788 13f79535-47bb-0310-9956-ffa450edef68 :04 04 29993a9574837b7332021aeba2f02427dc892064 8dc6299868dcdd68ba4833aa8708dab987b013aa M share
Re: Breaking changes since 0.11
Thanks for the heads up, I updated the wiki. Cheers Jan -- On 2 Jul 2010, at 11:06, Volker Mische wrote: > Hi, > > I just found out that _bulk_docs now needs a correct Content-Type set. I > wanted to add this information to the breaking changes wiki page, but I can't > log in atm (this has happened before). So I post it to the list, so people > hopefully not forget it :) > > If you want to use the bulk API you need to set the Content-Type to > "application/json" this behaviour was introduced in r957422. This is a > breaking change as clients now need to send special headers. > > I saw a mail from davisp where he asked why this change was made, sadly no > reply. > > Cheers, > Volker >
[jira] Commented: (COUCHDB-393) Cannot discover currently running http port if ini file specifies port 0
[
https://issues.apache.org/jira/browse/COUCHDB-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12884618#action_12884618
]
Jan Lehnardt commented on COUCHDB-393:
--
The patch looks good to me. It has a whitespace change (second hunk) that I'd
remove before committing:
diff --git a/src/couchdb/couch_server_sup.erl b/src/couchdb/couch_server_sup.erl
index 1484982..2de48d4 100644
--- a/src/couchdb/couch_server_sup.erl
+++ b/src/couchdb/couch_server_sup.erl
@@ -66,7 +66,7 @@ start_server(IniFiles) ->
[io:format(" [~s] ~s=~p~n", [Module, Variable, Value])
|| {{Module, Variable}, Value} <- couch_config:all()];
_ -> ok
-end,
+end,
And I'd use "http://~s:~w/~n"; as the format string (ending the file in a
newline).
Otherwise no objections committing this to trunk for 1.0.
> Cannot discover currently running http port if ini file specifies port 0
>
>
> Key: COUCHDB-393
> URL: https://issues.apache.org/jira/browse/COUCHDB-393
> Project: CouchDB
> Issue Type: Improvement
> Components: HTTP Interface
>Affects Versions: 0.9
> Environment: Ubuntu 9.04
>Reporter: Stuart Langridge
>Assignee: Noah Slater
>Priority: Blocker
> Fix For: 0.12
>
> Attachments: couch_uri.patch, couchctl.patch
>
>
> It is currently not possible, if the ini file specifies port 0 as the http
> port (so that the OS chooses a random port) to discover which port the OS
> actually chose.
> It would be nice if the currently running port was made available in the
> statusline output (couchdb -s), but a log statement would be adequate; some
> way that an external script can discover which port a running CouchDB is
> listening on.
> Edited discussion from #couchdb:
> aquarius: well at a glance it appears couch_http passes the 0 to
> mochiweb_http which passes it to the mochiweb_socket_server, which passes it
> to gen_tcp, an erlang module that lets the underlying OS assign it.
> mochiweb_socket_server then grabs that port and stores it. It has a get
> method to retrieve properties but that needs to be exposed to mochiweb_http
> so it would take a little work to do it. It's probably a JIRA ticket, unless
> someone else sees a quicker approach
> bitdiddle: you got that far and didn't find it?
> davisp: is there a better way to find the port?
> oh, is that not the bind port?
> I was just thinking a log statement
> davisp: the problem is if you specify 0 as the bind port (so the
> OS chooses a port), how do you find out what was chosen?
> aquarius: you have to look at the port returned by the socket
> aquarius: in other words, CouchDB was never written to do that
> AFAIK
> davisp: I found it, just needs some work to expose it
> aquarius: and by do that, I mean, we never put in a statement to log
> that
> mochiweb_http is the module that needs to bubble it up
> davisp: I don't really mind whether it's a log statement or it's
> exposed to couchdb -s (the latter seems tidier to me, but whichever), I just
> want to be able to start couch on port 0 and then later find out which port
> got chosen :)
> aquarius: for the time being you can use something like netstat or
> lsof, but we'll get a log statement in there or something
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Breaking changes since 0.11
Hi, I just found out that _bulk_docs now needs a correct Content-Type set. I wanted to add this information to the breaking changes wiki page, but I can't log in atm (this has happened before). So I post it to the list, so people hopefully not forget it :) If you want to use the bulk API you need to set the Content-Type to "application/json" this behaviour was introduced in r957422. This is a breaking change as clients now need to send special headers. I saw a mail from davisp where he asked why this change was made, sadly no reply. Cheers, Volker
