[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=13254695#comment-13254695 ] James Howe commented on COUCHDB-1466: - If I want to control replication I should be clicking the link marked Replication and using the nice UI that's there. Instead, for a particular kind of replication I have to go to a completely different UI that's not designed for specifying replications and have in-depth knowledge of the underlying implementation in order to do what I want. Futon can be changed to have a single, complete UI for replication now, and if Rob's preference is implemented then it doesn't need to change (instead the implementation of the interface becomes simpler). 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=13254929#comment-13254929 ] James Howe commented on COUCHDB-1466: - Can I clarify that this is not a request to change the _replicate endpoint, but to modify the Futon UI, which should take far less time and not break any compatibility. The latter can be done without waiting for the former, yet still provides great usability benefits. 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=13255061#comment-13255061 ] James Howe commented on COUCHDB-1466: - A separate ticket should probably be made for that separate change then. 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-1439) `key`, `startkey`, `endkey` query parameters seems to have valid json value for show/update handlers.
[
https://issues.apache.org/jira/browse/COUCHDB-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13229098#comment-13229098
]
James Howe commented on COUCHDB-1439:
-
FWIW this sounds like good behaviour. If parameters have the same name then
they should behave in the same way, and people shouldn't be encouraged to break
that convention. If you need a parameter that behaves differently then you
should give it a different name.
`key`, `startkey`, `endkey` query parameters seems to have valid json value
for show/update handlers.
-
Key: COUCHDB-1439
URL: https://issues.apache.org/jira/browse/COUCHDB-1439
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 1.2, 1.3
Environment: Apache CouchDB 1.3.0a-d6ab08d-git
Apache CouchDB 1.2.0a-0d8ddc8-git
Reporter: Alexander Shorin
Attachments: couchdb-1439_tests.patch
CouchDB requires that values of query parameters with names: `key`,
`startkey`, `endkey` be valid json value when request been catched by show or
update handler. This behavior is expected for views and lists(as they works
as proxy for views and views requires this values as valid json ones), but
it's little surprising to see same behavior for shows and updates.
It's easy to test with any show or update handler:
~ # curl -X PUT http://localhost:5984/app/_design/ddoc -d '{shows:
{empty: function(doc, req){return \\}}, updates: {nothing:
function(doc, req){return [null, \\]}}}'
~ # curl -v http://localhost:5984/app/_design/ddoc/_show/empty?key=foo
* 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 /app/_design/ddoc/_show/empty?key=foo HTTP/1.1
User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 GnuTLS/2.10.5
zlib/1.2.5
Host: localhost:5984
Accept: */*
HTTP/1.1 400 Bad Request
Server: CouchDB/1.3.0a-d6ab08d-git (Erlang OTP/R14B04)
Date: Tue, 13 Mar 2012 14:11:38 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 48
Cache-Control: must-revalidate
{error:bad_request,reason:invalid_json}
* Connection #0 to host localhost left intact
* Closing connection #0
curl -v -X POST http://localhost:5984/app/_design/ddoc/_update/nothing?key=foo
* About to connect() to localhost port 5984 (#0)
* Trying 127.0.0.1...
* connected
* Connected to localhost (127.0.0.1) port 5984 (#0)
POST /app/_design/ddoc/_update/nothing?key=foo HTTP/1.1
User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 GnuTLS/2.10.5
zlib/1.2.5
Host: localhost:5984
Accept: */*
HTTP/1.1 400 Bad Request
Server: CouchDB/1.3.0a-d6ab08d-git (Erlang OTP/R14B04)
Date: Tue, 13 Mar 2012 15:14:11 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 48
Cache-Control: must-revalidate
{error:bad_request,reason:invalid_json}
* Connection #0 to host localhost left intact
* Closing connection #0
while...
~ # curl -v http://localhost:5984/app/_design/ddoc/_show/empty?key=%22foo%22
* 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 /app/_design/ddoc/_show/empty?key=%22foo%22 HTTP/1.1
User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 GnuTLS/2.10.5
zlib/1.2.5
Host: localhost:5984
Accept: */*
HTTP/1.1 200 OK
Vary: Accept
Server: CouchDB/1.3.0a-d6ab08d-git (Erlang OTP/R14B04)
Etag: 3B14BLTA7M1G53XKHX7EP0JUO
Date: Tue, 13 Mar 2012 14:12:20 GMT
Content-Type: application/json
Content-Length: 0
* Connection #0 to host localhost left intact
* Closing connection #0
Initially, I'd faced with such behavior only for `key` parameter. Digging
deeper I've found[1] same thing for `startkey` and `endkey` parameters, but
I've no idea how to explain their dependency well.
[1]
http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=blob;f=src/couchdb/couch_httpd_external.erl;h=bfe77a329d569bcc48cb65d8251a437baf13fae6;hb=HEAD#l110
--
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-1415) Re-insering a document silently fails after compact is executed
[
https://issues.apache.org/jira/browse/COUCHDB-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214679#comment-13214679
]
James Howe commented on COUCHDB-1415:
-
Does this only happen when step 5 is a POST, or are PUTs affected too?
Re-insering a document silently fails after compact is executed
---
Key: COUCHDB-1415
URL: https://issues.apache.org/jira/browse/COUCHDB-1415
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 1.1.1
Environment: Tested on multiple linux platforms
Reporter: Viktor Szabo
Fix For: 1.3
When a document is re-inserted after a compact operation using the same
contents it was originally created, the insert operation is silently ignored,
leaving the client unaware of the fact it's document is not available in the
database.
Can be reproduced using the following sequence of steps:
alias curl='curl -H Content-Type: application/json'
url=http://localhost:5984/database;
1 curl -X PUT $url
2 curl -X POST $url -d '{_id: bug, key: value}'
3 curl -X DELETE $url/bug?rev=1-59414e77c768bc202142ac82c2f129de
4 curl -X POST $url/_compact
5 curl -X POST $url -d '{_id: bug, key: value}'
6 curl -X GET $url/bug
(bug here)
1 {ok:true}
201
2 [{ok:true,id:bug,rev:1-59414e77c768bc202142ac82c2f129de}]
201
3 {ok:true,id:bug,rev:2-9b2e3bcc3752a3a952a3570b2ed4d27e}
200
4 {ok:true}
202
5 [{ok:true,id:bug,rev:1-59414e77c768bc202142ac82c2f129de}]
201
6 {error:not_found,reason:deleted}
404
CouchDB shouldn't report ok on step 5 and then go on to claim that the doc
is deleted. Also, it seems to work on second try:
7 curl -X POST $url -d '{_id: bug, key: value}'
8 curl -X GET $url/bug
7 {ok:true,id:bug,rev:3-674f864b73df1c80925e48436e21d550}
201
8 {_id:bug,_rev:3-674f864b73df1c80925e48436e21d550,key:value}
200
--
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-1402) Crash on Views - {'EXIT', {{badmatch, {error, {enoent, [{erlang,open_port,
[
https://issues.apache.org/jira/browse/COUCHDB-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13202197#comment-13202197
]
James Howe commented on COUCHDB-1402:
-
ENOENT is basically file not found. Looks like you've not installed couchdb
correctly and one of couchspawnkillable, couchjs.exe or main.js aren't in the
right place.
Windows installers can be found here if you're having trouble.
https://github.com/dch/couchdb/downloads
Crash on Views - {'EXIT', {{badmatch, {error, {enoent, [{erlang,open_port,
--
Key: COUCHDB-1402
URL: https://issues.apache.org/jira/browse/COUCHDB-1402
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 1.1.1
Environment: Windows Server 2003 R2 SP3
Reporter: Christopher Betz
Every time I go to access a view, I get this error, even from futon. I am
currently running Windows 2003 Server R3, SP3.
** Reason for termination ==
** {'EXIT',
{{badmatch,
{error,
{enoent,
[{erlang,open_port,
[{spawn,
c:/PROGRA~1/Apache Software
Foundation/CouchDB/lib/couch-1.1.1/priv/couchspawnkillable ./couchjs.exe
../share/couchdb/server/main.js},
[stream,{line,1024},binary,exit_status,hide]]},
{couch_os_process,init,1},
{gen_server,init_it,6},
{proc_lib,init_p_do_apply,3}]}}},
[{couch_query_servers,new_process,3},
{couch_query_servers,lang_proc,3},
{couch_query_servers,handle_call,3},
{gen_server,handle_msg,5},
{proc_lib,init_p_do_apply,3}]}}
[Mon, 06 Feb 2012 18:59:17 GMT] [error] [0.19625.0] {error_report,0.34.0,
{0.19625.0,crash_report,
[[{initial_call,{couch_file,init,['Argument__1']}},
{pid,0.19625.0},
{registered_name,[]},
{error_info,
{exit,
{'EXIT',
{{badmatch,
{error,
{enoent,
[{erlang,open_port,
[{spawn,
c:/PROGRA~1/Apache Software
Foundation/CouchDB/lib/couch-1.1.1/priv/couchspawnkillable ./couchjs.exe
../share/couchdb/server/main.js},
[stream,
{line,1024},
binary,exit_status,hide]]},
{couch_os_process,init,1},
{gen_server,init_it,6},
{proc_lib,init_p_do_apply,3}]}}},
[{couch_query_servers,new_process,3},
{couch_query_servers,lang_proc,3},
{couch_query_servers,handle_call,3},
{gen_server,handle_msg,5},
{proc_lib,init_p_do_apply,3}]}},
[{gen_server,terminate,6},
{proc_lib,init_p_do_apply,3}]}},
{ancestors,[0.19624.0,0.19623.0]},
{messages,[{'EXIT',0.19627.0,shutdown}]},
{links,[]},
{dictionary,[]},
{trap_exit,true},
{status,running},
{heap_size,987},
{stack_size,24},
{reductions,1331}],
[]]}}
--
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-1397) Function expressions, evals in SpiderMonkey
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13201180#comment-13201180
]
James Howe commented on COUCHDB-1397:
-
@Marcello - for unit testing you can do what CommonsJS does (and Jason points
to) in order to define the globals.
var map_runner = function (emit, log, sum) { + map_value + }
Function expressions, evals in SpiderMonkey
---
Key: COUCHDB-1397
URL: https://issues.apache.org/jira/browse/COUCHDB-1397
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 1.2.1
Environment: All
Reporter: Jason Smith
New SpiderMonkey releases do not eval() a sole anonymous function expression.
That is not a valid JavaScript statement, and so it is not a valid JavaScript
script.
COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for
1.2. (Sorry to spam COUCHDB-1302. I saw Unassigned and read Unresolved.)
--
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-1397) Function expressions, evals in SpiderMonkey
[ https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13199616#comment-13199616 ] James Howe commented on COUCHDB-1397: - For Paul's example alternatives, is it not a trivial operation to convert the old format to these internally before eval? Then users can do what they've always done (and don't have to worry about new ways to ty[po) and the SM-related problem is solved. Function expressions, evals in SpiderMonkey --- Key: COUCHDB-1397 URL: https://issues.apache.org/jira/browse/COUCHDB-1397 Project: CouchDB Issue Type: Bug Components: JavaScript View Server Affects Versions: 1.2.1 Environment: All Reporter: Jason Smith New SpiderMonkey releases do not eval() a sole anonymous function expression. That is not a valid JavaScript statement, and so it is not a valid JavaScript script. COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for 1.2. (Sorry to spam COUCHDB-1302. I saw Unassigned and read Unresolved.) -- 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-1397) Function expressions, evals in SpiderMonkey
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13199747#comment-13199747
]
James Howe commented on COUCHDB-1397:
-
There's nothing Invalid about this javascript: {map: function(doc) {}},
it's only the way it's used (i.e. blindly eval'd) that is invalid. A
source-to-source translation cold be s/\bfunction\(/function map(/.
IMO, it is the people writing {map: var d=1; function(doc) { emit(doc._id,
d);} that should find their code not working, as they are using undocumented
features.
If changes are to be made, I much prefer Benoit's suggestion - having doc be
implicit in the context and the value of map keys being function bodies.
emit already works like this, so makes no difference to JSLintability.
Function expressions, evals in SpiderMonkey
---
Key: COUCHDB-1397
URL: https://issues.apache.org/jira/browse/COUCHDB-1397
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 1.2.1
Environment: All
Reporter: Jason Smith
New SpiderMonkey releases do not eval() a sole anonymous function expression.
That is not a valid JavaScript statement, and so it is not a valid JavaScript
script.
COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for
1.2. (Sorry to spam COUCHDB-1302. I saw Unassigned and read Unresolved.)
--
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-1397) Function expressions, evals in SpiderMonkey
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13199892#comment-13199892
]
James Howe commented on COUCHDB-1397:
-
The string function(doc) {} *isnt* invalid JavaScript - it's just a string.
It only becomes an anonymous function at global scope if you pass it directly
to eval().
Function expressions, evals in SpiderMonkey
---
Key: COUCHDB-1397
URL: https://issues.apache.org/jira/browse/COUCHDB-1397
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 1.2.1
Environment: All
Reporter: Jason Smith
New SpiderMonkey releases do not eval() a sole anonymous function expression.
That is not a valid JavaScript statement, and so it is not a valid JavaScript
script.
COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for
1.2. (Sorry to spam COUCHDB-1302. I saw Unassigned and read Unresolved.)
--
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-1179) erl.exe crash during view indexing
[ https://issues.apache.org/jira/browse/COUCHDB-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13198705#comment-13198705 ] James Howe commented on COUCHDB-1179: - Deleted, cleaned-up, added and indexed all the views again - no crashes (last time I did this on 1.1 it went down twice). doc_count: 5287 doc_del_count: 196818 erl.exe crash during view indexing -- Key: COUCHDB-1179 URL: https://issues.apache.org/jira/browse/COUCHDB-1179 Project: CouchDB Issue Type: Bug Components: JavaScript View Server Affects Versions: 1.0.2, 1.1 Environment: Windows XP, 32-bit Reporter: James Howe Assignee: Dave Cottlehuber While querying new views consecutively, some of which are very large, erl.exe crashes. First few sections of the dump: =erl_crash_dump:0.1 Thu May 26 11:34:32 2011 Slogan: eheap_alloc: Cannot allocate 32097420 bytes of memory (of type old_heap). System version: Erlang R14B01 (erts-5.8.2) [source] [smp:4:4] [rq:4] [async-threads:0] Compiled: Fri Jan 21 22:17:42 2011 Taints: crypto Atoms: 9079 =memory total: 1566295328 processes: 1556974804 processes_used: 1556965252 system: 9320524 atom: 415297 atom_used: 397915 binary: 3483760 code: 3026978 ets: 1004308 =hash_table:atom_tab size: 6421 used: 4864 objs: 9079 depth: 7 =index_table:atom_tab size: 9216 limit: 1048576 entries: 9079 =hash_table:module_code size: 197 used: 126 objs: 165 depth: 3 =index_table:module_code size: 1024 limit: 65536 entries: 165 =hash_table:export_list size: 3203 used: 2268 objs: 3969 depth: 6 =index_table:export_list size: 4096 limit: 524288 entries: 3969 =hash_table:secondary_export_table size: 97 used: 0 objs: 0 depth: 0 =hash_table:process_reg size: 47 used: 34 objs: 56 depth: 3 =hash_table:fun_table size: 797 used: 543 objs: 921 depth: 6 =hash_table:node_table size: 11 used: 1 objs: 1 depth: 1 =hash_table:dist_table size: 11 used: 1 objs: 1 depth: 1 =allocated_areas sys_misc: 302763 static: 499712 atom_space: 131088 113730 atom_table: 62629 module_table: 4968 export_table: 29280 register_table: 252 fun_table: 3250 module_refs: 2048 loaded_code: 2735300 dist_table: 335 node_table: 131 bits_bufs_size: 0 bif_timer: 40172 link_lh: 0 proc: 288316 285116 atom_entry: 221580 221556 export_entry: 192660 192132 module_entry: 8740 8020 reg_proc: 1492 1396 monitor_sh: 41236 35556 nlink_sh: 40532 39956 fun_entry: 53044 51980 db_tab: 12532 10452 driver_event_data_state: 28 28 driver_select_data_state: 356 260 -- 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=13189058#comment-13189058
]
James Howe commented on COUCHDB-1381:
-
I think this is how you're supposed to do it, but I'm unable to test.
function alert(str) {
var msg = new Windows.UI.Popups.MessageDialog(str);
msg.showAsync().then();
}
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-326) Occasional {error:error,reason:eacces} errors deleting a database on Windows
[
https://issues.apache.org/jira/browse/COUCHDB-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13155769#comment-13155769
]
James Howe commented on COUCHDB-326:
Anti-Virus
Occasional {error:error,reason:eacces} errors deleting a database on
Windows
Key: COUCHDB-326
URL: https://issues.apache.org/jira/browse/COUCHDB-326
Project: CouchDB
Issue Type: Bug
Affects Versions: 0.9
Environment: Windows, couch 0.9, erlang R12B 5.6.5
Reporter: Mark Hammond
On Windows, occasionally you will see errors attempting to delete a database.
This manifests itself by 10-30% of the test suite failing on Windows. If
you retry the tests that failed, they will usually pass on subsequent
attempts. Running the tests individually causes them to fail roughly 10% of
the time.
The log output shown is:
[debug] [0.18650.6] httpd 500 error response:
{error:error,reason:eacces}
[info] [0.18650.6] 127.0.0.1 - - 'DELETE' /test_suite_db/ 500
A slightly snipped transcript from IRC:
(2:58:32 PM) markh: I see a number of INFO logs Shutting down view group
server, monitored db is closing. directly before the error. I was guessing
the file may be unlink'd before one of those workers actually closes its
handle?
(2:58:54 PM) alisdair: yeah, it's probably a race condition
(2:59:13 PM) alisdair: where the delete is tried before the fd is let go
(2:59:26 PM) alisdair: the reader fd that is
(2:59:32 PM) markh: yeah
...
(3:11:47 PM) alisdair: i can't find an obvious deadlock
(3:12:18 PM) alisdair: couch_server:delete explicitly waits for the db
process to exit
(3:12:23 PM) alisdair: before deleting it
(3:15:15 PM) alisdair: i think i found the problem
(3:15:23 PM) alisdair: but i need a windows machine to confirm
(3:15:30 PM) alisdair: i'll look into it tomorrow
--
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
