Re: SpiderMonkey Version Support
On Wed, Jun 29, 2011 at 01:08, Paul Davis paul.joseph.da...@gmail.com wrote: *Nothing* should change on anything that isn't trunk. You mean that 1.1 will never support SpiderMonkey 1.8.5? That would kind of suck. Since 1.2 isn't more than a reference to trunk, there's not much (IMO) keeping us from dropping our support for everything pre-1.8.5 (except being nice to users I guess). Doesn't that depend on when 1.2 comes out? 1.8.5 is not that old. Cheers, Dirkjan
Re: SpiderMonkey Version Support
On 29 Jun 2011, at 01:06, Randall Leeds wrote: On Tue, Jun 28, 2011 at 15:54, Paul Davis paul.joseph.da...@gmail.com wrote: On Tue, Jun 28, 2011 at 6:41 PM, Randall Leeds rand...@apache.org wrote: I recently committed a patch from Chris Coulson to support the new 1.8.5 release of SpiderMonkey[1]. While some effort was put into supporting the breaking changes from 1.8.5 and it's been verified that the new trunk couchjs builds against the rest of the 1.8 series, Bob Dionne discovered that compatibility with 1.7 is now broken. davisp You dropped support for 1.7? tilgovi davisp: apparenty! tilgovi what's the 1.0.x branch say in INSTALL.*? davisp tilgovi: On purpose though? tilgovi no davisp I'm really confused tilgovi not on purpose davisp 1.7 I'm guessing tilgovi also, I didn't backport this tilgovi so, this is only on trunk davisp 1.8 davisp I guess its lying tilgovi I guess it's lying. davisp tilgovi: Sure, I would've screamed at yo otherwise tilgovi thoughts on not bothering to try and support 1.7? davisp tilgovi: I'm of two minds on whether I want to drop 1.7 support tilgovi might be super easy davisp But I think jan said he wanted 1.7 support in 1.2 so I said, k So 1.0.x, 1.1.x and trunk all seem to say we require SpiderMonkey 1.8, but up until this patch couchjs ran against 1.7. Should I back out the patch and try to fix compatibility with 1.7 or not bother? -Randall [1] https://github.com/apache/couchdb/commit/7b0f330627c9f3ef1ccb9e3ffe1e909e3a27f1bf I would say if you think its close that you should try and make it compatible with 1.7 again. I wouldn't immediately jump to backing it out unless you think it'll take a significant amount of time to bring back compatibility with 1.7. Good point. I won't back it out, but please give me your opinions here. I think it'd be fairly easy. On the other hand, if people want to dump 1.7 support I would vote in favor of dropping support for everything before 1.8.5. The source to couchjs would be greatly simplified and everything between 1.7 and 1.8.5 was never really an official SM release. However, this is a *really* good point. If there really hasn't been an official release since 1.7 I'd like to support it. We'll continue to support 1.1.x until 1.3 (2.0?) is out, so maybe it's okay to let that be the SM 1.7-compatible line and bump to 1.8.5 for CouchDB 1.2. While 1.7-1.8.5 wasn't really anything official, some distributions rolled their own releases. We shouldn't ignore that reality and I'd like to see 1.7 compat in trunk/1.2.0 unless it is proven that it is major effort. Cheers Jan --
Re: [Couchdb Wiki] Update of CouchDB_in_the_wild by PaulDavis
On 29 Jun 2011, at 01:43, Chris Anderson wrote: On Tue, Jun 28, 2011 at 8:54 AM, Noah Slater nsla...@apache.org wrote: On 28 Jun 2011, at 16:00, Apache Wiki wrote: - * [[http://www.weddingdjmelbourne.com/|weddings DJ Melbourne]] WDM is a DJ service. We use CouchDB in our database. Wow. So, the spammers are actually reading the warning at the top of the page, and then pretending to use CouchDB in [their] database. Kind of makes me want to just give trying. If you're reading this, Mr. Spamy McSpamface, Y U NO INSTALL SUM ETHICS IN UR DATABASE ASWEL? Noah I have a present for you: http://200967.spreadshirt.com/men-s-heavyweight-t-shirt-A7726440/customize/color/1 ^^^-- Are you saying Noah is fat?
Re: Spam on the wiki (CouchDB in the Wild contributors, please read this)
On 18 Jun 2011, at 09:01, Benoit Chesneau wrote: On Sat, Jun 18, 2011 at 1:56 AM, Chris Anderson jch...@apache.org wrote: On Fri, Jun 17, 2011 at 8:55 AM, Noah Slater nsla...@apache.org wrote: On 17 Jun 2011, at 16:49, Benoit Chesneau wrote: I meant if the number of projects continue to grow, how we can handled that with out the scrolling effect. Not sure what you mean, sorry. When the CouchDB in the Wild Page gets so long that browsers can't render it, Damien can be a proud papa indeed. :) Chris It will be just enough long when anyone will have added their 2 lines. If we can find a way to skip any scrolling that would be the best, though I'm pretty sure we can't do that with the current wiki. Can we have some js in ? We could start inventing some categories and have in-page links and anchors to make things a little more organised when this page gets too long. Cheers Jan --
Re: [Couchdb Wiki] Update of CouchDB_in_the_wild by PaulDavis
On 29 Jun 2011, at 10:42, Jan Lehnardt wrote: Noah I have a present for you: http://200967.spreadshirt.com/men-s-heavyweight-t-shirt-A7726440/customize/color/1 ^^^-- Are you saying Noah is fat? Does my database look big in this?
[jira] [Created] (COUCHDB-1205) Password of a pull-replicated db shown in stack trace
Password of a pull-replicated db shown in stack trace - Key: COUCHDB-1205 URL: https://issues.apache.org/jira/browse/COUCHDB-1205 Project: CouchDB Issue Type: Bug Reporter: Jaakko Sipari Attachments: couchdb_passwd_log_entry.txt The full url (with username password) of a pull-replicated database can be displayed in the erlang stack trace. This can be problematic when the the party reading the logs for analysis purposes should not know/get the credentials. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1205) Password of a pull-replicated db shown in stack trace
[ https://issues.apache.org/jira/browse/COUCHDB-1205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaakko Sipari updated COUCHDB-1205: --- Attachment: couchdb_passwd_log_entry.txt Password of a pull-replicated db shown in stack trace - Key: COUCHDB-1205 URL: https://issues.apache.org/jira/browse/COUCHDB-1205 Project: CouchDB Issue Type: Bug Reporter: Jaakko Sipari Attachments: couchdb_passwd_log_entry.txt The full url (with username password) of a pull-replicated database can be displayed in the erlang stack trace. This can be problematic when the the party reading the logs for analysis purposes should not know/get the credentials. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1205) Password of a pull-replicated db shown in stack trace
[ https://issues.apache.org/jira/browse/COUCHDB-1205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057178#comment-13057178 ] Filipe Manana commented on COUCHDB-1205: Which Couch version is it? Password of a pull-replicated db shown in stack trace - Key: COUCHDB-1205 URL: https://issues.apache.org/jira/browse/COUCHDB-1205 Project: CouchDB Issue Type: Bug Reporter: Jaakko Sipari Attachments: couchdb_passwd_log_entry.txt The full url (with username password) of a pull-replicated database can be displayed in the erlang stack trace. This can be problematic when the the party reading the logs for analysis purposes should not know/get the credentials. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1205) Password of a pull-replicated db shown in stack trace
[ https://issues.apache.org/jira/browse/COUCHDB-1205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057187#comment-13057187 ] Jaakko Sipari commented on COUCHDB-1205: We are running CouchDB 1.0.1. Sorry I forgot to mention it. Password of a pull-replicated db shown in stack trace - Key: COUCHDB-1205 URL: https://issues.apache.org/jira/browse/COUCHDB-1205 Project: CouchDB Issue Type: Bug Reporter: Jaakko Sipari Attachments: couchdb_passwd_log_entry.txt The full url (with username password) of a pull-replicated database can be displayed in the erlang stack trace. This can be problematic when the the party reading the logs for analysis purposes should not know/get the credentials. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-994) Crash after compacting large views
[ https://issues.apache.org/jira/browse/COUCHDB-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057188#comment-13057188 ] Geir Ove Grønmo commented on COUCHDB-994: - I had the same problem with one of my databases (CouchDB 1.0.1). I was able to work around the problem doing the following: 0. compaction failed 1. sudo /etc/init.d/couchdb stop 2. mv /var/lib/couchdb/mydb.couch.compact /tmp 3. sudo /etc/init.d/couchdb start 4. run compaction again (now it works) Crash after compacting large views -- Key: COUCHDB-994 URL: https://issues.apache.org/jira/browse/COUCHDB-994 Project: CouchDB Issue Type: Bug Affects Versions: 1.0.2 Environment: Centos5 64bit vm with 2CPU and 4G RAM running Erlang R14B and configured to use the 64bit js-devel libraries. URL: http://svn.apache.org/repos/asf/couchdb/branches/1.0.x Repository Root: http://svn.apache.org/repos/asf Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 1050680 Reporter: Bob Clary Fix For: 1.1.1, 1.2 Attachments: 2011-06-11-couchdb.log, 2011-06-13-couchdb.log, 2011-06-15-2-couchdb.log, 2011-06-15-couchdb.log, 2011-06-16-couchdb.log, couch_errors.txt, couch_errors_2.txt, couchdb-994-db-open-logic-11x.patch, couchdb-994-db-open-logic.patch The database has over 9 million records. Several of the views are relatively dense in that they emit a key for most documents. The views are successfully created initially but with relatively large sizes from 20 to 95G. When attempting to compact them, the server will crash upon completion of the compaction. This does not occur with the released 1.0.1 version but does with the 1.0.x svn version. I'll attach example logs. Unfortunately they are level error and may not have enough information. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1205) Password of a pull-replicated db shown in stack trace
[ https://issues.apache.org/jira/browse/COUCHDB-1205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaakko Sipari updated COUCHDB-1205: --- Affects Version/s: 1.0.1 Password of a pull-replicated db shown in stack trace - Key: COUCHDB-1205 URL: https://issues.apache.org/jira/browse/COUCHDB-1205 Project: CouchDB Issue Type: Bug Affects Versions: 1.0.2 Reporter: Jaakko Sipari Attachments: couchdb_passwd_log_entry.txt The full url (with username password) of a pull-replicated database can be displayed in the erlang stack trace. This can be problematic when the the party reading the logs for analysis purposes should not know/get the credentials. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
waitForRestart() double request()
Heya,
I may be missing something, but our weitForRestart() function seems to have an
accidental line duplication:
function waitForRestart() {
var waiting = true;
while (waiting) {
try {
CouchDB.request(GET, /);
CouchDB.request(GET, /);
waiting = false;
} catch(e) {
// the request will fail until restart completes
}
}
};
If this is intentional, I'd like to know what the intent here is :)
Cheers
Jan
--
Re: SpiderMonkey Version Support
On Wed, Jun 29, 2011 at 4:14 AM, Dirkjan Ochtman dirk...@ochtman.nl wrote: On Wed, Jun 29, 2011 at 01:08, Paul Davis paul.joseph.da...@gmail.com wrote: *Nothing* should change on anything that isn't trunk. You mean that 1.1 will never support SpiderMonkey 1.8.5? That would kind of suck. Its a fairly non-trivial patch as demonstrated by how long it took to even get into trunk. I don't think its proper fodder for a bug fix release. Also, not supporting 1.8.5 will motivate people to upgrade CouchDB as well. Since 1.2 isn't more than a reference to trunk, there's not much (IMO) keeping us from dropping our support for everything pre-1.8.5 (except being nice to users I guess). Doesn't that depend on when 1.2 comes out? 1.8.5 is not that old. Cheers, Dirkjan
Re: SpiderMonkey Version Support
On Wed, Jun 29, 2011 at 5:41 AM, Jan Lehnardt j...@apache.org wrote: On 29 Jun 2011, at 01:06, Randall Leeds wrote: On Tue, Jun 28, 2011 at 15:54, Paul Davis paul.joseph.da...@gmail.com wrote: On Tue, Jun 28, 2011 at 6:41 PM, Randall Leeds rand...@apache.org wrote: I recently committed a patch from Chris Coulson to support the new 1.8.5 release of SpiderMonkey[1]. While some effort was put into supporting the breaking changes from 1.8.5 and it's been verified that the new trunk couchjs builds against the rest of the 1.8 series, Bob Dionne discovered that compatibility with 1.7 is now broken. davisp You dropped support for 1.7? tilgovi davisp: apparenty! tilgovi what's the 1.0.x branch say in INSTALL.*? davisp tilgovi: On purpose though? tilgovi no davisp I'm really confused tilgovi not on purpose davisp 1.7 I'm guessing tilgovi also, I didn't backport this tilgovi so, this is only on trunk davisp 1.8 davisp I guess its lying tilgovi I guess it's lying. davisp tilgovi: Sure, I would've screamed at yo otherwise tilgovi thoughts on not bothering to try and support 1.7? davisp tilgovi: I'm of two minds on whether I want to drop 1.7 support tilgovi might be super easy davisp But I think jan said he wanted 1.7 support in 1.2 so I said, k So 1.0.x, 1.1.x and trunk all seem to say we require SpiderMonkey 1.8, but up until this patch couchjs ran against 1.7. Should I back out the patch and try to fix compatibility with 1.7 or not bother? -Randall [1] https://github.com/apache/couchdb/commit/7b0f330627c9f3ef1ccb9e3ffe1e909e3a27f1bf I would say if you think its close that you should try and make it compatible with 1.7 again. I wouldn't immediately jump to backing it out unless you think it'll take a significant amount of time to bring back compatibility with 1.7. Good point. I won't back it out, but please give me your opinions here. I think it'd be fairly easy. On the other hand, if people want to dump 1.7 support I would vote in favor of dropping support for everything before 1.8.5. The source to couchjs would be greatly simplified and everything between 1.7 and 1.8.5 was never really an official SM release. However, this is a *really* good point. If there really hasn't been an official release since 1.7 I'd like to support it. We'll continue to support 1.1.x until 1.3 (2.0?) is out, so maybe it's okay to let that be the SM 1.7-compatible line and bump to 1.8.5 for CouchDB 1.2. While 1.7-1.8.5 wasn't really anything official, some distributions rolled their own releases. We shouldn't ignore that reality and I'd like to see 1.7 compat in trunk/1.2.0 unless it is proven that it is major effort. Cheers Jan -- http://www.youtube.com/watch?v=W8qcccZy03s
Re: SpiderMonkey Version Support
On 29 Jun 2011, at 18:12, Paul Davis wrote: On Wed, Jun 29, 2011 at 4:14 AM, Dirkjan Ochtman dirk...@ochtman.nl wrote: On Wed, Jun 29, 2011 at 01:08, Paul Davis paul.joseph.da...@gmail.com wrote: *Nothing* should change on anything that isn't trunk. You mean that 1.1 will never support SpiderMonkey 1.8.5? That would kind of suck. Its a fairly non-trivial patch as demonstrated by how long it took to even get into trunk. I don't think its proper fodder for a bug fix release. Also, not supporting 1.8.5 will motivate people to upgrade CouchDB as well. Except if people have trouble installing / upgrading CouchDB, it leaves a bad taste. I'd rather not put users between a rock (1.7-based SpiderMonkey version) and a hard place (CouchDB only supporting 1.8.5 and up) Cheers Jan -- Since 1.2 isn't more than a reference to trunk, there's not much (IMO) keeping us from dropping our support for everything pre-1.8.5 (except being nice to users I guess). Doesn't that depend on when 1.2 comes out? 1.8.5 is not that old. Cheers, Dirkjan
Re: SpiderMonkey Version Support
On Wed, Jun 29, 2011 at 18:46, Jan Lehnardt j...@apache.org wrote: Except if people have trouble installing / upgrading CouchDB, it leaves a bad taste. I'd rather not put users between a rock (1.7-based SpiderMonkey version) and a hard place (CouchDB only supporting 1.8.5 and up) Right. Also, if 1.2 takes a long time in coming (like some of the previous releases), it would be nice if we'd get to use the state of the art in JS sooner. Cheers, Dirkjan
[jira] [Created] (COUCHDB-1206) View ETags may be incorrect if ?include_docs=true is specified
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 Priority: Minor 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. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: SpiderMonkey Version Support
On Wed, Jun 29, 2011 at 11:53, Dirkjan Ochtman dirk...@ochtman.nl wrote: On Wed, Jun 29, 2011 at 18:46, Jan Lehnardt j...@apache.org wrote: Except if people have trouble installing / upgrading CouchDB, it leaves a bad taste. I'd rather not put users between a rock (1.7-based SpiderMonkey version) and a hard place (CouchDB only supporting 1.8.5 and up) Right. Also, if 1.2 takes a long time in coming (like some of the previous releases), it would be nice if we'd get to use the state of the art in JS sooner. Cheers, Dirkjan I'm going to go forward with the following plan: 1) Make trunk compatible with SpiderMonkey 1.7 again. 2) Leave 1.1.x alone.* Let me know if this presents to anyone as egregiously offensive. * I'm sorry if this annoys anyone, but I don't want to backport something that isn't a bug fix. That's just how it's going to be. 50% policy, 50% time.
[jira] [Assigned] (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:all-tabpanel ] Robert Newson reassigned COUCHDB-1206: -- Assignee: Robert Newson 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. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (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:all-tabpanel ] Robert Newson updated COUCHDB-1206: --- Fix Version/s: 1.2 1.1.1 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. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-1171) Multiple requests to _changes feed causes {error, system_limit} Too many processes
[
https://issues.apache.org/jira/browse/COUCHDB-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Newson resolved COUCHDB-1171.
Resolution: Fixed
Multiple requests to _changes feed causes {error, system_limit} Too many
processes
Key: COUCHDB-1171
URL: https://issues.apache.org/jira/browse/COUCHDB-1171
Project: CouchDB
Issue Type: Bug
Affects Versions: 1.0.2, 1.1, 1.0.3
Reporter: Alexander Shorin
Assignee: Robert Newson
Fix For: 1.0.3, 1.2, 1.1
Attachments: couchdb-changes-stats-process-leak-test.js,
couchdb-changes-stats-process-leak.patch
Originally I have investigated of issue 182 of couchdb-python package where
calling db.changes() function over 32768 times generates next messages in
CouchDB log:
[Thu, 19 May 2011 14:03:26 GMT] [info] [0.2909.0] 127.0.0.1 - - 'GET'
/test/_changes 200
[Thu, 19 May 2011 14:03:26 GMT] [error] [emulator] Too many processes
[Thu, 19 May 2011 14:03:26 GMT] [error] [0.2909.0] Uncaught error in HTTP
request: {error,system_limit}
[Thu, 19 May 2011 14:03:26 GMT] [info] [0.2909.0] Stacktrace:
[{erlang,spawn,
[erlang,apply,
[#Funcouch_stats_collector.1.123391259,[]]]},
{erlang,spawn,1},
{couch_httpd_db,handle_changes_req,2},
{couch_httpd_db,do_db_req,2},
{couch_httpd,handle_request_int,5},
{mochiweb_http,headers,5},
{proc_lib,init_p_do_apply,3}]
[Thu, 19 May 2011 14:03:26 GMT] [info] [0.2909.0] 127.0.0.1 - - 'GET'
/test/_changes 500
More info about this issue could be found there:
http://code.google.com/p/couchdb-python/issues/detail?id=182
However, I still couldn't reproduce this error using only httplib module, but
I've got that same behavior using feed=longpool option:
from httplib import HTTPConnection
def test2():
conn = HTTPConnection('localhost:5984')
conn.connect()
i = 0
while(True):
conn.putrequest('GET', '/test/_changes?feed=longpool')
conn.endheaders()
conn.getresponse().read()
i = i + 1
if i % 100 == 0:
print i
When i get's around 32667 exception raises
Traceback (most recent call last):
File /home/kxepal/projects/couchdb-python/issue-182/test.py, line 259, in
module
test2()
File /home/kxepal/projects/couchdb-python/issue-182/test.py, line 239, in
test2
resp.read()
File /usr/lib/python2.6/httplib.py, line 522, in read
return self._read_chunked(amt)
File /usr/lib/python2.6/httplib.py, line 565, in _read_chunked
raise IncompleteRead(''.join(value))
httplib.IncompleteRead: IncompleteRead(0 bytes read)
[Thu, 19 May 2011 14:10:20 GMT] [info] [0.3240.4] 127.0.0.1 - - 'GET'
/test/_changes?feed=longpool 200
[Thu, 19 May 2011 14:10:20 GMT] [error] [emulator] Too many processes
[Thu, 19 May 2011 14:10:20 GMT] [error] [0.3240.4] Uncaught error in HTTP
request: {error,system_limit}
[Thu, 19 May 2011 14:10:20 GMT] [info] [0.3240.4] Stacktrace:
[{erlang,spawn,
[erlang,apply,
[#Funcouch_stats_collector.1.123391259,[]]]},
{erlang,spawn,1},
{couch_httpd_db,handle_changes_req,2},
{couch_httpd_db,do_db_req,2},
{couch_httpd,handle_request_int,5},
{mochiweb_http,headers,5},
{proc_lib,init_p_do_apply,3}]
[Thu, 19 May 2011 14:10:20 GMT] [info] [0.3240.4] 127.0.0.1 - - 'GET'
/test/_changes?feed=longpool 500
Same error. I know, that test function is quite outside from real use case,
but is this correct behavior and couldn't it be used in malicious aims?
This exception occurres only for multiple requests within single connection
for changes feed, chunked lists or attachments are not affected, if I've done
all right.
Test environment:
Gentoo Linux 2.6.38
CouchDB 1.0.2 release
couchdb-python@63feefd9e3b6
Python 2.6.6
If there is needed some additional information I could try to provide it.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1197) trunk no longer builds on Windows
[ https://issues.apache.org/jira/browse/COUCHDB-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Cottlehuber updated COUCHDB-1197: -- Attachment: (was: COUCHDB-1197_fix_ejson_v2.patch) trunk no longer builds on Windows - Key: COUCHDB-1197 URL: https://issues.apache.org/jira/browse/COUCHDB-1197 Project: CouchDB Issue Type: Bug Components: Build System, JavaScript View Server Environment: Windows 7 Enterprise x64 Cygwin MS Visual Studio 2008 Express Reporter: Dave Cottlehuber Labels: cygwin, windows Fix For: 1.2 ./configure fails - can no longer correctly find libcurl (after COUCHDB-1042) and instead compiles against cygwin's curl which is *bad*. Patch attached to resolve this. - finds jsapi.h correctly but can no longer use it. Work by dch to identify when it broke and how to fix this underway. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1197) trunk no longer builds on Windows
[ https://issues.apache.org/jira/browse/COUCHDB-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Cottlehuber updated COUCHDB-1197: -- Attachment: (was: COUCHDB-1197_fix_ejson.patch) trunk no longer builds on Windows - Key: COUCHDB-1197 URL: https://issues.apache.org/jira/browse/COUCHDB-1197 Project: CouchDB Issue Type: Bug Components: Build System, JavaScript View Server Environment: Windows 7 Enterprise x64 Cygwin MS Visual Studio 2008 Express Reporter: Dave Cottlehuber Labels: cygwin, windows Fix For: 1.2 ./configure fails - can no longer correctly find libcurl (after COUCHDB-1042) and instead compiles against cygwin's curl which is *bad*. Patch attached to resolve this. - finds jsapi.h correctly but can no longer use it. Work by dch to identify when it broke and how to fix this underway. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1197) trunk no longer builds on Windows
[ https://issues.apache.org/jira/browse/COUCHDB-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Cottlehuber updated COUCHDB-1197: -- Attachment: (was: COUCHDB-1197_fix_libcurl.patch) trunk no longer builds on Windows - Key: COUCHDB-1197 URL: https://issues.apache.org/jira/browse/COUCHDB-1197 Project: CouchDB Issue Type: Bug Components: Build System, JavaScript View Server Environment: Windows 7 Enterprise x64 Cygwin MS Visual Studio 2008 Express Reporter: Dave Cottlehuber Labels: cygwin, windows Fix For: 1.2 ./configure fails - can no longer correctly find libcurl (after COUCHDB-1042) and instead compiles against cygwin's curl which is *bad*. Patch attached to resolve this. - finds jsapi.h correctly but can no longer use it. Work by dch to identify when it broke and how to fix this underway. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1197) trunk no longer builds on Windows
[ https://issues.apache.org/jira/browse/COUCHDB-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Cottlehuber updated COUCHDB-1197: -- Attachment: COUCHDB-1197_fix_snappy_v3.patch COUCHDB-1197_fix_libcurl_v3.patch COUCHDB-1197_fix_includes_v3.patch COUCHDB-1197_fix_ejson_v3.patch COUCHDB-1197_fix_icu_v3.patch Needs to be applied in order: icu ejson libcurl snappy includes trunk no longer builds on Windows - Key: COUCHDB-1197 URL: https://issues.apache.org/jira/browse/COUCHDB-1197 Project: CouchDB Issue Type: Bug Components: Build System, JavaScript View Server Environment: Windows 7 Enterprise x64 Cygwin MS Visual Studio 2008 Express Reporter: Dave Cottlehuber Labels: cygwin, windows Fix For: 1.2 Attachments: COUCHDB-1197_fix_ejson_v3.patch, COUCHDB-1197_fix_icu_v3.patch, COUCHDB-1197_fix_includes_v3.patch, COUCHDB-1197_fix_libcurl_v3.patch, COUCHDB-1197_fix_snappy_v3.patch ./configure fails - can no longer correctly find libcurl (after COUCHDB-1042) and instead compiles against cygwin's curl which is *bad*. Patch attached to resolve this. - finds jsapi.h correctly but can no longer use it. Work by dch to identify when it broke and how to fix this underway. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: MapServer and CouchDB
Norman, I'd suggest looking at Paul Davis's write up of the externals API. It is designed to do 2 things well: * keep a background process alive, usually an HTTP server * proxy requests to that HTTP server http://davispj.com/2010/09/26/new-couchdb-externals-api.html I'm not sure if you'd be able to build your Map Server using exactly these APIs, but if you can you'll gain the benefits of less custom code. Or at least it may provide inspiration for how to integrate. Chris On Tue, Jun 28, 2011 at 11:51 AM, Norman Barker norman.bar...@gmail.com wrote: Hi, I am planning to wrap MapServer as a supervised process within CouchDB using Erlang. MapServer is a CGI application, it should be straightforward. The aim will be to store the MapServer map files (just text docs) that can passed in with every CGI call as JSON docs within CouchDB. The hook will be be register MapServer as an external process within CouchDB. If someone has already thought of this then let me know, I see GDAL has support for CouchDB as a client driver (using http though) so serving geojson through MapServer WFS or rendering over WMS should be possible. Let me know if you are interested, I should have some available for review middle of next week, I am just sounding out for now. The Erlang method of communication to C/C++ over stdio fits (in my mind) perfectly with the existing MapServer CGI model. GeoCouch can then be a supported backend of MapServer. cc'd Frank and Even rather than cross-posting as they seem to have some couch interest. thanks, Norman -- Chris Anderson http://jchrisa.net http://couchbase.com
Re: waitForRestart() double request()
On Wed, Jun 29, 2011 at 9:07 AM, Paul Davis paul.joseph.da...@gmail.com wrote:
On Wed, Jun 29, 2011 at 9:45 AM, Jan Lehnardt j...@apache.org wrote:
Heya,
I may be missing something, but our weitForRestart() function seems to have
an accidental line duplication:
That whole spot is gnarly. I did the double GET thing because it
seemed to work with it better than without it. If no one detects a
problem after removing it, then we should drop it.
Chris
function waitForRestart() {
var waiting = true;
while (waiting) {
try {
CouchDB.request(GET, /);
CouchDB.request(GET, /);
waiting = false;
} catch(e) {
// the request will fail until restart completes
}
}
};
If this is intentional, I'd like to know what the intent here is :)
Cheers
Jan
--
Someone's sick idea of a sleep statement?
FWIW, it's been doubled up since it was committed a long time ago:
https://github.com/apache/couchdb/commit/ed7e7c686fae7f1d2e3f149c2f2ed8854c4f95c8#L0R152
--
Chris Anderson
http://jchrisa.net
http://couchbase.com
