Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 36892 invoked from network); 11 Nov 2009 06:00:55 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 11 Nov 2009 06:00:55 -0000 Received: (qmail 73835 invoked by uid 500); 11 Nov 2009 06:00:54 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 73733 invoked by uid 500); 11 Nov 2009 06:00:53 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 73723 invoked by uid 99); 11 Nov 2009 06:00:53 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Nov 2009 06:00:53 +0000 X-ASF-Spam-Status: No, hits=-10.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Nov 2009 06:00:51 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id AE8EE234C1EF for ; Tue, 10 Nov 2009 22:00:28 -0800 (PST) Message-ID: <763611590.1257919228710.JavaMail.jira@brutus> Date: Wed, 11 Nov 2009 06:00:28 +0000 (UTC) From: "Sean Geoghegan (JIRA)" To: dev@couchdb.apache.org Subject: [jira] Commented: (COUCHDB-567) Erlang View with Reduce Fails on Large Number of documents In-Reply-To: <1132559758.1257916108152.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/COUCHDB-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12776297#action_12776297 ] Sean Geoghegan commented on COUCHDB-567: ---------------------------------------- Actually, my fix breaks when the reduce function is removed. I'm not sure how to go about fixing this though. I can probably provide a test case if needed though. > Erlang View with Reduce Fails on Large Number of documents > ---------------------------------------------------------- > > Key: COUCHDB-567 > URL: https://issues.apache.org/jira/browse/COUCHDB-567 > Project: CouchDB > Issue Type: Bug > Affects Versions: 0.10 > Reporter: Sean Geoghegan > > I have been having a problem with running Erlang views over a large dataset. Whenever the indexer goes to checkpoint it's process the following error occurs: > ** Last message in was {'EXIT',<0.2220.0>, > {function_clause, > [{couch_view_updater,view_insert_doc_query_results, > [{doc,<<"73956fdca62c384849a3313e6c48b7ed">>,... > [], > [{{view,0, > [<<"_temp">>], > <<"...">>, > {btree,<0.2218.0>, > {1565615,{341,[0]}}, > #Fun, > #Fun, > #Fun, > #Fun}, > [{<<"_temp">>, > <<"...">>}]}, > []}], > [],[]]}, > {couch_view_updater,view_insert_query_results,4}, > {couch_view_updater,process_doc,4}, > {couch_view_updater,'-update/2-fun-0-',6}, > {couch_btree,stream_kv_node2,7}, > {couch_btree,stream_kp_node,6}, > {couch_btree,fold,5}, > {couch_view_updater,update,2}]]}, > This problem occurs regardless of the functionality of the map and reduce functions, it seems to based on the time it takes to generate, or whatever causes the checkpoints to get written out. > I did some investigation into the problem by adding alot of LOG_INFO statements throughout the code. I was able to determine the following: > > * the Erlang View process is being held on to by the view updater for the entire duration of the indexing, > * however after the first checkpoint is hit and the progress is written out, a reduce call is made to the erlang view server, once this completes the view server is released back to the cache using ret_os_process. > * when the next reduce cycle occurs the same erlang view server is returned by get_os_process but it is first sent a reset message which clears all the functions in the view servers state. > * when the next map cycles starts the view updater uses the same handle to the erlang view server it had in the beginning. It assumes that the servers state is the same however it has been reset so there are no view functions in the view server. This causes the above error when it then attempts to write out the result of a view function which doesn't exist in the server. > I was able to fix this problem by modifying line 139 of couch_view_updater.erl from this: > {[], Group2, ViewEmptyKeyValues, []} > to this: > {[], Group2#group{query_server=nil}, ViewEmptyKeyValues, []} > Which removes the view updater's handle to the erlang server proc, forcing it to get/create a new one for each map cycle and setting up the view functions within the server. I don't know if this is the right way to do it, or if it has any bad side-effects, but it does prevent the crash at least, and allow the indexing to complete correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.