Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id F33876B97 for ; Wed, 1 Jun 2011 11:36:31 +0000 (UTC) Received: (qmail 62934 invoked by uid 500); 1 Jun 2011 11:36:31 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 62891 invoked by uid 500); 1 Jun 2011 11:36:31 -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 62883 invoked by uid 99); 1 Jun 2011 11:36:31 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Jun 2011 11:36:31 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Jun 2011 11:36:28 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id 5E514EDF29 for ; Wed, 1 Jun 2011 11:35:47 +0000 (UTC) Date: Wed, 1 Jun 2011 11:35:47 +0000 (UTC) From: "Clare Walsh (JIRA)" To: dev@couchdb.apache.org Message-ID: <595583666.59278.1306928147382.JavaMail.tomcat@hel.zones.apache.org> In-Reply-To: <55536757.59214.1306926347488.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Updated] (COUCHDB-1182) Crash after compaction is completed MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/COUCHDB-1182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clare Walsh updated COUCHDB-1182: --------------------------------- Description: When compaction is run, it seems to complete successfully (disappears from active tasks), but then at the end or a minute or so afterwards couch crashes [EDIT: that's a bit dramatic, it logs a crash, it goes up a few levels of crash, but doesn't get all the way to crashed before it starts working again]. This has happened twice so far, I am attaching logs for both occasions. The 'huge chunks of numbers' are all in a single binary array (ie no structure has been removed) and are hundreds of pages long (hence removed). I have truncated the logs as the same error appears three times as the supervisor is restarting child, and then the rest of the chain upwards as it gradually folds into a heap was very long. If any of this chain (or any other information) is needed please let me know. Thanks was: When compaction is run, it seems to complete successfully (disappears from active tasks), but then at the end or a minute or so afterwards couch crashes. This has happened twice so far, I am attaching logs for both occasions. The 'huge chunks of numbers' are all in a single binary array (ie no structure has been removed) and are over 3 pages long (hence removed). I have truncated the logs as the same error appears three times as the supervisor is restarting child, and then the rest of the chain upwards as it gradually folds into a heap was very long. If any of this chain (or any other information) is needed please let me know. Thanks > Crash after compaction is completed > ----------------------------------- > > Key: COUCHDB-1182 > URL: https://issues.apache.org/jira/browse/COUCHDB-1182 > Project: CouchDB > Issue Type: Bug > Affects Versions: 1.0.2 > Environment: Centos 5.6 > Reporter: Clare Walsh > Labels: compaction > Attachments: compaction fail.txt, post patch friday - noproc.txt > > > When compaction is run, it seems to complete successfully (disappears from active tasks), but then at the end or a minute or so afterwards couch crashes [EDIT: that's a bit dramatic, it logs a crash, it goes up a few levels of crash, but doesn't get all the way to crashed before it starts working again]. > This has happened twice so far, I am attaching logs for both occasions. The 'huge chunks of numbers' are all in a single binary array (ie no structure has been removed) and are hundreds of pages long (hence removed). I have truncated the logs as the same error appears three times as the supervisor is restarting child, and then the rest of the chain upwards as it gradually folds into a heap was very long. If any of this chain (or any other information) is needed please let me know. > Thanks -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira