Re: [MERGE] 1676-feature-console_log
+1 On Feb 11, 2013, at 04:29 , Jason Smith j...@iriscouch.com wrote: This is cleaned up from my console_log branch. Add a test to confirm console.log and util.format() Document console.log() and util.format() Please check my code. -- Iris Couch
Re: [MERGE] 1677-feature-query_server_log_file
+1 On Feb 11, 2013, at 06:43 , Jason Smith j...@iriscouch.com wrote: See COUCHDB-1677. This is a feature for an optional secondary log file which is basically the output of JavaScript log() functions. No tests; I did not see any log etap log tests. However some of the JavaScript _log tests exercise (some of) this code. Documented the existence of _config/log/query_server_file and the ability to fetch /_log/query_server Please check my code. Thank you. -- Iris Couch
[ANN]: New Committers: Russell, Garren, Simon Mike
Hi all, I’m happy to announce the Fauxton team as new committers to the Apache CouchDB project. Please welcome Russell Branca, Garren Smith, Simon Metson and Mike West to the team! Woohoo! Jan --
Re: [ANN]: New Committers: Russell, Garren, Simon Mike
On Feb 11, 2013, at 13:42 , Jan Lehnardt j...@apache.org wrote: Hi all, I’m happy to announce the Fauxton team as new committers to the Apache CouchDB project. Please welcome Russell Branca, Garren Smith, Simon Metson and Mike West Mike Wallace! My apologies. (now, where is my coffee) Best Jan -- to the team! Woohoo! Jan --
[jira] [Commented] (COUCHDB-1675) User doc validation allows non-strings in roles array
[ https://issues.apache.org/jira/browse/COUCHDB-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13575778#comment-13575778 ] ASF subversion and git services commented on COUCHDB-1675: -- Commit 5f507095a0c7996391f6ca37a30fd0c4829b5e45 in branch refs/heads/master from [~rnewson] [ https://git-wip-us.apache.org/repos/asf?p=couchdb.git;h=5f50709 ] Only allow strings in user doc roles array We validate that _security documents only contain strings but we have not done the same for the roles field in user docs. This is a breaking change as users may have been inserting other things (notably, objects) in this field. COUCHDB-1675 User doc validation allows non-strings in roles array - Key: COUCHDB-1675 URL: https://issues.apache.org/jira/browse/COUCHDB-1675 Project: CouchDB Issue Type: Bug Reporter: Robert Newson -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-1675) User doc validation allows non-strings in roles array
[ https://issues.apache.org/jira/browse/COUCHDB-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Newson resolved COUCHDB-1675. Resolution: Fixed Fix Version/s: 1.4 must be noted in BREAKING_CHANGES, though. User doc validation allows non-strings in roles array - Key: COUCHDB-1675 URL: https://issues.apache.org/jira/browse/COUCHDB-1675 Project: CouchDB Issue Type: Bug Reporter: Robert Newson Fix For: 1.4 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [ANN]: New Committers: Russell, Garren, Simon Mike
Congratulations, all! On Mon, Feb 11, 2013 at 12:47 PM, Jan Lehnardt j...@apache.org wrote: On Feb 11, 2013, at 13:42 , Jan Lehnardt j...@apache.org wrote: Hi all, I’m happy to announce the Fauxton team as new committers to the Apache CouchDB project. Please welcome Russell Branca, Garren Smith, Simon Metson and Mike West Mike Wallace! My apologies. (now, where is my coffee) Best Jan -- to the team! Woohoo! Jan -- -- Iris Couch
In-browser debugging with Node.js couchjs
I just pushed more work in my nodejs_couchdb branch. I have a working in-browser GUI debugger. You can set breakpoints, step through code, inspect data values. This works for any JavaScript code CouchDB runs: map/reduce functions, validate_doc_update, filters, etc. I put up some quick screenshots and mp4 screencast to show what it's like: https://jhs.iriscouch.com/files/debugger/debug.html I would love to hear feedback from people. What are your thoughts? Me? I think it shows the power of Node.js. It shows possible opportunity cost if we do not use it. Thanks! -- Iris Couch
Re: In-browser debugging with Node.js couchjs
Hi Jason! Any possibility to have such feature for other query servers? -- ,,,^..^,,, On Mon, Feb 11, 2013 at 6:04 PM, Jason Smith j...@iriscouch.com wrote: I just pushed more work in my nodejs_couchdb branch. I have a working in-browser GUI debugger. You can set breakpoints, step through code, inspect data values. This works for any JavaScript code CouchDB runs: map/reduce functions, validate_doc_update, filters, etc. I put up some quick screenshots and mp4 screencast to show what it's like: https://jhs.iriscouch.com/files/debugger/debug.html I would love to hear feedback from people. What are your thoughts? Me? I think it shows the power of Node.js. It shows possible opportunity cost if we do not use it. Thanks! -- Iris Couch
Re: In-browser debugging with Node.js couchjs
All I am doing is using node-inspector, a web-based debugger. Any language with a web-based debugger could work. CouchDB just proxies requests to the debugger. So any language is possible. It's just that it was so easy with Node.js. On Mon, Feb 11, 2013 at 2:22 PM, Alexander Shorin kxe...@gmail.com wrote: Hi Jason! Any possibility to have such feature for other query servers? -- ,,,^..^,,, On Mon, Feb 11, 2013 at 6:04 PM, Jason Smith j...@iriscouch.com wrote: I just pushed more work in my nodejs_couchdb branch. I have a working in-browser GUI debugger. You can set breakpoints, step through code, inspect data values. This works for any JavaScript code CouchDB runs: map/reduce functions, validate_doc_update, filters, etc. I put up some quick screenshots and mp4 screencast to show what it's like: https://jhs.iriscouch.com/files/debugger/debug.html I would love to hear feedback from people. What are your thoughts? Me? I think it shows the power of Node.js. It shows possible opportunity cost if we do not use it. Thanks! -- Iris Couch -- Iris Couch
Re: In-browser debugging with Node.js couchjs
On Feb 11, 2013, at 15:04 , Jason Smith j...@iriscouch.com wrote: I just pushed more work in my nodejs_couchdb branch. I have a working in-browser GUI debugger. You can set breakpoints, step through code, inspect data values. This works for any JavaScript code CouchDB runs: map/reduce functions, validate_doc_update, filters, etc. I put up some quick screenshots and mp4 screencast to show what it's like: https://jhs.iriscouch.com/files/debugger/debug.html I would love to hear feedback from people. What are your thoughts? Me? I think it shows the power of Node.js. It shows possible opportunity cost if we do not use it. HOLY SHIT THIS IS HOT
Re: In-browser debugging with Node.js couchjs
Ah, so how it works. Brilliant! But am I right, that os_process_limit should be raised for it (long debug - long respond time) and there would be hard to locate bottlenecks with such technique? Probably, next evolution step should have profiler and frames stack tracer features with some backlog for post-analysis. -- ,,,^..^,,, On Mon, Feb 11, 2013 at 6:37 PM, Jason Smith j...@iriscouch.com wrote: All I am doing is using node-inspector, a web-based debugger. Any language with a web-based debugger could work. CouchDB just proxies requests to the debugger. So any language is possible. It's just that it was so easy with Node.js. On Mon, Feb 11, 2013 at 2:22 PM, Alexander Shorin kxe...@gmail.com wrote: Hi Jason! Any possibility to have such feature for other query servers? -- ,,,^..^,,, On Mon, Feb 11, 2013 at 6:04 PM, Jason Smith j...@iriscouch.com wrote: I just pushed more work in my nodejs_couchdb branch. I have a working in-browser GUI debugger. You can set breakpoints, step through code, inspect data values. This works for any JavaScript code CouchDB runs: map/reduce functions, validate_doc_update, filters, etc. I put up some quick screenshots and mp4 screencast to show what it's like: https://jhs.iriscouch.com/files/debugger/debug.html I would love to hear feedback from people. What are your thoughts? Me? I think it shows the power of Node.js. It shows possible opportunity cost if we do not use it. Thanks! -- Iris Couch -- Iris Couch -- ,,,^..^,,, On Mon, Feb 11, 2013 at 6:37 PM, Jason Smith j...@iriscouch.com wrote: All I am doing is using node-inspector, a web-based debugger. Any language with a web-based debugger could work. CouchDB just proxies requests to the debugger. So any language is possible. It's just that it was so easy with Node.js. On Mon, Feb 11, 2013 at 2:22 PM, Alexander Shorin kxe...@gmail.com wrote: Hi Jason! Any possibility to have such feature for other query servers? -- ,,,^..^,,, On Mon, Feb 11, 2013 at 6:04 PM, Jason Smith j...@iriscouch.com wrote: I just pushed more work in my nodejs_couchdb branch. I have a working in-browser GUI debugger. You can set breakpoints, step through code, inspect data values. This works for any JavaScript code CouchDB runs: map/reduce functions, validate_doc_update, filters, etc. I put up some quick screenshots and mp4 screencast to show what it's like: https://jhs.iriscouch.com/files/debugger/debug.html I would love to hear feedback from people. What are your thoughts? Me? I think it shows the power of Node.js. It shows possible opportunity cost if we do not use it. Thanks! -- Iris Couch -- Iris Couch
Re: In-browser debugging with Node.js couchjs
On 11 February 2013 15:22, Alexander Shorin kxe...@gmail.com wrote: Hi Jason! Any possibility to have such feature for other query servers? -- ,,,^..^,,, Maybe look at komodo IDE which has support for node and python XDBP protocols? A+ Dave
Re: In-browser debugging with Node.js couchjs
On Monday, February 11, 2013, Alexander Shorin wrote: Ah, so how it works. Brilliant! But am I right, that os_process_limit should be raised for it (long debug - long respond time) and there would be hard to locate bottlenecks with such technique? Probably, next evolution step should have profiler and frames stack tracer features with some backlog for post-analysis. right :) we definitely need an improved protocol to handle thzt and more concurrency. also maybe using websockets in most parts. benoît -- ,,,^..^,,, On Mon, Feb 11, 2013 at 6:37 PM, Jason Smith j...@iriscouch.comjavascript:; wrote: All I am doing is using node-inspector, a web-based debugger. Any language with a web-based debugger could work. CouchDB just proxies requests to the debugger. So any language is possible. It's just that it was so easy with Node.js. On Mon, Feb 11, 2013 at 2:22 PM, Alexander Shorin kxe...@gmail.comjavascript:; wrote: Hi Jason! Any possibility to have such feature for other query servers? -- ,,,^..^,,, On Mon, Feb 11, 2013 at 6:04 PM, Jason Smith j...@iriscouch.comjavascript:; wrote: I just pushed more work in my nodejs_couchdb branch. I have a working in-browser GUI debugger. You can set breakpoints, step through code, inspect data values. This works for any JavaScript code CouchDB runs: map/reduce functions, validate_doc_update, filters, etc. I put up some quick screenshots and mp4 screencast to show what it's like: https://jhs.iriscouch.com/files/debugger/debug.html I would love to hear feedback from people. What are your thoughts? Me? I think it shows the power of Node.js. It shows possible opportunity cost if we do not use it. Thanks! -- Iris Couch -- Iris Couch -- ,,,^..^,,, On Mon, Feb 11, 2013 at 6:37 PM, Jason Smith j...@iriscouch.comjavascript:; wrote: All I am doing is using node-inspector, a web-based debugger. Any language with a web-based debugger could work. CouchDB just proxies requests to the debugger. So any language is possible. It's just that it was so easy with Node.js. On Mon, Feb 11, 2013 at 2:22 PM, Alexander Shorin kxe...@gmail.comjavascript:; wrote: Hi Jason! Any possibility to have such feature for other query servers? -- ,,,^..^,,, On Mon, Feb 11, 2013 at 6:04 PM, Jason Smith j...@iriscouch.comjavascript:; wrote: I just pushed more work in my nodejs_couchdb branch. I have a working in-browser GUI debugger. You can set breakpoints, step through code, inspect data values. This works for any JavaScript code CouchDB runs: map/reduce functions, validate_doc_update, filters, etc. I put up some quick screenshots and mp4 screencast to show what it's like: https://jhs.iriscouch.com/files/debugger/debug.html I would love to hear feedback from people. What are your thoughts? Me? I think it shows the power of Node.js. It shows possible opportunity cost if we do not use it. Thanks! -- Iris Couch -- Iris Couch
Re: In-browser debugging with Node.js couchjs
I immediately think: is sandboxing a concern? Also, this is a test email to see if my MUA is configured correctly, please (mostly) ignore. -Joan On Mon, Feb 11, 2013 at 03:44:57PM +0100, Jan Lehnardt wrote: On Feb 11, 2013, at 15:04 , Jason Smith j...@iriscouch.com wrote: I just pushed more work in my nodejs_couchdb branch. I have a working in-browser GUI debugger. You can set breakpoints, step through code, inspect data values. This works for any JavaScript code CouchDB runs: map/reduce functions, validate_doc_update, filters, etc. I put up some quick screenshots and mp4 screencast to show what it's like: https://jhs.iriscouch.com/files/debugger/debug.html I would love to hear feedback from people. What are your thoughts? Me? I think it shows the power of Node.js. It shows possible opportunity cost if we do not use it. HOLY SHIT THIS IS HOT -- Joan Touzet | jo...@atypical.net | wohali everywhere else
Re: In-browser debugging with Node.js couchjs
woh...@apache.org :D :D also debugging yay On 11 February 2013 18:04, Joan Touzet woh...@apache.org wrote: I immediately think: is sandboxing a concern? Also, this is a test email to see if my MUA is configured correctly, please (mostly) ignore. -Joan On Mon, Feb 11, 2013 at 03:44:57PM +0100, Jan Lehnardt wrote: On Feb 11, 2013, at 15:04 , Jason Smith j...@iriscouch.com wrote: I just pushed more work in my nodejs_couchdb branch. I have a working in-browser GUI debugger. You can set breakpoints, step through code, inspect data values. This works for any JavaScript code CouchDB runs: map/reduce functions, validate_doc_update, filters, etc. I put up some quick screenshots and mp4 screencast to show what it's like: https://jhs.iriscouch.com/files/debugger/debug.html I would love to hear feedback from people. What are your thoughts? Me? I think it shows the power of Node.js. It shows possible opportunity cost if we do not use it. HOLY SHIT THIS IS HOT -- Joan Touzet | jo...@atypical.net | wohali everywhere else
[jira] [Created] (COUCHDB-1678) Seach in the documentation 404's
Dale Harvey created COUCHDB-1678: Summary: Seach in the documentation 404's Key: COUCHDB-1678 URL: https://issues.apache.org/jira/browse/COUCHDB-1678 Project: CouchDB Issue Type: Bug Components: Documentation Reporter: Dale Harvey Go to docs.couchdb.org (or .com) and do a search, it 404's http://docs.couchdb.com/en/latest/search.html?q=testcheck_keywords=yesarea=default -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (COUCHDB-1678) Seach in the documentation 404's
[ https://issues.apache.org/jira/browse/COUCHDB-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Cottlehuber reassigned COUCHDB-1678: - Assignee: Dave Cottlehuber Seach in the documentation 404's Key: COUCHDB-1678 URL: https://issues.apache.org/jira/browse/COUCHDB-1678 Project: CouchDB Issue Type: Bug Components: Documentation Reporter: Dale Harvey Assignee: Dave Cottlehuber Go to docs.couchdb.org (or .com) and do a search, it 404's http://docs.couchdb.com/en/latest/search.html?q=testcheck_keywords=yesarea=default -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1678) Seach in the documentation 404's
[ https://issues.apache.org/jira/browse/COUCHDB-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13576041#comment-13576041 ] Dave Cottlehuber commented on COUCHDB-1678: --- Thanks Dale. It looks like one of the changes we have made alters the way RTD is building the search interface. I suspect this might be in prettifying the URLs. Will look in more detail tomorrow. Seach in the documentation 404's Key: COUCHDB-1678 URL: https://issues.apache.org/jira/browse/COUCHDB-1678 Project: CouchDB Issue Type: Bug Components: Documentation Reporter: Dale Harvey Assignee: Dave Cottlehuber Go to docs.couchdb.org (or .com) and do a search, it 404's http://docs.couchdb.com/en/latest/search.html?q=testcheck_keywords=yesarea=default -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1678) Seach in the documentation 404's
[ https://issues.apache.org/jira/browse/COUCHDB-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13576046#comment-13576046 ] Dave Cottlehuber commented on COUCHDB-1678: --- EWORKSFORME on my dev branch https://couchdb-dev.readthedocs.org/en/latest/ from earlier code. This should be easy enough to track down now. Seach in the documentation 404's Key: COUCHDB-1678 URL: https://issues.apache.org/jira/browse/COUCHDB-1678 Project: CouchDB Issue Type: Bug Components: Documentation Reporter: Dale Harvey Assignee: Dave Cottlehuber Go to docs.couchdb.org (or .com) and do a search, it 404's http://docs.couchdb.com/en/latest/search.html?q=testcheck_keywords=yesarea=default -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1678) Seach in the documentation 404's
[ https://issues.apache.org/jira/browse/COUCHDB-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Cottlehuber updated COUCHDB-1678: -- Affects Version/s: 1.3 Seach in the documentation 404's Key: COUCHDB-1678 URL: https://issues.apache.org/jira/browse/COUCHDB-1678 Project: CouchDB Issue Type: Bug Components: Documentation Affects Versions: 1.3 Reporter: Dale Harvey Assignee: Dave Cottlehuber Go to docs.couchdb.org (or .com) and do a search, it 404's http://docs.couchdb.com/en/latest/search.html?q=testcheck_keywords=yesarea=default -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: In-browser debugging with Node.js couchjs
Very slick Jason, this is great! -Russell On Mon, Feb 11, 2013 at 10:05 AM, Robert Newson rnew...@apache.org wrote: woh...@apache.org :D :D also debugging yay On 11 February 2013 18:04, Joan Touzet woh...@apache.org wrote: I immediately think: is sandboxing a concern? Also, this is a test email to see if my MUA is configured correctly, please (mostly) ignore. -Joan On Mon, Feb 11, 2013 at 03:44:57PM +0100, Jan Lehnardt wrote: On Feb 11, 2013, at 15:04 , Jason Smith j...@iriscouch.com wrote: I just pushed more work in my nodejs_couchdb branch. I have a working in-browser GUI debugger. You can set breakpoints, step through code, inspect data values. This works for any JavaScript code CouchDB runs: map/reduce functions, validate_doc_update, filters, etc. I put up some quick screenshots and mp4 screencast to show what it's like: https://jhs.iriscouch.com/files/debugger/debug.html I would love to hear feedback from people. What are your thoughts? Me? I think it shows the power of Node.js. It shows possible opportunity cost if we do not use it. HOLY SHIT THIS IS HOT -- Joan Touzet | jo...@atypical.net | wohali everywhere else
[jira] [Commented] (COUCHDB-1651) Server responds 400 Exceeded rewrite recursion limit indefinitely
[
https://issues.apache.org/jira/browse/COUCHDB-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13576330#comment-13576330
]
Paul Frazee commented on COUCHDB-1651:
--
Another update as I work on this. I removed all root-level rewrites. Here are
my vhosts (I have multiple design documents in use):
{code}
grimwire.com/_browserid = /_browserid
grimwire.com/local = /grimwire/_design/local/_rewrite
grimwire.com/_changes = /grimwire/_changes
grimwire.com/assets = /grimwire/_design/assets/_rewrite
grimwire.com/email = /email/_design/email/_rewrite
grimwire.com= /grimwire/_design/grimwire/_rewrite
{code}
And here are the four rewrite jsons:
{code}
[
{
from:,
to:index.html,
method:GET
},
{
from:/posts,
to:_list/wallpost/wallpost-by-created_at,
method:GET
},
{
from:/posts,
to:_update/wallpost,
method:POST
},
{
from:/posts/:id,
to:_show/wallpost/:id,
method:GET
},
{
from:/posts/:id,
to:_update/wallpost/:id,
method:PUT
},
{
from:/types/:id,
to:_show/type/_design/local,
query:{type::id},
method:GET
},
{
from:/apps/*,
to:/apps/*
},
{
from:/assets/*,
to:/assets/*
},
{
from:/docs/*,
to:/docs/*
},
{
from:/lib/*,
to:/lib/*
}
]
{code}
[
{ from: , to: index.html, method: GET },
{ from: index.html, to: index.html, method: GET },
{ from: index.css, to: index.css, method: GET },
{ from: index.js, to: index.js, method: GET },
{ from: grim/*, to: grim/*, method: GET }
]
{code}
{code}
[
{
from:,
to:_update/message,
method:POST
},
{
from:,
to:../../,
method:GET
},
{
from:/:key,
to:../../:key,
method:GET
}
]
{code}
{code}
[
{
from: bootstrap/*,
to: bootstrap/*
},
{
from: fontello/*,
to: fontello/*
},
{
from:icons/*,
to: icons/*
}
]
{code}
I got suspicious of my vhosts (because one application is root-level) so I
moved that app to a subpath (grimwire.com/grim/). However, that didn't solve
the problem.
Usually, I can trigger the problem within 10-15 refreshes of a page (each of
which triggers 35 asset requests).
Server responds 400 Exceeded rewrite recursion limit indefinitely
---
Key: COUCHDB-1651
URL: https://issues.apache.org/jira/browse/COUCHDB-1651
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Reporter: Paul Frazee
Running 1.2.1 on Windows 7 as a service.
hosts file includes 127.0.0.1 grimwire.local
CouchDB conf includes vhosts entries:
grimwire.local:5984/grimwire/_design/grimwire/_rewrite
grimwire.local:5984/local /grimwire/_design/local/_rewrite
'grimwire' design doc rewrites:
[
{
from: ,
to: index.html,
method: GET
},
{
from: *,
to: *
}
]
'local' design doc rewrites:
[
{
from:,
to:index.html,
method:GET
},
{
from:/posts,
to:_list/wallpost/wallpost-by-created_at,
method:GET
},
{
from:/posts,
to:_update/wallpost,
method:POST
},
{
from:/posts/:id,
to:_show/wallpost/:id,
method:GET
},
{
from:/posts/:id,
to:_update/wallpost/:id,
method:PUT
},
{
from:*,
to:*
}
]
Problem:
The requests work as expected for some unknown period, then begin to respond
with a 400 status and the Exceeded rewrite recursion limit error message.
Changing the rewrites rules for both applications, including setting them to
empty arrays, had no effect.
The problem was solved by restarting the CouchDB service.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1651) Server responds 400 Exceeded rewrite recursion limit indefinitely
[
https://issues.apache.org/jira/browse/COUCHDB-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13576407#comment-13576407
]
Benoit Chesneau commented on COUCHDB-1651:
--
can you paste the debug log as well? It would help to figure when the first
crash happen.
Server responds 400 Exceeded rewrite recursion limit indefinitely
---
Key: COUCHDB-1651
URL: https://issues.apache.org/jira/browse/COUCHDB-1651
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Reporter: Paul Frazee
Running 1.2.1 on Windows 7 as a service.
hosts file includes 127.0.0.1 grimwire.local
CouchDB conf includes vhosts entries:
grimwire.local:5984/grimwire/_design/grimwire/_rewrite
grimwire.local:5984/local /grimwire/_design/local/_rewrite
'grimwire' design doc rewrites:
[
{
from: ,
to: index.html,
method: GET
},
{
from: *,
to: *
}
]
'local' design doc rewrites:
[
{
from:,
to:index.html,
method:GET
},
{
from:/posts,
to:_list/wallpost/wallpost-by-created_at,
method:GET
},
{
from:/posts,
to:_update/wallpost,
method:POST
},
{
from:/posts/:id,
to:_show/wallpost/:id,
method:GET
},
{
from:/posts/:id,
to:_update/wallpost/:id,
method:PUT
},
{
from:*,
to:*
}
]
Problem:
The requests work as expected for some unknown period, then begin to respond
with a 400 status and the Exceeded rewrite recursion limit error message.
Changing the rewrites rules for both applications, including setting them to
empty arrays, had no effect.
The problem was solved by restarting the CouchDB service.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
