[jira] [Commented] (COUCHDB-1466) Create persistent replications via Futon
[ https://issues.apache.org/jira/browse/COUCHDB-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13255048#comment-13255048 ] Robert Newson commented on COUCHDB-1466: James, I think that's clear from all you've said. The other people speaking on the issue are talking about correcting the fundamental issue. Futon should reflect the true case underneath, so "just" fixing this in Futon would seem a confusing step, albeit one that works for many people. > Create persistent replications via Futon > > > Key: COUCHDB-1466 > URL: https://issues.apache.org/jira/browse/COUCHDB-1466 > Project: CouchDB > Issue Type: New Feature > Components: Futon >Affects Versions: 1.2 >Reporter: James Howe > > Futon's replicator page should have the option of making the task persistent > (i.e. it should add a document to _replictor rather than making the usual > POST). > Probably implemented as another checkbox next to "Continuous". -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1466) Create persistent replications via Futon
[ https://issues.apache.org/jira/browse/COUCHDB-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13254710#comment-13254710 ] Robert Newson commented on COUCHDB-1466: We're in agreement. That there are two endpoints for replication was raised as an issue at the Summit. Broad agreement to get back to one. > Create persistent replications via Futon > > > Key: COUCHDB-1466 > URL: https://issues.apache.org/jira/browse/COUCHDB-1466 > Project: CouchDB > Issue Type: New Feature > Components: Futon >Affects Versions: 1.2 >Reporter: James Howe > > Futon's replicator page should have the option of making the task persistent > (i.e. it should add a document to _replictor rather than making the usual > POST). > Probably implemented as another checkbox next to "Continuous". -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1466) Create persistent replications via Futon
[ https://issues.apache.org/jira/browse/COUCHDB-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13254673#comment-13254673 ] Robert Newson commented on COUCHDB-1466: I'm concerned that this overlaps with the existing ability to make the _replicator doc in Futon. My preference, discussed at the summit, is to change the replicator api so that you add "persistent":"true much like "continuous":true to _replicate (and _replicator disappears). With that change, this suggestion fits neatly. > Create persistent replications via Futon > > > Key: COUCHDB-1466 > URL: https://issues.apache.org/jira/browse/COUCHDB-1466 > Project: CouchDB > Issue Type: New Feature > Components: Futon >Affects Versions: 1.2 >Reporter: James Howe > > Futon's replicator page should have the option of making the task persistent > (i.e. it should add a document to _replictor rather than making the usual > POST). > Probably implemented as another checkbox next to "Continuous". -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1445) CouchDB deletes .view files if it can't open them, even if the error is "emfile".
[
https://issues.apache.org/jira/browse/COUCHDB-1445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13232375#comment-13232375
]
Robert Newson commented on COUCHDB-1445:
To summarize couchdb-dev IRC chat, we (Randall, Jan, myself) don't think
there's any error condition when opening a view file that warrants blowing the
view file away. The behaviour dates to 2008 where, perhaps, it was considered
better to automatically recover from any error in a view file by starting over.
CouchDB's view handling is well-tested now and so this pessimistic recovery
mechanism is overly aggressive.
Instead, we will log an error to the log file and throw in the code.
> CouchDB deletes .view files if it can't open them, even if the error is
> "emfile".
> -
>
> Key: COUCHDB-1445
> URL: https://issues.apache.org/jira/browse/COUCHDB-1445
> Project: CouchDB
> Issue Type: Bug
> Components: JavaScript View Server
>Affects Versions: 1.2
>Reporter: Jan Lehnardt
>Assignee: Randall Leeds
> Fix For: 1.2, 1.1.2
>
>
> Via Stefan Kögl on dev@:
> Another thing I noticed during my tests of CouchDB 1.2.x. I redirected
> live traffic to the instance and after a rather short time, requests
> were failing with the following information in the logs:
> [Sun, 18 Mar 2012 16:39:24 GMT] [error] [<0.27554.2>]
> {error_report,<0.31.0>,
>{<0.27554.2>,std_error,
> [{application,mochiweb},
> "Accept failed error",
> "{error,emfile}"]}}
> [Sun, 18 Mar 2012 16:39:24 GMT] [error] [<0.27554.2>]
> {error_report,<0.31.0>,
> {<0.27554.2>,crash_report,
> [[{initial_call,
> {mochiweb_acceptor,init,
> ['Argument__1','Argument__2',
> 'Argument__3']}},
> {pid,<0.27554.2>},
> {registered_name,[]},
> {error_info,
> {exit,
> {error,accept_failed},
> [{mochiweb_acceptor,init,3},
> {proc_lib,init_p_do_apply,3}]}},
> {ancestors,
> [couch_httpd,couch_secondary_services,
> couch_server_sup,<0.32.0>]},
> {messages,[]},
> {links,[<0.129.0>]},
> {dictionary,[]},
> {trap_exit,false},
> {status,running},
> {heap_size,233},
> {stack_size,24},
> {reductions,244}],
>[]]}}
> I think "emfile" means that CouchDB (or mochiweb?) couldn't open any
> more files / connections. I've set the (hard and soft) nofile limit for
> user couchdb to 4096, but didn't raise the ERL_MAX_PORTS accordingly.
> Anyway, as soon as the error occured, CouchDB started writing most of my
> view files from scratch, rendering the instance unusable.
> I'd expect CouchDB to fail more gracefully when the maximum number of
> open files is reached. Is this a bug or expected behaviour?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1444) missing_named_view error on existing javascript design doc and view
[
https://issues.apache.org/jira/browse/COUCHDB-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13231355#comment-13231355
]
Robert Newson commented on COUCHDB-1444:
Sam,
Can you include the logs between the 200 and the 404? Does the view ever 'come
back' or do you always restart?
I'm pretty confident that the view is not 'gone' in the strong sense (not least
because it can be regenerated from the database) but this could be a sign that
some internal state has gone wrong.
> missing_named_view error on existing javascript design doc and view
> ---
>
> Key: COUCHDB-1444
> URL: https://issues.apache.org/jira/browse/COUCHDB-1444
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Affects Versions: 1.1.1
> Environment: Ubuntu 11.01 64 bit Erlang R13B03
>Reporter: Sam Lown
>Priority: Critical
> Labels: 404, bug, missing_named_view
>
> Moved over from issue: https://issues.apache.org/jira/browse/COUCHDB-1225
> which has similar symptoms but the view is written in Erlang.
> On our production server for no apparent reason, one of our views just
> suddenly stopped responding to requests. The design document was still
> visible in Futon and the "all" view did provide a list of documents. All
> other views in the ddoc responded with a 404
> {"error":"not_found","reason":"missing_named_view"}.
> Restarting the couchdb server resolved the issue, and I've as yet been unable
> to reproduce the problem.
> Here is the last successful log entry for the view:
> [Fri, 16 Mar 2012 13:14:19 GMT] [info] [<0.831.531>] 192.168.163.3 - -
> 'GET'
> /maxi/_design/Payment/_view/by_journey_id_and_sequence?startkey=%5B%229bd1647eb09fca1634a8a6129a8cff46%22%2C%7B%7D%5D&endkey=%5B%229bd1647eb09fca1634a8a6129a8cff46%22%5D&limit=1&descending=true&include_docs=true&reduce=false
> 200
> Many requests later to other documents and views, here is when requests
> stopped working, some 6 minutes later:
> [Fri, 16 Mar 2012 13:20:29 GMT] [info] [<0.4510.531>] 192.168.163.3 - -
> 'GET'
> /maxi/_design/Payment/_view/by_user_id_and_created_at?startkey=%5B%22a0d0912e031b8fd28c2f89f828eebb12%22%5D&endkey=%5B%22a0d0912e031b8fd28c2f89f828eebb12%22%2C%7B%7D%5D&reduce=true&skip=0&limit=1
> 404
> Here is the design document in question: https://gist.github.com/2050446
> I could see nothing in the logs out of the ordinary.
> Obviously, this problem is very alarming indeed and not something I've come
> across before in CouchDB. As you can see the view in question is related to
> Payments, which is something we really do not want to go wrong.
> Please let me know if I can provide more information.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1225) missing_named_view error on existing erlang design doc and view
[
https://issues.apache.org/jira/browse/COUCHDB-1225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13231312#comment-13231312
]
Robert Newson commented on COUCHDB-1225:
Hi Sam, please file a new ticket, this one is about erlang ddocs and yours is
javascript. thanks.
> missing_named_view error on existing erlang design doc and view
> ---
>
> Key: COUCHDB-1225
> URL: https://issues.apache.org/jira/browse/COUCHDB-1225
> Project: CouchDB
> Issue Type: Bug
> Environment: Erlang 1:14.b.3
> CouchDB 1.2.0a-f7cc8fa-git
> Ubuntu Lucid 10.04 64bit
>Reporter: Alex Koshelev
>
> curl
> foo.bar:5984/cray_frame_11266/_design/admin/_view/regions_by_channel?limit=1
> {"error":"not_found","reason":"missing_named_view"}
> It worked some time ago but now there is constantly the error. If I restart
> CoucDB it will solve this issue. Updating the desing doc also solves the
> issue.
> With debug log level I get this messages:
> [Sat, 16 Jul 2011 23:40:44 GMT] [debug] [<0.898.3>] 'GET'
> /cray_frame_11266/_design/admin/_view/regions_by_channel?limit=1 {1,
>
> 1} from "93.158.159.91"
> Headers: [{'Accept',"*/*"},
> {'Host',"foo.bar:5984"},
> {'User-Agent',"curl/7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7
> OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15"}]
> [Sat, 16 Jul 2011 23:40:44 GMT] [debug] [<0.898.3>] OAuth Params:
> [{"limit","1"}]
> [Sat, 16 Jul 2011 23:40:44 GMT] [debug] [<0.898.3>] request_group {Pid, Seq}
> {<0.6419.0>,311}
> [Sat, 16 Jul 2011 23:40:44 GMT] [debug] [<0.898.3>] request_group {Pid, Seq}
> {<0.6419.0>,311}
> [Sat, 16 Jul 2011 23:40:44 GMT] [debug] [<0.898.3>] Minor error in HTTP
> request: {not_found,
> missing_named_view}
> [Sat, 16 Jul 2011 23:40:44 GMT] [debug] [<0.898.3>] Stacktrace:
> [{io_lib_pretty,cind_tag_tuple,7},
> {io_lib_pretty,while_fail,3},
> {io_lib_pretty,print,6},
> {io_lib_format,build,3},
> {io_lib_format,build,3},
> {io_lib_format,build,3},
> {io_lib_format,build,3},
> {io_lib_format,build,3}]
> [Sat, 16 Jul 2011 23:40:44 GMT] [info] [<0.898.3>] 0.0.0.0 - - GET
> /cray_frame_11266/_design/admin/_view/regions_by_channel?limit=1 404
> [Sat, 16 Jul 2011 23:40:44 GMT] [debug] [<0.898.3>] httpd 404 error response:
> {"error":"not_found","reason":"missing_named_view"}
> I've also tried to get _info about design doc and found that it have had zero
> data_size:
> > curl foo.bar:5984/cray_frame_11266/_design/admin/_info | python -mjson.tool
> {
> "name": "admin",
> "view_index": {
> "compact_running": false,
> "data_size": 0,
> "disk_size": 90241,
> "language": "erlang",
> "purge_seq": 0,
> "signature": "09b8b599cad584406b7aa5956b98a335",
> "update_seq": 311,
> "updater_running": false,
> "waiting_clients": 0,
> "waiting_commit": false
> }
> }
> In the same time another similar design doc works fine and has some data_size:
> > curl foo.bar:5984/cray_frame_11266/_design/web/_info | python -mjson.tool
> {
> "name": "web",
> "view_index": {
> "compact_running": false,
> "data_size": 7462075,
> "disk_size": 9138406,
> "language": "erlang",
> "purge_seq": 0,
> "signature": "7f01f0c843b3bbb79d00ec4ff8d43010",
> "update_seq": 311,
> "updater_running": false,
> "waiting_clients": 0,
> "waiting_commit": false
> }
> }
> Over the year ago Mark Anderson has asked similar questing in the thread
> called "Need help diagnosing couchdb view 404s" [1] but seams did not found
> any answer than.
> [1]: http://comments.gmane.org/gmane.comp.db.couchdb.user/8994
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1436) Sometimes a newly created document does not appear in the database although operation for its creating returns "ok"=true
[ https://issues.apache.org/jira/browse/COUCHDB-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13226170#comment-13226170 ] Robert Newson commented on COUCHDB-1436: Do you have any more details than this? A trace of a curl session would be useful. As it stands, this report is unactionable. > Sometimes a newly created document does not appear in the database although > operation for its creating returns "ok"=true > > > Key: COUCHDB-1436 > URL: https://issues.apache.org/jira/browse/COUCHDB-1436 > Project: CouchDB > Issue Type: Bug > Components: Database Core >Affects Versions: 1.1 >Reporter: Oleg Rostanin > > Sometimes after creating a document via http request a newly created document > does not apper in the db (both in Web gui and when requested through API) > althougho the response of the creation request returned ok=true, -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1424) make check hangs when compiling with R15B
[ https://issues.apache.org/jira/browse/COUCHDB-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13217292#comment-13217292 ] Robert Newson commented on COUCHDB-1424: I ran make check on Ubuntu 11.10, 5 time in a row. It never hung, though the auth cache test failed on runs 3-5 inclusive. > make check hangs when compiling with R15B > - > > Key: COUCHDB-1424 > URL: https://issues.apache.org/jira/browse/COUCHDB-1424 > Project: CouchDB > Issue Type: Bug > Components: Test Suite >Affects Versions: 1.2, 1.3 >Reporter: Jan Lehnardt > > make check hangs when running under R15B. For me it is 160-vhosts.t where > execution stops, but if I recall correctly others have reported other tests. > The crux here is that running the tests individually succeeds. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1424) make check hangs when compiling with R15B
[ https://issues.apache.org/jira/browse/COUCHDB-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13217191#comment-13217191 ] Robert Newson commented on COUCHDB-1424: hangs for me too, the last thing printed is the 075-auth-cache.t line. > make check hangs when compiling with R15B > - > > Key: COUCHDB-1424 > URL: https://issues.apache.org/jira/browse/COUCHDB-1424 > Project: CouchDB > Issue Type: Bug > Components: Test Suite >Affects Versions: 1.2, 1.3 >Reporter: Jan Lehnardt > > make check hangs when running under R15B. For me it is 160-vhosts.t where > execution stops, but if I recall correctly others have reported other tests. > The crux here is that running the tests individually succeeds. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1186) Speedups in the view indexer
[
https://issues.apache.org/jira/browse/COUCHDB-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13216720#comment-13216720
]
Robert Newson commented on COUCHDB-1186:
Filipe,
Part of this patch is implicated in a significant reduction of view indexing
performance. Several devs are testing and confirming this result right now but,
if confirmed, I consider it a release blocking issue.
> Speedups in the view indexer
>
>
> Key: COUCHDB-1186
> URL: https://issues.apache.org/jira/browse/COUCHDB-1186
> Project: CouchDB
> Issue Type: Improvement
>Reporter: Filipe Manana
>Assignee: Filipe Manana
> Fix For: 1.2
>
>
> The patches at [1] and [2] do 2 distinct optimizations to the view indexer
> 1) Use a NIF to implement couch_view:less_json/2;
> 2) Multiple small optimizations to couch_view_updater - the main one is to
> decode the view server's JSON only in the updater's write process, avoiding 2
> EJSON term copying phases (couch_os_process -> updater processes and writes
> work queue)
> [1] -
> https://github.com/fdmanana/couchdb/commit/3935a4a991abc32132c078e908dbc11925605602
> [2] -
> https://github.com/fdmanana/couchdb/commit/cce325378723c863f05cca2192ac7bd58eedde1c
> Using these 2 patches, I've seen significant improvements to view generation
> time. Here I present as example the databases at:
> A) http://fdmanana.couchone.com/indexer_test_2
> B) http://fdmanana.couchone.com/indexer_test_3
> ## Trunk
> ### database A
> $ time curl
> http://localhost:5985/indexer_test_2/_design/test/_view/view1?limit=1
> {"total_rows":1102400,"offset":0,"rows":[
>
> {"id":"00d49881-7bcf-4c3d-a65d-e44435eeb513","key":["dwarf","assassin",2,1.1],"value":[{"x":174347.18,"y":127272.8},{"x":35179.93,"y":41550.55},{"x":157014.38,"y":172052.63},{"x":116185.83,"y":69871
>.73},{"x":153746.28,"y":190006.59}]}
> ]}
> real 19m46.007s
> user 0m0.024s
> sys 0m0.020s
> ### Database B
> $ time curl
> http://localhost:5985/indexer_test_3/_design/test/_view/view1?limit=1
> {"total_rows":1102400,"offset":0,"rows":[
>
> {"id":"00d49881-7bcf-4c3d-a65d-e44435eeb513","key":["dwarf","assassin",2,1.1],"value":[{"x":174347.18,"y":127272.8},{"x":35179.93,"y":41550.55},{"x":157014.38,"y":172052.63},{"x":116185.83,"y":69871
>.73},{"x":153746.28,"y":190006.59}]}
> ]}
> real 21m41.958s
> user 0m0.004s
> sys 0m0.028s
> ## Trunk + the 2 patches
> ### Database A
> $ time curl
> http://localhost:5984/indexer_test_2/_design/test/_view/view1?limit=1
> {"total_rows":1102400,"offset":0,"rows":[
>
> {"id":"00d49881-7bcf-4c3d-a65d-e44435eeb513","key":["dwarf","assassin",2,1.1],"value":[{"x":174347.18,"y":127272.8},{"x":35179.93,"y":41550.55},{"x":157014.38,"y":172052.63},{"x":116185.83,"y":69871.7
> 3},{"x":153746.28,"y":190006.59}]}
> ]}
> real16m1.820s
> user0m0.000s
> sys 0m0.028s
> (versus 19m46 with trunk)
> ### Database B
> $ time curl
> http://localhost:5984/indexer_test_3/_design/test/_view/view1?limit=1
> {"total_rows":1102400,"offset":0,"rows":[
>
> {"id":"00d49881-7bcf-4c3d-a65d-e44435eeb513","key":["dwarf","assassin",2,1.1],"value":[{"x":174347.18,"y":127272.8},{"x":35179.93,"y":41550.55},{"x":157014.38,"y":172052.63},{"x":116185.83,"y":69871.7
> 3},{"x":153746.28,"y":190006.59}]}
> ]}
> real17m22.778s
> user0m0.020s
> sys 0m0.016s
> (versus 21m41s with trunk)
> Repeating these tests, always clearing my OS/fs cache before running them
> (via `echo 3 > /proc/sys/vm/drop_caches`), I always get about the same
> relative differences.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-tabpanel&focusedCommentId=13215576#comment-13215576
]
Robert Newson commented on COUCHDB-523:
---
also +1 on the array/order preserving API and -1 on the object thing, just to
get things moving.
> 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
> Fix For: 1.3
>
> 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1420) Futon display breaks on really long db name
[
https://issues.apache.org/jira/browse/COUCHDB-1420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13214923#comment-13214923
]
Robert Newson commented on COUCHDB-1420:
We should reject dbnames over 256 characters as the database will be stored in
a file of that name and many filesystems have a 256 char limit. {error,
etoolongfilename} is somesuch.
> Futon display breaks on really long db name
> ---
>
> Key: COUCHDB-1420
> URL: https://issues.apache.org/jira/browse/COUCHDB-1420
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core, Futon
>Affects Versions: 1.2
>Reporter: Sam Bisbee
>Priority: Minor
>
> Futon's display breaks if the database name is too long and some information
> is just not retrieved.
> Example database name:
> bpjwguulsnozjugktpmtnsucxlojprxyhbmuxkyuqepaptmjvwctautgpiawxiodsqkdrposfrdayauvzkgixkztdaamhhihifdvdqykpqacpmifosdouzlqwxkbooxnebxohdueppgpawfsetsayrzeigevclmnplfewskbzepwqkrpuvsqeqkdnmkgxwrsmdqmgcqkhfkgtnfmcompyugwmymaoguzxwfjn
> Marking minor since people who want db names this long/crazy are (a) a
> minority and (b) should be accepting of minor UI issues.
> Cheers.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1407) JSON encoding of number changes
[
https://issues.apache.org/jira/browse/COUCHDB-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213732#comment-13213732
]
Robert Newson commented on COUCHDB-1407:
Inclined to agree with the general trend that we don't "fix" this. 1.0 and 1
are the same value, libraries that ignore the consequences of JSON's definition
of number are broken and should be fixed.
I'd like to resolve as "Won't Fix" and updated BREAKING CHANGES for 1.2.0 to
reflect this decision.
> JSON encoding of number changes
> ---
>
> Key: COUCHDB-1407
> URL: https://issues.apache.org/jira/browse/COUCHDB-1407
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
>Affects Versions: 1.2
> Environment: Ubuntu 12.04 (alpha)
>Reporter: Adam Lofts
> Attachments: 0001-Only-validate-numbers-on-JSON-decoding.patch
>
>
> JSON encoding of Number has changed from 1.0.2 to 1.2. JSON only defines
> Number but this change causes issues in my app because python decodes the
> number as an int in 1.2.
> Test case:
> PORT=5985
> curl -X DELETE http://localhost:$PORT/test-floats/
> curl -X PUT http://localhost:$PORT/test-floats/
> curl -X PUT http://localhost:$PORT/test-floats/doc1 -H "Content-Type:
> application/json" -d "{ \"a\": 1.0 }"
> curl http://localhost:$PORT/test-floats/doc1
> Run against 1.0.2:
> {"ok":true}
> {"ok":true}
> {"ok":true,"id":"doc1","rev":"1-78e61304147429d3d500aee7806fd26d"}
> {"_id":"doc1","_rev":"1-78e61304147429d3d500aee7806fd26d","a":1.0}
> Run against 1.2:
> {"ok":true}
> {"ok":true}
> {"ok":true,"id":"doc1","rev":"1-78e61304147429d3d500aee7806fd26d"}
> {"_id":"doc1","_rev":"1-78e61304147429d3d500aee7806fd26d","a":1}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-665) Replication not possible via IPv6
[
https://issues.apache.org/jira/browse/COUCHDB-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13212495#comment-13212495
]
Robert Newson commented on COUCHDB-665:
---
I've successfully replicated a db using a remote source and target for an ipv6
couchdb. Here are my steps.
1) added this to local_dev.ini;
[httpd]
bind_address = ::1
2) Created a 'db1' and 'db2' database and added a doc to 'db1'.
3) Performed replication;
curl localhost:5984/_replicate -Hcontent-type:application/json -d
'{"source":"http://[::1]:5984/db1","target":"http://[::1]:5984/db2"}'
4) Replication succeeded, 'db2' has one document.
Bastiaan, can you please respond to Filipe's request for more information? This
would be a release blocking ticket if it can be confirmed (and assuming my
result doesn't invalidate the ticket).
> Replication not possible via IPv6
> --
>
> Key: COUCHDB-665
> URL: https://issues.apache.org/jira/browse/COUCHDB-665
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
>Affects Versions: 0.10.1
> Environment: Linux x200 2.6.32-2 #2 SMP Wed Feb 17 01:00:03 CET 2010
> x86_64 GNU/Linux
>Reporter: Michael Stapelberg
>Assignee: Filipe Manana
>Priority: Blocker
> Labels: ipv6
> Fix For: 1.1, 1.0.3, 1.2
>
> Attachments: COUCHDB-665-replication-ipv6.patch, couchdb-ipv6.patch,
> patch
>
> Original Estimate: 0.25h
> Remaining Estimate: 0.25h
>
> I have a host which is only reachable via IPv6. While I can connect to a
> CouchDB running on this host just fine, I cannot replicate my database to it.
> This is due to the inet6-option missing from the gen_tcp.connect() call. I
> will attach a patch which fixes the issue.
> To test it, you can use a host which only has an record in the DNS.
> CouchDB will immediately return 404 if you want to replicate to it unless you
> add the inet6 option.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1410) Formally define number support
[ https://issues.apache.org/jira/browse/COUCHDB-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13208478#comment-13208478 ] Robert Newson commented on COUCHDB-1410: I appreciate that the format is fully defined. Perhaps what I mean, instead, is the precision with which those numbers can be manipulated in view servers? I've certainly been stung by some crazy number rounding issues in the past, I don't think it's reasonable behavior for a database. It sounds like this ticket is really two issues, 1) numbers can roundtrip safely to and from JSON, 2) numbers can be computed with within known (and consistent) bounds. Issue 1 is something we need to resolve in ejson for the 1.2.0 release but sounds simple. To fulfill this ticket, we have to commit to not breaking roundtrip safety in future versions. Issue 2, I suspect, is contentious. Or, at least, I suspect I desire stronger numeric handling than javascript typically delivers. I'll be happy here if we document, and preserve, some minimal standard. /ramble > Formally define number support > -- > > Key: COUCHDB-1410 > URL: https://issues.apache.org/jira/browse/COUCHDB-1410 > Project: CouchDB > Issue Type: Improvement >Affects Versions: 1.2 >Reporter: Robert Newson >Priority: Blocker > Fix For: 1.3 > > > The JSON spec has a very loose definition of Number. CouchDB, as a database, > should have well-defined and first class support for numbers (both integral > and decimal). The precision of number support should be formally specified as > should the algorithm used to represent floating-point values, especially > where an approximation must be made in the conversion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1410) Formally define number support
[ https://issues.apache.org/jira/browse/COUCHDB-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13207806#comment-13207806 ] Robert Newson commented on COUCHDB-1410: If all that needs to happen to resolve this ticket is to include what you just said in the documentation (and maybe some tests that prove it is, and remains, true), I'll be quite happy. > Formally define number support > -- > > Key: COUCHDB-1410 > URL: https://issues.apache.org/jira/browse/COUCHDB-1410 > Project: CouchDB > Issue Type: Improvement >Affects Versions: 1.2 >Reporter: Robert Newson >Priority: Blocker > Fix For: 1.3 > > > The JSON spec has a very loose definition of Number. CouchDB, as a database, > should have well-defined and first class support for numbers (both integral > and decimal). The precision of number support should be formally specified as > should the algorithm used to represent floating-point values, especially > where an approximation must be made in the conversion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1409) Look into manual GC
[ https://issues.apache.org/jira/browse/COUCHDB-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13207653#comment-13207653 ] Robert Newson commented on COUCHDB-1409: A further note that Cloudant have some operational experience (and deployed remedies) for this issue. A quick look indicates at least some of these made it into bigcouch already. > Look into manual GC > --- > > Key: COUCHDB-1409 > URL: https://issues.apache.org/jira/browse/COUCHDB-1409 > Project: CouchDB > Issue Type: Improvement >Reporter: Jan Lehnardt > > This just as a reminder to consider > http://andy.wordpress.com/2012/02/13/erlang-is-a-hoarder/ (incl. comments) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1407) JSON encoding of number changes
[
https://issues.apache.org/jira/browse/COUCHDB-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206212#comment-13206212
]
Robert Newson commented on COUCHDB-1407:
Parity is restored as easily as;
diff --git a/src/ejson/encode.c b/src/ejson/encode.c
index 916a0b7..134ffca 100644
--- a/src/ejson/encode.c
+++ b/src/ejson/encode.c
@@ -146,7 +146,7 @@ final_encode(ErlNifEnv* env, int argc, const ERL_NIF_TERM
argv[])
}
// write the string into the buffer
snprintf((char*)ctx.bin.data+ctx.fill_offset, 32,
-"%.16g", number);
+"%.16f", number);
// increment the length
ctx.fill_offset += strlen((char*)ctx.bin.data+ctx.fill_offset);
}
The obvious downside is that, by not taking the shorter of the %e and %f
formats, numbers will be less concisely persisted.
> JSON encoding of number changes
> ---
>
> Key: COUCHDB-1407
> URL: https://issues.apache.org/jira/browse/COUCHDB-1407
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
>Affects Versions: 1.2
> Environment: Ubuntu 12.04 (alpha)
>Reporter: Adam Lofts
>
> JSON encoding of Number has changed from 1.0.2 to 1.2. JSON only defines
> Number but this change causes issues in my app because python decodes the
> number as an int in 1.2.
> Test case:
> PORT=5985
> curl -X DELETE http://localhost:$PORT/test-floats/
> curl -X PUT http://localhost:$PORT/test-floats/
> curl -X PUT http://localhost:$PORT/test-floats/doc1 -H "Content-Type:
> application/json" -d "{ \"a\": 1.0 }"
> curl http://localhost:$PORT/test-floats/doc1
> Run against 1.0.2:
> {"ok":true}
> {"ok":true}
> {"ok":true,"id":"doc1","rev":"1-78e61304147429d3d500aee7806fd26d"}
> {"_id":"doc1","_rev":"1-78e61304147429d3d500aee7806fd26d","a":1.0}
> Run against 1.2:
> {"ok":true}
> {"ok":true}
> {"ok":true,"id":"doc1","rev":"1-78e61304147429d3d500aee7806fd26d"}
> {"_id":"doc1","_rev":"1-78e61304147429d3d500aee7806fd26d","a":1}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1407) JSON encoding of number changes
[
https://issues.apache.org/jira/browse/COUCHDB-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206184#comment-13206184
]
Robert Newson commented on COUCHDB-1407:
For my part, I fully accept the notion that we've adhered to the JSON semantics
for numbers. However, I think we all recognize that the JSON semantics for
numbers are rubbish.
At the very least, as I noted on the 1.2.0 voting thread, this should be
recorded in 'BREAKING CHANGES' but I think we ought to fix it. I will devote
some cycles to that end.
> JSON encoding of number changes
> ---
>
> Key: COUCHDB-1407
> URL: https://issues.apache.org/jira/browse/COUCHDB-1407
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
>Affects Versions: 1.2
> Environment: Ubuntu 12.04 (alpha)
>Reporter: Adam Lofts
>
> JSON encoding of Number has changed from 1.0.2 to 1.2. JSON only defines
> Number but this change causes issues in my app because python decodes the
> number as an int in 1.2.
> Test case:
> PORT=5985
> curl -X DELETE http://localhost:$PORT/test-floats/
> curl -X PUT http://localhost:$PORT/test-floats/
> curl -X PUT http://localhost:$PORT/test-floats/doc1 -H "Content-Type:
> application/json" -d "{ \"a\": 1.0 }"
> curl http://localhost:$PORT/test-floats/doc1
> Run against 1.0.2:
> {"ok":true}
> {"ok":true}
> {"ok":true,"id":"doc1","rev":"1-78e61304147429d3d500aee7806fd26d"}
> {"_id":"doc1","_rev":"1-78e61304147429d3d500aee7806fd26d","a":1.0}
> Run against 1.2:
> {"ok":true}
> {"ok":true}
> {"ok":true,"id":"doc1","rev":"1-78e61304147429d3d500aee7806fd26d"}
> {"_id":"doc1","_rev":"1-78e61304147429d3d500aee7806fd26d","a":1}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1405) error generating document id with utc_random
[ https://issues.apache.org/jira/browse/COUCHDB-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13204450#comment-13204450 ] Robert Newson commented on COUCHDB-1405: I know, from bitter experience, that timekeeping in some hypervisors is pretty lousy. Specifically, I've experienced every kind of clock-goes-wrong event inside VMWare guests. I doubt that erlang:now()'s behavior of never returning the same value twice is at fault here (it's certainly *not* just returning the CMOS value but the difference should be negligible). I'd further argue that attempting to get an absolute guarantee of consistent time across a cluster is doomed to failure. You can get very close but unless you're prepared to synchronously consult a single external time authority every time (and to fail when it's unavailable) there will be mistakes. The only alternative I've found is to implement a fault-tolerant consensus mechanism (oh, it's that easy, huh?). The better solution is to not require this kind of synchronization in the first place. In non-virtual situations, NTP is your friend. In virtual situations, NTP is your enemy. Your virtual host should be configured to set the time in all guests and the guests should generally *not* use NTP. Since the guests are not necessarily getting every clock cycle they believe they are, the NTP auto correction algorithms can get confused, ironically making things worse, not better. > error generating document id with utc_random > > > Key: COUCHDB-1405 > URL: https://issues.apache.org/jira/browse/COUCHDB-1405 > Project: CouchDB > Issue Type: Bug > Components: Database Core >Affects Versions: 1.1.1 > Environment: Windows 7, 64-bit, running as virtual pc in hyper-v >Reporter: André Bögge > Labels: Hyper-V > > I use the utc_random algorithm for generating document ids. So it's possible > for me to calculate time and date out of the id in my client application. > After running CouchDB for about a month i got a difference between system > time and calculated time of id of about half an hour. I restarted the > database and even then i got a difference about 1 minute. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1400) Critical crash of Futon after misconfigured bind_address
[ https://issues.apache.org/jira/browse/COUCHDB-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13200082#comment-13200082 ] Robert Newson commented on COUCHDB-1400: the bind_address is only stored in the .ini files, it doesn't come from anywhere else. Therefore I think it's more likely that you haven't reset your .ini files correctly. If couchdb is currently running, you can use netstat to see if it's bound to any interface. You can also tweak bind_address over http, assuming couch is bound to at least one interface. If it's bound to zero interfaces, then there's not much we can do about it. Again, we can more easily assist with this support question on a support channel rather than our bug tracker. > Critical crash of Futon after misconfigured bind_address > > > Key: COUCHDB-1400 > URL: https://issues.apache.org/jira/browse/COUCHDB-1400 > Project: CouchDB > Issue Type: Bug > Components: Futon >Affects Versions: 0.11.2 > Environment: CentOS 5.5 (64-bit) >Reporter: Tim > Labels: Futon,, crash > Attachments: screenshot-1.jpg > > > Bug1: Unable to reflect bind_address in local.ini > Bug2: Unable to revert changes doing clean install > Bug3: Can only change bind_address in Futon > I made a mistake to change the configuration table's httpd/bind_address > parameter to my domain, the domain that looks like www.google.com etc. That > was supposed to be left at 0.0.0.0 or 127.0.0.1. I remember making this > mistake long time ago but now basically I can't access anything from either > localhost and external. > Please check screenshot to see what it looks like when I try to access Futon > after misconfiguration. > I am unable to reverse my setting because working with > /etc/couchdb/default.ini or local.ini never affected this in the first place > (spent 2 hours trying to modify these fails in order to get external access > of couchDB). > So Futon must have changed something when I set it. When I change the value, > it stuck at the error: Some of the changes require database restart. Since > then, I can never access my couchDB. > I tried to yum remove erlang, yum remove couchdb several times. Checked to > see if any default.ini or local.ini remains, restart system, log out users, > but none of above works. > Please help me with this problem as soon as possible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1400) Critical crash of Futon after misconfigured bind_address
[ https://issues.apache.org/jira/browse/COUCHDB-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13200047#comment-13200047 ] Robert Newson commented on COUCHDB-1400: Hi, You should stop couchdb (and verify that the process is not running), then fix local.ini (restore 0.0.0.0 for bind_address) and then start it up again. I suggest hopping on our IRC channel #couchdb on irc.freenode.net or the user@ mailing list. JIRA is for bug reports, not support. B. > Critical crash of Futon after misconfigured bind_address > > > Key: COUCHDB-1400 > URL: https://issues.apache.org/jira/browse/COUCHDB-1400 > Project: CouchDB > Issue Type: Bug > Components: Futon >Affects Versions: 0.11.2 > Environment: CentOS 5.5 (64-bit) >Reporter: Tim > Labels: Futon,, crash > Attachments: screenshot-1.jpg > > > I made a mistake to change the configuration table's httpd/bind_address > parameter to my domain, the domain that looks like www.google.com etc. That > was supposed to be left at 0.0.0.0 or 127.0.0.1. I remember making this > mistake long time ago but now basically I can't access anything from either > localhost and external. > Please check screenshot to see what it looks like when I try to access Futon > after misconfiguration. > I am unable to reverse my setting because working with > /etc/couchdb/default.ini or local.ini never affected this in the first place > (spent 2 hours trying to modify these fails in order to get external access > of couchDB). > So Futon must have changed something when I set it. When I change the value, > it stuck at the error: Some of the changes require database restart. Since > then, I can never access my couchDB. > I tried to yum remove erlang, yum remove couchdb several times. Checked to > see if any default.ini or local.ini remains, restart system, log out users, > but none of above works. > Please help me with this problem as soon as possible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1073) DELETE _session doesn't delete the session. Client can still get user information using GET _session and with the session cookie retrieved.
[ https://issues.apache.org/jira/browse/COUCHDB-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13199718#comment-13199718 ] Robert Newson commented on COUCHDB-1073: DELETE _session returns a response that clears the clients AuthSession cookie. > DELETE _session doesn't delete the session. Client can still get user > information using GET _session and with the session cookie retrieved. > --- > > Key: COUCHDB-1073 > URL: https://issues.apache.org/jira/browse/COUCHDB-1073 > Project: CouchDB > Issue Type: Improvement >Reporter: Johnny Weng Luu > > When using DELETE _session CouchDB only sends a empty session cookie back. > But if I use the original session cookie when using GET _session I can still > get the user information. > https://gist.github.com/838996 > This could be a security flaw because when the user leaves the computer a > hacker can check out the session cookie and log in to account. > Very bad if it's a very sensitive web application like financial. > Isn't it better to just delete the session internally in couchdb when DELETE > _session is used. Then that session cookie the hacker gets won't matter > because the session is already gone. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-769) Store large attachments external to the .couch file
[ https://issues.apache.org/jira/browse/COUCHDB-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197949#comment-13197949 ] Robert Newson commented on COUCHDB-769: --- quick note that we can't use 417 as that's only legal in response to the inability to fulfill a request with an Expect header. I think 404 is the correct code but it does expose the loss of atomicity when using external attachments. > Store large attachments external to the .couch file > --- > > Key: COUCHDB-769 > URL: https://issues.apache.org/jira/browse/COUCHDB-769 > Project: CouchDB > Issue Type: New Feature > Components: Database Core >Reporter: Robert Newson > Attachments: external_attachments_alpha.patch > > > For attachment-heavy applications storing the attachments in separate files > significantly eases compaction problems. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1395) Not well-formed JSON in changes feed filtered by view.
[
https://issues.apache.org/jira/browse/COUCHDB-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13194216#comment-13194216
]
Robert Newson commented on COUCHDB-1395:
+1 on porting the delayed response work to couchdb.
> Not well-formed JSON in changes feed filtered by view.
> --
>
> Key: COUCHDB-1395
> URL: https://issues.apache.org/jira/browse/COUCHDB-1395
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 1.2, 1.3
> Environment: Apache CouchDB 1.3.0a-d59cdd7-git
> Apache CouchDB 1.2.0a-0d8ddc8-git
>Reporter: Alexander Shorin
>Priority: Critical
> Attachments: filtered_view_bug.sh
>
>
> CouchDB returns invalid JSON response for _changes feed if filter view have
> failed somehow: by code mistake, bug, os timeout etc.
> Steps to reproduce:
> 1. Create db and fill it with some documents.
> 2. Create buggy view that would make view server crush for some document. For
> javascript one segfault and os timeout errors are actual due to any
> exceptions raised from map function is silenced. You view could be fine
> however for normal usage.
> 3. Request changes feed and apply this buggy view as filter.
> Story:
> View function had never proceed design documents and mostly they are created
> with that knowledge. But in changes feed they have to process every document
> in database and DDocs too, so they breaks their original logic and creates
> unexpectable situation. Another side of problem is about custom query servers
> that could prevent view processing on first occurred exception or due dynamic
> code execution nature.
> Certainly, it's all about invalid view function that generates exception for
> some document in some case, but should _changes feed return malformed data in
> this case or just notify about problem somehow and emit valid parseable JSON?
> Expected result:
> Valid JSON response and some message about document processing error.
> Actual result:
> * About to connect() to localhost port 5984 (#0)
> * Trying 127.0.0.1... connected
> * Connected to localhost (127.0.0.1) port 5984 (#0)
> > GET /filtered_view_bug/_changes?filter=_view&view=bug/crush_on_ddoc HTTP/1.1
> > User-Agent: curl/7.21.4 (x86_64-pc-linux-gnu) libcurl/7.21.4 GnuTLS/2.10.5
> > zlib/1.2.5
> > Host: localhost:5984
> > Accept: application/json
> >
> < HTTP/1.1 200 OK
> < Transfer-Encoding: chunked
> < Server: CouchDB/1.3.0a-d59cdd7-git (Erlang OTP/R14B04)
> < ETag: "3IV66Q7INUYEHYKVWADD0CA8A"
> < Date: Thu, 26 Jan 2012 19:30:23 GMT
> < Content-Type: application/json
> < Cache-Control: must-revalidate
> <
> {"results":[
> {"seq":1,"id":"foo","changes":[{"rev":"1-5277061607e266deb7cc87eb63354db7"}]},
> {"seq":2,"id":"bar","changes":[{"rev":"1-ced1ed0168f00311e1ee301cda904840"}]},
> {"seq":3,"id":"baz","changes":[{"rev":"1-ae16db0d925a8295009ff580e226a978"}]}
> * Received problem 2 in the chunky parser
> * Closing connection #0
> curl: (56) Received problem 2 in the chunky parser
> Last chunk arrives with "HTTP/1.1 500 Internal Server Error" instead of size
> value.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1388) Support Windows Phone 7
[ https://issues.apache.org/jira/browse/COUCHDB-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191669#comment-13191669 ] Robert Newson commented on COUCHDB-1388: And please do not assign "Fix version" in tickets. > Support Windows Phone 7 > --- > > Key: COUCHDB-1388 > URL: https://issues.apache.org/jira/browse/COUCHDB-1388 > Project: CouchDB > Issue Type: Improvement > Components: Database Core >Affects Versions: 1.1.2 > Environment: Windows Phone 7 >Reporter: Chang Luo > Labels: windows-phone, wp7 > > Now that we have support for iOS and Android, I am looking forward to Windows > Phone 7. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1304) set Expires header on session cookies to make them persistent
[ https://issues.apache.org/jira/browse/COUCHDB-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189773#comment-13189773 ] Robert Newson commented on COUCHDB-1304: Let's keep it disabled by default then, it's an easy thing to switch on. A further question of whether the toggle should be finer-grained than per-server has been raised by Randall. I think it's a good question but should be on a new ticket if we intend to pursue it. > set Expires header on session cookies to make them persistent > - > > Key: COUCHDB-1304 > URL: https://issues.apache.org/jira/browse/COUCHDB-1304 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface >Affects Versions: 1.1 >Reporter: max ogden >Assignee: Robert Newson >Priority: Minor > Labels: authentication, cookie > Fix For: 1.2 > > Original Estimate: 1h > Remaining Estimate: 1h > > currently couch's cookie based authentication only sets session cookies as > opposed to persistent cookies. the difference between these two is the > Expires header. if it is not present most web browsers will delete your > cookie when you quit your browser, whereas if it is set then your browser > keeps the cookie around until the time specified by the Expires header. > This sucks for UX because users quit and re-launch their browser they'll have > to log in again. > I am proposing that we set the Expires header in cookies to match the time in > the couch_httpd_auth timeout > p.s. this is similar to the issue I opened > https://issues.apache.org/jira/browse/COUCHDB-1095 but at that time I didn't > realize that what I really wanted was the Expires header -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1304) set Expires header on session cookies to make them persistent
[ https://issues.apache.org/jira/browse/COUCHDB-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189753#comment-13189753 ] Robert Newson commented on COUCHDB-1304: Enabling by default works for me, can I get some votes? > set Expires header on session cookies to make them persistent > - > > Key: COUCHDB-1304 > URL: https://issues.apache.org/jira/browse/COUCHDB-1304 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface >Affects Versions: 1.1 >Reporter: max ogden >Assignee: Robert Newson >Priority: Minor > Labels: authentication, cookie > Fix For: 1.2 > > Original Estimate: 1h > Remaining Estimate: 1h > > currently couch's cookie based authentication only sets session cookies as > opposed to persistent cookies. the difference between these two is the > Expires header. if it is not present most web browsers will delete your > cookie when you quit your browser, whereas if it is set then your browser > keeps the cookie around until the time specified by the Expires header. > This sucks for UX because users quit and re-launch their browser they'll have > to log in again. > I am proposing that we set the Expires header in cookies to match the time in > the couch_httpd_auth timeout > p.s. this is similar to the issue I opened > https://issues.apache.org/jira/browse/COUCHDB-1095 but at that time I didn't > realize that what I really wanted was the Expires header -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1304) set Expires header on session cookies to make them persistent
[ https://issues.apache.org/jira/browse/COUCHDB-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189105#comment-13189105 ] Robert Newson commented on COUCHDB-1304: Here code here: http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commitdiff;h=b5c3f72018d462638a56fe05b2d377b05324c61d > set Expires header on session cookies to make them persistent > - > > Key: COUCHDB-1304 > URL: https://issues.apache.org/jira/browse/COUCHDB-1304 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface >Affects Versions: 1.1 >Reporter: max ogden >Assignee: Robert Newson >Priority: Minor > Labels: authentication, cookie > Fix For: 1.3 > > Original Estimate: 1h > Remaining Estimate: 1h > > currently couch's cookie based authentication only sets session cookies as > opposed to persistent cookies. the difference between these two is the > Expires header. if it is not present most web browsers will delete your > cookie when you quit your browser, whereas if it is set then your browser > keeps the cookie around until the time specified by the Expires header. > This sucks for UX because users quit and re-launch their browser they'll have > to log in again. > I am proposing that we set the Expires header in cookies to match the time in > the couch_httpd_auth timeout > p.s. this is similar to the issue I opened > https://issues.apache.org/jira/browse/COUCHDB-1095 but at that time I didn't > realize that what I really wanted was the Expires header -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1381) Support Windows 8 Metro Apps
[
https://issues.apache.org/jira/browse/COUCHDB-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189095#comment-13189095
]
Robert Newson commented on COUCHDB-1381:
Dale Harvey suggests that instead of adding that Windows abomination, we a)
change jquery.couch.js to throw an exception instead of alert(str) and b) have
Futon catch exceptions and report them appropriately. This strikes me as a very
sane proposal.
> Support Windows 8 Metro Apps
>
>
> Key: COUCHDB-1381
> URL: https://issues.apache.org/jira/browse/COUCHDB-1381
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
>Affects Versions: 1.1.1
> Environment: Windows 8
>Reporter: Chang Luo
> Labels: javascript, metro, windows
>
> jquery.couch.js doesn't work for Windows 8 Metro apps. Below code works fine
> on browsers. However when run within a Windows 8 Metro app, it throws an
> error in line 665 jquery.couch.js: alert undefined.
> If this is hard to fixed, any alternative javascript library recommendation
> is welcome.
>
>
>
> CouchDB jQuery Examples
>
>
>
>
>
>
>
>
>
>
> console.log('starting');
> $.couch.urlPrefix = "http://localhost:5984";;
> $.couch.db("_users").allDocs({
> success: function (data) {
> console.log();
> }
> });
> console.log('done');
>
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1206) View ETags may be incorrect if ?include_docs=true is specified
[ https://issues.apache.org/jira/browse/COUCHDB-1206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189065#comment-13189065 ] Robert Newson commented on COUCHDB-1206: Erm, so what? :) > View ETags may be incorrect if ?include_docs=true is specified > -- > > Key: COUCHDB-1206 > URL: https://issues.apache.org/jira/browse/COUCHDB-1206 > Project: CouchDB > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Jens Alfke >Assignee: Robert Newson >Priority: Minor > Fix For: 1.1.1, 1.2 > > > Change COUCHDB-799 altered the way ETags are assigned to views, by having the > ETag change only when the view index changes, not when any document changes. > Unfortunately this means that a view with the "?include_docs=true" option can > return an incorrect ETag. The reason is that if a document in the view is > changed, but the change doesn't affect the view index, the result of the GET > will change (it will contain the document's updated contents), but the ETag > won't. This can result in stale data if the client uses a conditional GET, > because it'll get a 304 even though the prior response is out of date. > Robert Newson's analysis on the user@ list is "I think the sanest fix is to > make view etags for include_docs=true use the original algorithm, so that > they always change if the database changes." -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1381) Support Windows 8 Metro Apps
[
https://issues.apache.org/jira/browse/COUCHDB-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189060#comment-13189060
]
Robert Newson commented on COUCHDB-1381:
That was my conclusion also, but isn't that just absolutely foul?
> Support Windows 8 Metro Apps
>
>
> Key: COUCHDB-1381
> URL: https://issues.apache.org/jira/browse/COUCHDB-1381
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
>Affects Versions: 1.1.1
> Environment: Windows 8
>Reporter: Chang Luo
> Labels: javascript, metro, windows
>
> jquery.couch.js doesn't work for Windows 8 Metro apps. Below code works fine
> on browsers. However when run within a Windows 8 Metro app, it throws an
> error in line 665 jquery.couch.js: alert undefined.
> If this is hard to fixed, any alternative javascript library recommendation
> is welcome.
>
>
>
> CouchDB jQuery Examples
>
>
>
>
>
>
>
>
>
>
> console.log('starting');
> $.couch.urlPrefix = "http://localhost:5984";;
> $.couch.db("_users").allDocs({
> success: function (data) {
> console.log();
> }
> });
> console.log('done');
>
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1381) Support Windows 8 Metro Apps
[
https://issues.apache.org/jira/browse/COUCHDB-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189059#comment-13189059
]
Robert Newson commented on COUCHDB-1381:
That was my conclusion also, but isn't that just absolutely foul?
> Support Windows 8 Metro Apps
>
>
> Key: COUCHDB-1381
> URL: https://issues.apache.org/jira/browse/COUCHDB-1381
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
>Affects Versions: 1.1.1
> Environment: Windows 8
>Reporter: Chang Luo
> Labels: javascript, metro, windows
>
> jquery.couch.js doesn't work for Windows 8 Metro apps. Below code works fine
> on browsers. However when run within a Windows 8 Metro app, it throws an
> error in line 665 jquery.couch.js: alert undefined.
> If this is hard to fixed, any alternative javascript library recommendation
> is welcome.
>
>
>
> CouchDB jQuery Examples
>
>
>
>
>
>
>
>
>
>
> console.log('starting');
> $.couch.urlPrefix = "http://localhost:5984";;
> $.couch.db("_users").allDocs({
> success: function (data) {
> console.log();
> }
> });
> console.log('done');
>
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1206) View ETags may be incorrect if ?include_docs=true is specified
[ https://issues.apache.org/jira/browse/COUCHDB-1206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189056#comment-13189056 ] Robert Newson commented on COUCHDB-1206: The all_docs view includes the update_seq, so the ETag is still correct. What problem are you experiencing? > View ETags may be incorrect if ?include_docs=true is specified > -- > > Key: COUCHDB-1206 > URL: https://issues.apache.org/jira/browse/COUCHDB-1206 > Project: CouchDB > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Jens Alfke >Assignee: Robert Newson >Priority: Minor > Fix For: 1.1.1, 1.2 > > > Change COUCHDB-799 altered the way ETags are assigned to views, by having the > ETag change only when the view index changes, not when any document changes. > Unfortunately this means that a view with the "?include_docs=true" option can > return an incorrect ETag. The reason is that if a document in the view is > changed, but the change doesn't affect the view index, the result of the GET > will change (it will contain the document's updated contents), but the ETag > won't. This can result in stale data if the client uses a conditional GET, > because it'll get a 304 even though the prior response is out of date. > Robert Newson's analysis on the user@ list is "I think the sanest fix is to > make view etags for include_docs=true use the original algorithm, so that > they always change if the database changes." -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1381) Support Windows 8 Metro Apps
[
https://issues.apache.org/jira/browse/COUCHDB-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13188593#comment-13188593
]
Robert Newson commented on COUCHDB-1381:
It seems this environment doesn't support alert(str), which is used in several
places in jquery.couch.js. Is there an equivalent function?
> Support Windows 8 Metro Apps
>
>
> Key: COUCHDB-1381
> URL: https://issues.apache.org/jira/browse/COUCHDB-1381
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
>Affects Versions: 1.1.1
> Environment: Windows 8
>Reporter: Chang Luo
> Labels: javascript, metro, windows
>
> jquery.couch.js doesn't work for Windows 8 Metro apps. Below code works fine
> on browsers. However when run within a Windows 8 Metro app, it throws an
> error in line 665 jquery.couch.js: alert undefined.
> If this is hard to fixed, any alternative javascript library recommendation
> is welcome.
>
>
>
> CouchDB jQuery Examples
>
>
>
>
>
>
>
>
>
>
> console.log('starting');
> $.couch.urlPrefix = "http://localhost:5984";;
> $.couch.db("_users").allDocs({
> success: function (data) {
> console.log();
> }
> });
> console.log('done');
>
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1373) Time-ordered document ids including the database identity
[
https://issues.apache.org/jira/browse/COUCHDB-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13185690#comment-13185690
]
Robert Newson commented on COUCHDB-1373:
grabbing the MAC by name is as simple as;
fun(Name) -> {ok, List} = inet:getifaddrs(), If = proplists:get_value(Name,
List), proplists:get_value(hwaddr, If) end.
So I suggest the value in the .ini file is the name of the interface ("eth0",
for example) and not a uuid, this will ensure that any live node is using a
different value.
> Time-ordered document ids including the database identity
> --
>
> Key: COUCHDB-1373
> URL: https://issues.apache.org/jira/browse/COUCHDB-1373
> Project: CouchDB
> Issue Type: Improvement
> Components: Database Core
>Reporter: Nick North
>Priority: Minor
> Labels: uuid
> Attachments: 0001-Add-etap-for-jira-1373.patch,
> 0002-utc_id_suffix.patch, 0003-utc_id_suffix.patch, couch_uuids.patch,
> utc_machine_id.patch
>
>
> This suggestion is for an enhancement to the document id generation
> algorithms in CouchDb. I am new to CouchDb, and this question addresses an
> old issue (https://issues.apache.org/jira/browse/COUCHDB-465) so please
> forgive me if I am retreading old ground.
> My application has a number of mutually replicating CouchDb instances and I
> would like document ids to be monotonically-increasing per-instance, and
> globally unique, and for the instance where the document was created to be
> determinable from the id. (To be more accurate - I don't need to know
> anything about the instance itself; just whether any two documents originated
> from the same instance.) The utc_random algorithm is not far from meeting
> these requirements, as ids are monotonic and almost certainly globally
> unique. However, the instance cannot be determined from the id, and there is
> a tiny chance of an id clash between two instances. Both of these issues
> could be solved if the random part of the id could be replaced with a suffix
> that is fixed in the ini file for each instance.
> To address this I have a modified version of couch_uuids.erl introducing a
> new utc_machine_id algorithm which reads a machine_id string from the ini
> file and then generates ids using an internal utc_suffix method that just
> appends the string to the usual utc 14-byte string. utc_random then also uses
> the utc_suffix method, but its suffix is the usual random byte string.
> However, it is obviously a nuisance to have to maintain a non-standard
> distribution, so I wondered if there is enough call for this sort of thing to
> make it a part of the standard distribution? If there is, I'd be very happy
> to make my code available for discussion/modification/inclusion. If there are
> good reasons why this is a bad idea, then I'd also be very interested to hear
> them so that I can rethink my ideas. (It happens that the privacy and
> guessability concerns raised in the original discussion do not apply in my
> case.) If this question has been beaten to death, then I'm sorry for
> bothering the group, and would be grateful if someone could point me to the
> discussions so that I can understand the issues.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1373) Time-ordered document ids including the database identity
[ https://issues.apache.org/jira/browse/COUCHDB-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13185564#comment-13185564 ] Robert Newson commented on COUCHDB-1373: Some food for thought: http://blog.boundary.com/2012/01/12/Flake-A-decentralized-k-ordered-id-generation-service-in-Erlang.html > Time-ordered document ids including the database identity > -- > > Key: COUCHDB-1373 > URL: https://issues.apache.org/jira/browse/COUCHDB-1373 > Project: CouchDB > Issue Type: Improvement > Components: Database Core >Reporter: Nick North >Priority: Minor > Labels: uuid > Attachments: 0001-Add-etap-for-jira-1373.patch, > 0002-utc_id_suffix.patch, 0003-utc_id_suffix.patch, couch_uuids.patch, > utc_machine_id.patch > > > This suggestion is for an enhancement to the document id generation > algorithms in CouchDb. I am new to CouchDb, and this question addresses an > old issue (https://issues.apache.org/jira/browse/COUCHDB-465) so please > forgive me if I am retreading old ground. > My application has a number of mutually replicating CouchDb instances and I > would like document ids to be monotonically-increasing per-instance, and > globally unique, and for the instance where the document was created to be > determinable from the id. (To be more accurate - I don't need to know > anything about the instance itself; just whether any two documents originated > from the same instance.) The utc_random algorithm is not far from meeting > these requirements, as ids are monotonic and almost certainly globally > unique. However, the instance cannot be determined from the id, and there is > a tiny chance of an id clash between two instances. Both of these issues > could be solved if the random part of the id could be replaced with a suffix > that is fixed in the ini file for each instance. > To address this I have a modified version of couch_uuids.erl introducing a > new utc_machine_id algorithm which reads a machine_id string from the ini > file and then generates ids using an internal utc_suffix method that just > appends the string to the usual utc 14-byte string. utc_random then also uses > the utc_suffix method, but its suffix is the usual random byte string. > However, it is obviously a nuisance to have to maintain a non-standard > distribution, so I wondered if there is enough call for this sort of thing to > make it a part of the standard distribution? If there is, I'd be very happy > to make my code available for discussion/modification/inclusion. If there are > good reasons why this is a bad idea, then I'd also be very interested to hear > them so that I can rethink my ideas. (It happens that the privacy and > guessability concerns raised in the original discussion do not apply in my > case.) If this question has been beaten to death, then I'm sorry for > bothering the group, and would be grateful if someone could point me to the > discussions so that I can understand the issues. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1367) update_seq does not always reflect the seq of the latest document update
[ https://issues.apache.org/jira/browse/COUCHDB-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13181968#comment-13181968 ] Robert Newson commented on COUCHDB-1367: FYI: I've fixed couchdb-lucene. Instead of using "update_seq" from GET /dbname I instead grab "last_seq" from GET /dbname/_changes?limit=0&descending=true. > update_seq does not always reflect the seq of the latest document update > > > Key: COUCHDB-1367 > URL: https://issues.apache.org/jira/browse/COUCHDB-1367 > Project: CouchDB > Issue Type: Bug > Components: HTTP Interface >Affects Versions: 1.1.1 > Environment: Any >Reporter: Henrik Hofmeister >Priority: Minor > Labels: revs_limit > > Certain operations, (currently _revs_limit and _security changes) cause the > database header's update_seq to increase when the by_seq index (and therefore > _changes) has not changed, which is confusing in light of the naming > consistency. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1367) update_seq does not always reflect the seq of the latest document update
[ https://issues.apache.org/jira/browse/COUCHDB-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13177798#comment-13177798 ] Robert Newson commented on COUCHDB-1367: I still don't see why we need do anything. My early mistaken understanding of this value should not be used as motivation here. At the time, I was not a "couchdb committer" so the earlier implication that it escaped even my awesome knowledge is to impute omniscience where none is warranted. I haven't yet fixed couchdb-lucene as the update model is rather clumsy. Simply calling _changes?since=N instead of comparing update_seq with a local value will radically simplify that piece of couchdb-lucene. It should improve the internals of couchdb-lucene so significantly that I would rather *not* fix update_seq to work the way I expected years ago, in case it misleads someone into making the same mistake I made. That said, I wouldn't veto the change, but C-L will not depend on either the current or any future meaning of update_seq in the next release. > update_seq does not always reflect the seq of the latest document update > > > Key: COUCHDB-1367 > URL: https://issues.apache.org/jira/browse/COUCHDB-1367 > Project: CouchDB > Issue Type: Bug > Components: HTTP Interface >Affects Versions: 1.1.1 > Environment: Any >Reporter: Henrik Hofmeister >Priority: Minor > Labels: revs_limit > > Certain operations, (currently _revs_limit and _security changes) cause the > database header's update_seq to increase when the by_seq index (and therefore > _changes) has not changed, which is confusing in light of the naming > consistency. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1372) "_stats" reduce producing errors on empty views
[
https://issues.apache.org/jira/browse/COUCHDB-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13177721#comment-13177721
]
Robert Newson commented on COUCHDB-1372:
nvm, I see it now. The view still returns results ('{"rows":[]}') but there's a
function_clause in the log, doesn't appear fatal, but it is untidy.
> "_stats" reduce producing errors on empty views
> ---
>
> Key: COUCHDB-1372
> URL: https://issues.apache.org/jira/browse/COUCHDB-1372
> Project: CouchDB
> Issue Type: Bug
> Components: JavaScript View Server
>Affects Versions: 1.1.1
> Environment: windows, most likely effects all systems
>Reporter: paul iannazzo
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> have a database with any number of documents in it. create a map that outputs
> 0 things (no emits called). use reduce : "_stats". an error should occur.
> it's very common to have views be an empty set since maps act as filters in
> couchdb.
> when i use my own reduce functions i don't get errors, only with the standard
> couchdb functions.
> this wouldn't be a problem if i could use commonJS in my reduces.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1372) "_stats" reduce producing errors on empty views
[ https://issues.apache.org/jira/browse/COUCHDB-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13177718#comment-13177718 ] Robert Newson commented on COUCHDB-1372: I'm unable to reproduce this, could you include the error you received? > "_stats" reduce producing errors on empty views > --- > > Key: COUCHDB-1372 > URL: https://issues.apache.org/jira/browse/COUCHDB-1372 > Project: CouchDB > Issue Type: Bug > Components: JavaScript View Server >Affects Versions: 1.1.1 > Environment: windows, most likely effects all systems >Reporter: paul iannazzo > Original Estimate: 24h > Remaining Estimate: 24h > > have a database with any number of documents in it. create a map that outputs > 0 things (no emits called). use reduce : "_stats". an error should occur. > it's very common to have views be an empty set since maps act as filters in > couchdb. > when i use my own reduce functions i don't get errors, only with the standard > couchdb functions. > this wouldn't be a problem if i could use commonJS in my reduces. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1367) When settings revs_limit on db - the db increases its update_seq counter when viewing stats - but not when getting changes
[ https://issues.apache.org/jira/browse/COUCHDB-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175368#comment-13175368 ] Robert Newson commented on COUCHDB-1367: The motivation for c-l's current approach is for indexes to be fresh at all times as well as updating the lucene indexes optimally (in modest sized batches). If it were purely driven by user queries, it would be variably stale, and variably well optimized, like couchdb's indexes. I wanted better for my child. > When settings revs_limit on db - the db increases its update_seq counter when > viewing stats - but not when getting changes > -- > > Key: COUCHDB-1367 > URL: https://issues.apache.org/jira/browse/COUCHDB-1367 > Project: CouchDB > Issue Type: Bug > Components: HTTP Interface >Affects Versions: 1.1.1 > Environment: Any >Reporter: Henrik Hofmeister >Priority: Minor > Labels: revs_limit > > If you put a number to _revs_limit on a db (to update it) - the > http://host/dbname/ info document gets an increase in update_seq number - > however the changes feed does not contain this change (while its not a > change). This causes the update_seq in the dbinfo doc and the last seq in the > changes feed to differ - which breaks any application depending on the > update_seq number as the expected sequence size of the db (in my case - > couchdb-lucene that will only respond to stale requests because it thinks its > not up to date) > I know this is an edge case - but still its something fairly fundamental - > that clearly is not working as intended. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1367) When settings revs_limit on db - the db increases its update_seq counter when viewing stats - but not when getting changes
[ https://issues.apache.org/jira/browse/COUCHDB-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175357#comment-13175357 ] Robert Newson commented on COUCHDB-1367: On reflection, it's couchdb-lucene's bug, not couchdb's. Let me explain. CouchDB-Lucene (to give it its grown-up name) compares the update_seq from a GET /dbname to the sequences a background process is indexing through. It then unblocks searcher threads as that process reaches or exceeds the required update_seq. This is, in fact, just silly. Instead, a search query should cause a GET /dbname/_changes?since=. It should block until it consumes the entire response, passing the updates to the indexing process. It can then return a non-stale search result. In the case that the index is fresh, the _changes response contains no rows, and serves only to confirm that the index is fresh. If, as planned, CouchDB-Lucene *also* runs a _changes?feed=continuous to keep indexes fresh in the background then indexes will simply be fresher than they would be in the CouchDB case. I repeat, CouchDB-Lucene's *mistake* is to *only* use the feed=continuous variety of the changes feed. This prevents it from knowing when its own index is fresh. I will make this change next week and I suggest that this ticket be closed with no further action taken. > When settings revs_limit on db - the db increases its update_seq counter when > viewing stats - but not when getting changes > -- > > Key: COUCHDB-1367 > URL: https://issues.apache.org/jira/browse/COUCHDB-1367 > Project: CouchDB > Issue Type: Bug > Components: HTTP Interface >Affects Versions: 1.1.1 > Environment: Any >Reporter: Henrik Hofmeister >Assignee: Bob Dionne >Priority: Minor > Labels: revs_limit > > If you put a number to _revs_limit on a db (to update it) - the > http://host/dbname/ info document gets an increase in update_seq number - > however the changes feed does not contain this change (while its not a > change). This causes the update_seq in the dbinfo doc and the last seq in the > changes feed to differ - which breaks any application depending on the > update_seq number as the expected sequence size of the db (in my case - > couchdb-lucene that will only respond to stale requests because it thinks its > not up to date) > I know this is an edge case - but still its something fairly fundamental - > that clearly is not working as intended. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1367) When settings revs_limit on db - the db increases its update_seq counter when viewing stats - but not when getting changes
[ https://issues.apache.org/jira/browse/COUCHDB-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175168#comment-13175168 ] Robert Newson commented on COUCHDB-1367: Correct, 'monotonically incrementing' means that the number always goes up but does *not* imply that it always goes up by exactly 1. Because it sorta kind *sounds* like that, I clarified with 'never goes down' and tried a synonym for monotonic. The changes feed will certainly have gaps, but no row N will have a lower update_seq than any previously seen row. monotonic |ˌmänəˈtänik| adjective 1 Mathematics (of a function or quantity) varying in such a way that it either never decreases or never increases. > When settings revs_limit on db - the db increases its update_seq counter when > viewing stats - but not when getting changes > -- > > Key: COUCHDB-1367 > URL: https://issues.apache.org/jira/browse/COUCHDB-1367 > Project: CouchDB > Issue Type: Bug > Components: HTTP Interface >Affects Versions: 1.1.1 > Environment: Any >Reporter: Henrik Hofmeister >Assignee: Bob Dionne >Priority: Minor > Labels: revs_limit > > If you put a number to _revs_limit on a db (to update it) - the > http://host/dbname/ info document gets an increase in update_seq number - > however the changes feed does not contain this change (while its not a > change). This causes the update_seq in the dbinfo doc and the last seq in the > changes feed to differ - which breaks any application depending on the > update_seq number as the expected sequence size of the db (in my case - > couchdb-lucene that will only respond to stale requests because it thinks its > not up to date) > I know this is an edge case - but still its something fairly fundamental - > that clearly is not working as intended. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1367) When settings revs_limit on db - the db increases its update_seq counter when viewing stats - but not when getting changes
[ https://issues.apache.org/jira/browse/COUCHDB-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175143#comment-13175143 ] Robert Newson commented on COUCHDB-1367: I would hope it's obvious that update_seq must be monotonously incrementing (i.e, it cannot go down). You're right in the strict sense here, readers of the changes feed will get a row for each document change, and nothing else. The subtle point I think you've missed in that some applications want to know if they've read all changes up to the current update sequence of the database. non stale=ok view queries already do this, and couchdb-lucene does too. It turns out that *only* the view engine can do it correctly in all cases because it knows the last sequence value that affected a document (that is, it doesn't 'see' the change to _security, and thus doesn't block for that change). > When settings revs_limit on db - the db increases its update_seq counter when > viewing stats - but not when getting changes > -- > > Key: COUCHDB-1367 > URL: https://issues.apache.org/jira/browse/COUCHDB-1367 > Project: CouchDB > Issue Type: Bug > Components: HTTP Interface >Affects Versions: 1.1.1 > Environment: Any >Reporter: Henrik Hofmeister >Assignee: Bob Dionne >Priority: Minor > Labels: revs_limit > > If you put a number to _revs_limit on a db (to update it) - the > http://host/dbname/ info document gets an increase in update_seq number - > however the changes feed does not contain this change (while its not a > change). This causes the update_seq in the dbinfo doc and the last seq in the > changes feed to differ - which breaks any application depending on the > update_seq number as the expected sequence size of the db (in my case - > couchdb-lucene that will only respond to stale requests because it thinks its > not up to date) > I know this is an edge case - but still its something fairly fundamental - > that clearly is not working as intended. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1367) When settings revs_limit on db - the db increases its update_seq counter when viewing stats - but not when getting changes
[ https://issues.apache.org/jira/browse/COUCHDB-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13172791#comment-13172791 ] Robert Newson commented on COUCHDB-1367: Oh, ye of little faith. couchdb-lucene certainly can handle the last_seq output (and has since approximately forever). It's just so rarely encountered that it doesn't help with respect to the issue at hand. > When settings revs_limit on db - the db increases its update_seq counter when > viewing stats - but not when getting changes > -- > > Key: COUCHDB-1367 > URL: https://issues.apache.org/jira/browse/COUCHDB-1367 > Project: CouchDB > Issue Type: Bug > Components: HTTP Interface >Affects Versions: 1.1.1 > Environment: Any >Reporter: Henrik Hofmeister >Assignee: Bob Dionne >Priority: Minor > Labels: revs_limit > > If you put a number to _revs_limit on a db (to update it) - the > http://host/dbname/ info document gets an increase in update_seq number - > however the changes feed does not contain this change (while its not a > change). This causes the update_seq in the dbinfo doc and the last seq in the > changes feed to differ - which breaks any application depending on the > update_seq number as the expected sequence size of the db (in my case - > couchdb-lucene that will only respond to stale requests because it thinks its > not up to date) > I know this is an edge case - but still its something fairly fundamental - > that clearly is not working as intended. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1353) Adding security to the replication database leads to crashes
[
https://issues.apache.org/jira/browse/COUCHDB-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13161560#comment-13161560
]
Robert Newson commented on COUCHDB-1353:
Am I summarizing correctly that you've removed authorization for the replicator
to read the replicator db and are wondering why the replicator can't read the
replicator db?
> Adding security to the replication database leads to crashes
>
>
> Key: COUCHDB-1353
> URL: https://issues.apache.org/jira/browse/COUCHDB-1353
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
>Affects Versions: 1.1.1, 1.2
> Environment: Ubuntu
>Reporter: Martin Higham
>
> If I set Admin and reader security on the replication database the replicator
> will crash when adding new records to the database with a "not authorised
> error". It will continue to crash while trying to restart replication and
> even after a restart
> 1. Create several databases and replication rules - everything works fine
> 2. Add reader security to the replication database
> 3. Insert new document into the replication database. Replication will record
> the error and stop all replication
> [Fri, 02 Dec 2011 10:45:36 GMT] [debug] [<0.216.0>] OS Process #Port<0.2851>
> Input :: ["ddoc","_design/_replicator",["valida
> te_doc_update"],[{"_id":"8d158931ac19d99f96f2aad68104aa09","target":"testrep","continuous":true,"source":"http://admin:a@
> 127.0.0.1:5984/dbz_molly","_revisions":{"start":0,"ids":[]}},null,{"db":"ndz_replicator","name":"admin","roles":["_admin"]},{
> "admins":{"names":[],"roles":["_admin","_replicator"]},"members":{"names":[],"roles":["_admin","_replicator"]}}]]
> [Fri, 02 Dec 2011 10:45:36 GMT] [debug] [<0.216.0>] OS Process #Port<0.2851>
> Output :: 1
> [Fri, 02 Dec 2011 10:45:36 GMT] [info] [<0.12560.0>] 109.150.210.170 - - PUT
> /ndz_replicator/8d158931ac19d99f96f2aad68104aa09
> 201
> [Fri, 02 Dec 2011 10:45:36 GMT] [debug] [<0.117.0>] Not a reader: UserCtx
> {user_ctx,null,[],undefined} vs Names [] Roles [<<"
> _admin">>,
>
> <<"_admin">>,
>
> <<"_replicator">>]
> [Fri, 02 Dec 2011 10:45:36 GMT] [error] [<0.110.0>] Replication manager
> received unexpected message {'EXIT',
>
> <0.117.0>,
>
> {{nocatch,
>
> {unauthorized,
>
> <<"You are not authorized to access this db.">>}},
>
> [{couch_db,
> open,
> 2},
>
> {couch_changes,
>
> keep_sending_changes,
> 9},
>
> {couch_changes,
>
> '-handle_changes/3-fun-1-',
> 5},
>
> {couch_replication_manager,
>
> '-changes_feed_loop/0-fun-1-',
> 2}]}}
> [Fri, 02 Dec 2011 10:45:36 GMT] [error] [emulator] Error in process <0.117.0>
> with exit value: {{nocatch,{unauthorized,<<41 b
> ytes>>}},[{couch_db,open,2},{couch_changes,keep_sending_changes,9},{couch_changes,'-handle_changes/3-fun-1-',5},{couch_replic
> ation_manager,'-changes_feed_loop/0-fun-1-',2}]}
> [Fri, 02 Dec 2011 10:45:36 GMT] [info] [<0.110.0>] Stopping all ongoing
> replications because the replicator database was deleted or changed
> I am testing against a trunk build of CouchDB but think I have seen similar
> behaviour on 1.1.x but hadn't pinned down the cause
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1212) Newly created user accounts cannot sign-in after _user database crashes
[
https://issues.apache.org/jira/browse/COUCHDB-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13160905#comment-13160905
]
Robert Newson commented on COUCHDB-1212:
I assume Benoit is suggesting replacing the ref counting with monitors, which
we do in BigCouch.
> Newly created user accounts cannot sign-in after _user database crashes
>
>
> Key: COUCHDB-1212
> URL: https://issues.apache.org/jira/browse/COUCHDB-1212
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core, HTTP Interface
>Affects Versions: 1.0.2
> Environment: Ubuntu 10.10, Erlang R14B02 (erts-5.8.3)
>Reporter: Jan van den Berg
>Priority: Critical
> Labels: _users, authentication
> Attachments: couchdb-1212.patch
>
>
> We have one (4,5 GB) couch database and we use the (default) _users database
> to store user accounts for a website. Once a week we need to restart couchdb
> because newly sign-up user accounts cannot login any more. They get a HTTP
> statuscode 401 from the _session HTTP interface. We update, and compact the
> database three times a day.
> This is the a stacktrace I see in the couch database log prior to when these
> issues occur.
> --- couch.log ---
> [Wed, 29 Jun 2011 22:02:46 GMT] [info] [<0.117.0>] Starting compaction for db
> "fbm"
> [Wed, 29 Jun 2011 22:02:46 GMT] [info] [<0.5753.79>] 127.0.0.1 - - 'POST'
> /fbm/_compact 202
> [Wed, 29 Jun 2011 22:02:46 GMT] [info] [<0.5770.79>] 127.0.0.1 - - 'POST'
> /fbm/_view_cleanup 202
> [Wed, 29 Jun 2011 22:10:19 GMT] [info] [<0.5773.79>] 86.9.246.184 - - 'GET'
> /_session 200
> [Wed, 29 Jun 2011 22:24:39 GMT] [info] [<0.6236.79>] 85.28.105.161 - - 'GET'
> /_session 200
> [Wed, 29 Jun 2011 22:25:06 GMT] [error] [<0.84.0>] ** Generic server
> couch_server terminating
> ** Last message in was {open,<<"fbm">>,
> [{user_ctx,{user_ctx,null,[],undefined}}]}
> ** When Server state == {server,"/opt/couchbase-server/var/lib/couchdb",
> {re_pattern,0,0,
> <<69,82,67,80,116,0,0,0,16,0,0,0,1,0,0,0,0,0,
> 0,0,0,0,0,0,40,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> 0,93,0,72,25,77,0,0,0,0,0,0,0,0,0,0,0,0,254,
> 255,255,7,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> 77,0,0,0,0,16,171,255,3,0,0,0,128,254,255,
> 255,7,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,69,26,
> 84,0,72,0>>},
> 100,2,"Sat, 18 Jun 2011 14:00:44 GMT"}
> ** Reason for termination ==
> ** {timeout,{gen_server,call,[<0.116.0>,{open_ref_count,<0.10417.79>}]}}
> [Wed, 29 Jun 2011 22:25:06 GMT] [error] [<0.84.0>] {error_report,<0.31.0>,
> {<0.84.0>,crash_report,
> [[{initial_call,{couch_server,init,['Argument__1']}},
>{pid,<0.84.0>},
>{registered_name,couch_server},
>{error_info,
>{exit,
>{timeout,
>{gen_server,call,
>[<0.116.0>,{open_ref_count,<0.10417.79>}]}},
>[{gen_server,terminate,6},{proc_lib,init_p_do_apply,3}]}},
>{ancestors,[couch_primary_services,couch_server_sup,<0.32.0>]},
>{messages,[]},
>{links,[<0.91.0>,<0.483.0>,<0.116.0>,<0.79.0>]},
>{dictionary,[]},
>{trap_exit,true},
>{status,running},
>{heap_size,6765},
>{stack_size,24},
>{reductions,206710598}],
> []]}}
> [Wed, 29 Jun 2011 22:25:06 GMT] [error] [<0.79.0>] {error_report,<0.31.0>,
> {<0.79.0>,supervisor_report,
> [{supervisor,{local,couch_primary_services}},
> {errorContext,child_terminated},
> {reason,
> {timeout,
> {gen_server,call,[<0.116.0>,{open_ref_count,<0.10417.79>}]}}},
> {offender,
> [{pid,<0.84.0>},
>{name,couch_server},
>{mfargs,{couch_server,sup_start_link,[]}},
>{restart_type,permanent},
>{shutdown,1000},
>{child_type,worker}]}]}}
> [Wed, 29 Jun 2011 22:25:06 GMT] [error] [<0.91.0>] ** Generic server <0.91.0>
> terminating
> ** Last message in was {'EXIT',<0.84.0>,
>{timeout,
>{gen_server,call,
>[<0.116.0>,
> {open_ref_count,<0.10417.79>}]}}}
> ** When Server state == {db,<0.91.0>,<0.92.0>,nil,<<"1308405644393791">>,
> <0.90.0>,<0.94.0>,
> {db_header,5,91,0,
> {378285,{30,9}},
>
[jira] [Commented] (COUCHDB-1342) Asynchronous file writes
[ https://issues.apache.org/jira/browse/COUCHDB-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13152240#comment-13152240 ] Robert Newson commented on COUCHDB-1342: I saw the (hardcoded) 1 mib limit but my context is hundreds or thousands of such things at once. Making it configurable or even optional would be an improvement. I appreciate the effort to close some of these gaps but, speaking personally and from (bitter) experience, trying to get a large piece of work into trunk with promises to fix things 'later' really bothers me. I don't see why this work can't sit on a branch while the discussion, and the enhancements continue. > Asynchronous file writes > > > Key: COUCHDB-1342 > URL: https://issues.apache.org/jira/browse/COUCHDB-1342 > Project: CouchDB > Issue Type: Improvement > Components: Database Core >Reporter: Jan Lehnardt > Fix For: 1.3 > > Attachments: COUCHDB-1342.patch > > > This change updates the file module so that it can do > asynchronous writes. Basically it replies immediately > to process asking to write something to the file, with > the position where the chunks will be written to the > file, while a dedicated child process keeps collecting > chunks and write them to the file (and batching them > when possible). After issuing a series of write request > to the file module, the caller can call its 'flush' > function which will block the caller until all the > chunks it requested to write are effectively written > to the file. > This maximizes the IO subsystem, as for example, while > the updater is traversing and modifying the btrees and > doing CPU bound tasks, the writes are happening in > parallel. > Originally described at http://s.apache.org/TVu > Github Commit: > https://github.com/fdmanana/couchdb/commit/e82a673f119b82dddf674ac2e6233cd78c123554 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1340) Replication: Invalid JSON reported
[
https://issues.apache.org/jira/browse/COUCHDB-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13152089#comment-13152089
]
Robert Newson commented on COUCHDB-1340:
actually it does (they're baked in by couch_rep_httpc:full_url/1), I think the
mistake is later when accounting for ?open_revs=[].
> Replication: Invalid JSON reported
> --
>
> Key: COUCHDB-1340
> URL: https://issues.apache.org/jira/browse/COUCHDB-1340
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
>Affects Versions: 1.1.1
> Environment: CentOS 5.6 x86_64, Couchdb 1.1.1 (Patched for
> COUCHDB-1333), spidermonkey 1.8.5, curl 7.21, erlang 14b03
>Reporter: Alex Markham
> Labels: invalid, json
> Fix For: 1.2, 1.1.2
>
> Attachments: 9c94ed0e23508f4ec3d18f8949c06a5b replicaton from
> wireshark cut.txt, replication error wireshark.txt, source couch error.log,
> target couch error.log
>
>
> It seems our replication has stopped, reporting an error
> [emulator] Error in process <0.21599.306> {{nocatch,{invalid_json,<<0
> bytes>>}},[{couch_util,json_decode,1},{couch_rep_reader,'-open_doc_revs/3-lc$^1/1-1-',1},{couch_rep_reader,'-open_doc_revs/3-lc$^1/1-1-',1},{couch_rep_reader,open_doc_revs,3},{couch_rep_reader,'-spawn_document_request/4-fun-0-'...
>
> It was all working until we upgraded some other couches in our replication
> "web" from couch 1.0.3 to couch 1.1.1. We then set of database and view
> compactions, and sometime overnight some of the replication links stopped.
> I have curled the command myself, both as a multipart message and a single
> json response (with header "Accept:application/json" ) and it can be parsed
> correctly by Python simplejson - I have attached it here aswell - called
> "troublecurl-redacted.txt" - though it is 18.8mb. The request takes about 6
> seconds.
> I don't quite understand why it is reported as invalid JSON? Other reports
> similar to this that I googled mentioned blank document ids, but I can't see
> any of these.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1342) Asynchronous file writes
[ https://issues.apache.org/jira/browse/COUCHDB-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13152022#comment-13152022 ] Robert Newson commented on COUCHDB-1342: @Damien, thanks for the clarification. It's possible to read what you originally wrote as an intention to dismiss concerns over introducing further complexity as long as it improved performance. Since Paul has now explicitly described several technical problems with the patch I'm sure we can all move on to addressing them. I'll only add that I had read the entire page on voting and didn't feel that the section you highlighted applied in this case, which is why I didn't mention it myself. I would like to know why couch_file now needs two file descriptors to provide asynchronous writes, though. If it's integral, I'd appreciate knowing why, and whether there are alternatives. If not, a separate ticket seems appropriate. The only thing I can think of is the inability to usefully pass a handle to a file opened with [raw] between processes. In any case, doubling the consumption of precious server resources should be called out explicitly, rather than incidentally, in my opinion. Am I also right in thinking that the improved write performance entails increased memory usage (and therefore increased GC too)? What's the impact of that on very busy servers? > Asynchronous file writes > > > Key: COUCHDB-1342 > URL: https://issues.apache.org/jira/browse/COUCHDB-1342 > Project: CouchDB > Issue Type: Improvement > Components: Database Core >Reporter: Jan Lehnardt > Fix For: 1.3 > > Attachments: COUCHDB-1342.patch > > > This change updates the file module so that it can do > asynchronous writes. Basically it replies immediately > to process asking to write something to the file, with > the position where the chunks will be written to the > file, while a dedicated child process keeps collecting > chunks and write them to the file (and batching them > when possible). After issuing a series of write request > to the file module, the caller can call its 'flush' > function which will block the caller until all the > chunks it requested to write are effectively written > to the file. > This maximizes the IO subsystem, as for example, while > the updater is traversing and modifying the btrees and > doing CPU bound tasks, the writes are happening in > parallel. > Originally described at http://s.apache.org/TVu > Github Commit: > https://github.com/fdmanana/couchdb/commit/e82a673f119b82dddf674ac2e6233cd78c123554 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1342) Asynchronous file writes
[ https://issues.apache.org/jira/browse/COUCHDB-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13151567#comment-13151567 ] Robert Newson commented on COUCHDB-1342: Technical comments notwithstanding, saying "We won't be holding up this patch because it seems more complicated than before. It's about what users want." is a little bold. As I understand the Apache rules, if Paul feels strongly he can vote -1 which is a veto. >From http://www.apache.org/foundation/voting.html: "Votes on code modifications follow a different model. In this scenario, a negative vote constitutes a veto , which cannot be overridden." Any suggestion that one person can force in a controversial change to an Apache project needs to be challenged. > Asynchronous file writes > > > Key: COUCHDB-1342 > URL: https://issues.apache.org/jira/browse/COUCHDB-1342 > Project: CouchDB > Issue Type: Improvement > Components: Database Core >Reporter: Jan Lehnardt > Fix For: 1.3 > > Attachments: COUCHDB-1342.patch > > > This change updates the file module so that it can do > asynchronous writes. Basically it replies immediately > to process asking to write something to the file, with > the position where the chunks will be written to the > file, while a dedicated child process keeps collecting > chunks and write them to the file (and batching them > when possible). After issuing a series of write request > to the file module, the caller can call its 'flush' > function which will block the caller until all the > chunks it requested to write are effectively written > to the file. > This maximizes the IO subsystem, as for example, while > the updater is traversing and modifying the btrees and > doing CPU bound tasks, the writes are happening in > parallel. > Originally described at http://s.apache.org/TVu > Github Commit: > https://github.com/fdmanana/couchdb/commit/e82a673f119b82dddf674ac2e6233cd78c123554 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1341) calculate replication id using only db name in remote case
[ https://issues.apache.org/jira/browse/COUCHDB-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13151255#comment-13151255 ] Robert Newson commented on COUCHDB-1341: The original approach, removing the password, seems the sanest move here. We do want to allow multiple remote replications that only vary by hostname, port and user. > calculate replication id using only db name in remote case > -- > > Key: COUCHDB-1341 > URL: https://issues.apache.org/jira/browse/COUCHDB-1341 > Project: CouchDB > Issue Type: Improvement > Components: Replication >Reporter: Bob Dionne >Assignee: Bob Dionne >Priority: Minor > > currently if the source or target in a replication spec contains user/pwd > information it gets encoded in the id which can cause restarts if the > password changes. Change it to use just the db name as the local case does, > Here's a draft[1] of a solution. > [1] https://github.com/bdionne/couchdb/compare/master...9767-fix-repl-id -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1340) Replication: Invalid JSON reported
[
https://issues.apache.org/jira/browse/COUCHDB-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13150632#comment-13150632
]
Robert Newson commented on COUCHDB-1340:
It seems an attempt is being made to decode an empty erlang binary as JSON,
which correctly fails. So the real question is why is that happening?
> Replication: Invalid JSON reported
> --
>
> Key: COUCHDB-1340
> URL: https://issues.apache.org/jira/browse/COUCHDB-1340
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
>Affects Versions: 1.1.1
> Environment: CentOS 5.6 x86_64, Couchdb 1.1.1 (Patched for
> COUCHDB-1333), spidermonkey 1.8.5, curl 7.21, erlang 14b03
>Reporter: Alex Markham
> Labels: invalid, json
> Attachments: source couch error.log, target couch error.log
>
>
> It seems our replication has stopped, reporting an error
> [emulator] Error in process <0.21599.306> {{nocatch,{invalid_json,<<0
> bytes>>}},[{couch_util,json_decode,1},{couch_rep_reader,'-open_doc_revs/3-lc$^1/1-1-',1},{couch_rep_reader,'-open_doc_revs/3-lc$^1/1-1-',1},{couch_rep_reader,open_doc_revs,3},{couch_rep_reader,'-spawn_document_request/4-fun-0-'...
>
> It was all working until we upgraded some other couches in our replication
> "web" from couch 1.0.3 to couch 1.1.1. We then set of database and view
> compactions, and sometime overnight some of the replication links stopped.
> I have curled the command myself, both as a multipart message and a single
> json response (with header "Accept:application/json" ) and it can be parsed
> correctly by Python simplejson - I have attached it here aswell - called
> "troublecurl-redacted.txt" - though it is 18.8mb. The request takes about 6
> seconds.
> I don't quite understand why it is reported as invalid JSON? Other reports
> similar to this that I googled mentioned blank document ids, but I can't see
> any of these.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1337) Use MD5 for attachment ETag
[ https://issues.apache.org/jira/browse/COUCHDB-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13145958#comment-13145958 ] Robert Newson commented on COUCHDB-1337: Feedback from devs welcome. > Use MD5 for attachment ETag > --- > > Key: COUCHDB-1337 > URL: https://issues.apache.org/jira/browse/COUCHDB-1337 > Project: CouchDB > Issue Type: Improvement >Affects Versions: 1.1.1 >Reporter: Jacob Wright >Assignee: Robert Newson >Priority: Minor > Attachments: > 0001-CouchDB-1337-Use-attachments-md5-as-ETag-if-availabl.patch > > > Currently attachments use the revision number of the document they're > attached to for their ETag. This can be inefficient if many attachments are > added, removed, or modified on the same document. Example: a website's assets > might be stored on a document. Whenever one file is changed every file on the > website drops out of cache. > If we could use the MD5 of the attachment for the ETag then any caches > (including the browser's) will not drop unchanged files, even if the document > to which they are attached is modified. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1332) Invalid JSON shows debug level info in response
[ https://issues.apache.org/jira/browse/COUCHDB-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13143889#comment-13143889 ] Robert Newson commented on COUCHDB-1332: Why? > Invalid JSON shows debug level info in response > --- > > Key: COUCHDB-1332 > URL: https://issues.apache.org/jira/browse/COUCHDB-1332 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface >Affects Versions: 1.1.1 > Environment: OS X 10.7.1 Macbook Pro >Reporter: Christopher Bonhage >Priority: Minor > Labels: erlang, error, json > Fix For: 1.1.1 > > Attachments: COUCHDB-1332.patch > > Original Estimate: 0h > Remaining Estimate: 0h > > When sending invalid JSON in an HTTP request, the response contains the > string "invalid UTF-8 JSON: " followed by an erlang tuple and the escaped > internal form of the string. I noticed that this error tuple is only logged > when the [log] level is debug. I would propose that the error tuple only be > show in the client response when debug is on as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1327) CLONE - remote to local replication fails when using a proxy
[
https://issues.apache.org/jira/browse/COUCHDB-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13140690#comment-13140690
]
Robert Newson commented on COUCHDB-1327:
There is no CouchDB 1.1.2 release yet, which version does this really affect?
> CLONE - remote to local replication fails when using a proxy
>
>
> Key: COUCHDB-1327
> URL: https://issues.apache.org/jira/browse/COUCHDB-1327
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
>Affects Versions: 1.1.2
>Reporter: Eliseo Soto
>
> The following is failing for me:
> curl -X POST -H "Content-Type:application/json"
> http://localhost:5984/_replicate -d
> '{"source":"http://isaacs.iriscouch.com/registry/";, "target":"registry",
> "proxy": "http://wwwgate0.myproxy.com:1080"}'
> This is the error:
> {"error":"json_encode","reason":"{bad_term,{nocatch,{invalid_json,<<>>}}}"}
> I have no clue about what's wrong, I can curl
> http://isaacs.iriscouch.com/registry/ directly and it works.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-769) Store large attachments external to the .couch file
[ https://issues.apache.org/jira/browse/COUCHDB-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13140085#comment-13140085 ] Robert Newson commented on COUCHDB-769: --- This is the latest version I have, but it's incomplete. I will be working on the problem again soon. Agree that it would be nicer to abstract things out a little, to allow other storage options. > Store large attachments external to the .couch file > --- > > Key: COUCHDB-769 > URL: https://issues.apache.org/jira/browse/COUCHDB-769 > Project: CouchDB > Issue Type: New Feature > Components: Database Core >Reporter: Robert Newson > Attachments: external_attachments_alpha.patch > > > For attachment-heavy applications storing the attachments in separate files > significantly eases compaction problems. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1313) Support JSONP in externals
[ https://issues.apache.org/jira/browse/COUCHDB-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13131690#comment-13131690 ] Robert Newson commented on COUCHDB-1313: The proposed patch is here; https://github.com/rnewson/couchdb/compare/master...1313-jsonp-externals > Support JSONP in externals > -- > > Key: COUCHDB-1313 > URL: https://issues.apache.org/jira/browse/COUCHDB-1313 > Project: CouchDB > Issue Type: New Feature >Reporter: Robert Newson >Assignee: Robert Newson > Fix For: 1.2 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1302) Fix couchjs
[
https://issues.apache.org/jira/browse/COUCHDB-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13122280#comment-13122280
]
Robert Newson commented on COUCHDB-1302:
+1 on 1,2,3.
Not keen on configure option in 1.1.1 but will go with the flow (though let's
decide soon pls).
for point 4, while that signature looks much nicer, is it too much of a break
for 1.2? Feels like a 2.0 thing. If there's agreement, then the remaining
question is what branch becomes 2.0. Oh, the joy.
> Fix couchjs
> ---
>
> Key: COUCHDB-1302
> URL: https://issues.apache.org/jira/browse/COUCHDB-1302
> Project: CouchDB
> Issue Type: Improvement
> Components: JavaScript View Server
>Affects Versions: 1.1.1, 1.2, 1.3
>Reporter: Paul Joseph Davis
>Priority: Blocker
>
> Figure out why some spidermonkeys have an error when doing:
> eval("function(){}")
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-690) replication fail -- couchdb crashed
[ https://issues.apache.org/jira/browse/COUCHDB-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13118078#comment-13118078 ] Robert Newson commented on COUCHDB-690: --- 0.10.1 is ancient. Is the original poster still active? Inclined to close this ticket as 'Cannot Reproduce' unless someone can reaffirm the bug. > replication fail -- couchdb crashed > --- > > Key: COUCHDB-690 > URL: https://issues.apache.org/jira/browse/COUCHDB-690 > Project: CouchDB > Issue Type: Bug > Components: Replication >Affects Versions: 0.10.1 > Environment: linux 2.6.30.7 - debian 5.0 >Reporter: linkfluence >Priority: Critical > Labels: couchdb, replication > Attachments: couch.log > > > We have a database on host A with 8.5 millions document. The size of the > database is ~450GO. > We first tried to start a continuous replication on a second host B. The > replication stoped after only 1Go have been copied, and the replication never > started again. > We then copied the database file from host A on host B. When the file was > copied, we started a replication from A to B, then the couchdb on host B > crashed. It tooks a long time to fetch a list of IDs, then it appears in the > logfile that a time out occured on host B, and immediatly after the couchdb > instance on host B crashed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
