Maybe this problem is trivial, hence the lack of response :-) Anyway, I think I have found the root cause:
The view function fails to send a change because the socket is closed. This is because we use the changes feed just as a trigger, closing it when we recieve the first change. The connection is closed when subsequent changes are evaluated and the stacktrace shows up in the log. /Henrik On Thu, Jan 12, 2012 at 2:13 PM, Henrik Lundgren <[email protected]> wrote: > We are seeing the stacktrace below quite frequently on our production servers: > > [Thu, 12 Jan 2012 08:43:38 GMT] [info] [<0.16217.138>] 10.21.39.2 - - > 'POST' /inbox_db/_bulk_docs 201 > > [Thu, 12 Jan 2012 08:43:38 GMT] [error] [<0.16095.138>] Uncaught error > in HTTP request: {error,{case_clause,{error,enotconn}}} > > [Thu, 12 Jan 2012 08:43:38 GMT] [info] [<0.16095.138>] Stacktrace: > [{mochiweb_request,get,2}, > {couch_httpd_external,json_req_obj,3}, > {couch_query_servers,filter_docs,5}, > {couch_changes,'-make_filter_fun/4-fun-1-',6}, > {couch_changes,changes_enumerator,2}, > {couch_btree,stream_kv_node2,8}, > {couch_btree,stream_kp_node,8}, > {couch_btree,fold,4}] > > The bulk operation succeeds (201) but the stacktraces are worrying. > The application subsequently tries to save a document in another > database on the same couchdb instance. > That request fails with a dropped connection every so often. > > We have a changes feed that also fails frequently: > 'GET' > /inbox_db/_changes?feed=continuous&since=79362&filter=StandardRecordHeader%2Funprocessed_files&heartbeat=9000 > 500 > > Here's the filter function: > > function(doc) { return doc.state === void 0 && doc._attachments && > doc._attachments.payload} > > Maybe these two errors are connected? > > We are currently using CouchDb 1.0.2 > > Anybody got an idea what could be wrong? > > /Henrik
