Return-Path: X-Original-To: apmail-incubator-lucy-user-archive@www.apache.org Delivered-To: apmail-incubator-lucy-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 264A37BEE for ; Thu, 17 Nov 2011 06:17:55 +0000 (UTC) Received: (qmail 50919 invoked by uid 500); 17 Nov 2011 06:17:54 -0000 Delivered-To: apmail-incubator-lucy-user-archive@incubator.apache.org Received: (qmail 50737 invoked by uid 500); 17 Nov 2011 06:17:46 -0000 Mailing-List: contact lucy-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: lucy-user@incubator.apache.org Delivered-To: mailing list lucy-user@incubator.apache.org Received: (qmail 50718 invoked by uid 99); 17 Nov 2011 06:17:43 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Nov 2011 06:17:43 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [68.116.39.62] (HELO rectangular.com) (68.116.39.62) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Nov 2011 06:17:36 +0000 Received: from marvin by rectangular.com with local (Exim 4.69) (envelope-from ) id 1RQvHT-00074T-Vr for lucy-user@incubator.apache.org; Wed, 16 Nov 2011 22:17:03 -0800 Date: Wed, 16 Nov 2011 22:17:03 -0800 From: Marvin Humphrey To: lucy-user@incubator.apache.org Message-ID: <20111117061703.GA27162@rectangular.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-Virus-Checked: Checked by ClamAV on apache.org Subject: Re: [lucy-user] Couldn't completely remove 'seg_N' On Wed, Nov 16, 2011 at 09:28:25AM +0200, goran kent wrote: > I've noticed this occasional error/failure during index merging: > > Couldn't completely remove 'seg_N' > > Which comes from core/Lucy/Index/SegWriter.c, where the comment in > SegWriter_prep_seg_dir() says: > > // Clear stale segment files from crashed indexing sessions. > > Is that stale segment folder from a previous unrelated index/merge > session, or is it from the current session which has crashed/failed > and this is part of the cleanup procedure? > It seems to be the former, am I right? That code is indeed supposed to clear files from discrete indexing sessions which crashed earlier. It generally works without calling attention to itself. The fact that you are encountering repeated errors there is troubling; the same symptom can arise when two indexers from different machines collide when trying to write to the same index on a shared drive. I recall you saying that you had your own locking mechanism, but as a precaution, I suggest that you use this code to provide a defense in depth against locking problems: use Sys::Hostname qw( hostname ); my $hostname = hostname() or die "Can't get unique hostname"; my $manager = Lucy::Index::IndexManager->new( host => $hostname, ); my $indexer = Lucy::Index::Indexer->new( index => '/path/to/index', manager => $manager, ); > (grep -rl '^Folder_Delete_Tree' * failed to find anything, > so I couldn't have a quick look to confirm that idea) Folder_Delete_Tree is a method call. The implementing function which gets called in this case is Folder_delete_tree, in core/Lucy/Store/Folder.c. Marvin Humphrey