[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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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%5Dendkey=%5B%229bd1647eb09fca1634a8a6129a8cff46%22%5Dlimit=1descending=trueinclude_docs=truereduce=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%5Dendkey=%5B%22a0d0912e031b8fd28c2f89f828eebb12%22%2C%7B%7D%5Dreduce=trueskip=0limit=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-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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-1424) make check hangs when compiling with R15B
[ https://issues.apache.org/jira/browse/COUCHDB-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-1186) Speedups in the view indexer
[
https://issues.apache.org/jira/browse/COUCHDB-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-1409) Look into manual GC
[ https://issues.apache.org/jira/browse/COUCHDB-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-1410) Formally define number support
[ https://issues.apache.org/jira/browse/COUCHDB-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-1407) JSON encoding of number changes
[
https://issues.apache.org/jira/browse/COUCHDB-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-1407) JSON encoding of number changes
[
https://issues.apache.org/jira/browse/COUCHDB-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-1405) error generating document id with utc_random
[ https://issues.apache.org/jira/browse/COUCHDB-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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=_viewview=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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.
!DOCTYPE html
html
head
titleCouchDB jQuery Examples/title
meta http-equiv=Content-Type content=text/html; charset=utf-8 /
script src=js/json2.js/script
script src=js/sha1.js/script
script src=js/jquery.js/script
script src=js/jquery.couch.js/script
script src=js/jquery.dialog.js/script
/head
body
script
console.log('starting');
$.couch.urlPrefix = http://localhost:5984;;
$.couch.db(_users).allDocs({
success: function (data) {
console.log();
}
});
console.log('done');
/script
/body
/html
--
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-tabpanelfocusedCommentId=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.
!DOCTYPE html
html
head
titleCouchDB jQuery Examples/title
meta http-equiv=Content-Type content=text/html; charset=utf-8 /
script src=js/json2.js/script
script src=js/sha1.js/script
script src=js/jquery.js/script
script src=js/jquery.couch.js/script
script src=js/jquery.dialog.js/script
/head
body
script
console.log('starting');
$.couch.urlPrefix = http://localhost:5984;;
$.couch.db(_users).allDocs({
success: function (data) {
console.log();
}
});
console.log('done');
/script
/body
/html
--
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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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.
!DOCTYPE html
html
head
titleCouchDB jQuery Examples/title
meta http-equiv=Content-Type content=text/html; charset=utf-8 /
script src=js/json2.js/script
script src=js/sha1.js/script
script src=js/jquery.js/script
script src=js/jquery.couch.js/script
script src=js/jquery.dialog.js/script
/head
body
script
console.log('starting');
$.couch.urlPrefix = http://localhost:5984;;
$.couch.db(_users).allDocs({
success: function (data) {
console.log();
}
});
console.log('done');
/script
/body
/html
--
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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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.
!DOCTYPE html
html
head
titleCouchDB jQuery Examples/title
meta http-equiv=Content-Type content=text/html; charset=utf-8 /
script src=js/json2.js/script
script src=js/sha1.js/script
script src=js/jquery.js/script
script src=js/jquery.couch.js/script
script src=js/jquery.dialog.js/script
/head
body
script
console.log('starting');
$.couch.urlPrefix = http://localhost:5984;;
$.couch.db(_users).allDocs({
success: function (data) {
console.log();
}
});
console.log('done');
/script
/body
/html
--
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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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=0descending=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-1372) _stats reduce producing errors on empty views
[ https://issues.apache.org/jira/browse/COUCHDB-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-1372) _stats reduce producing errors on empty views
[
https://issues.apache.org/jira/browse/COUCHDB-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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=latest index checkpoint. 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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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}},
{380466,39},
nil,0,nil,nil,1000},
91,
{btree,0.90.0,
[jira] [Commented] (COUCHDB-1342) Asynchronous file writes
[ https://issues.apache.org/jira/browse/COUCHDB-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-1340) Replication: Invalid JSON reported
[
https://issues.apache.org/jira/browse/COUCHDB-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-1342) Asynchronous file writes
[ https://issues.apache.org/jira/browse/COUCHDB-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-1340) Replication: Invalid JSON reported
[
https://issues.apache.org/jira/browse/COUCHDB-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-1313) Support JSONP in externals
[ https://issues.apache.org/jira/browse/COUCHDB-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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
