Return-Path: Delivered-To: apmail-jackrabbit-users-archive@minotaur.apache.org Received: (qmail 36818 invoked from network); 9 Feb 2010 11:07:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 9 Feb 2010 11:07:06 -0000 Received: (qmail 24098 invoked by uid 500); 9 Feb 2010 11:07:06 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 24048 invoked by uid 500); 9 Feb 2010 11:07:05 -0000 Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@jackrabbit.apache.org Delivered-To: mailing list users@jackrabbit.apache.org Received: (qmail 24037 invoked by uid 99); 9 Feb 2010 11:07:05 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Feb 2010 11:07:05 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of mail@jutzig.de designates 88.198.121.126 as permitted sender) Received: from [88.198.121.126] (HELO mail.esd4j.org) (88.198.121.126) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Feb 2010 11:06:56 +0000 Received: from irdorath.esd4j.org (static.88-198-121-122.clients.your-server.de [88.198.121.122]) by mail.esd4j.org (Postfix) with ESMTP id 4BFDB8B402F for ; Tue, 9 Feb 2010 12:06:36 +0100 (CET) Received: by irdorath.esd4j.org (Postfix, from userid 33) id A800580000C; Tue, 9 Feb 2010 12:06:35 +0100 (CET) To: users@jackrabbit.apache.org Subject: Re: Out Of Memory Error while indexing MIME-Version: 1.0 Date: Tue, 09 Feb 2010 12:06:35 +0100 From: In-Reply-To: References: <4B706375.1080103@jutzig.de> <91f3b2651002082357x3121d7e4kb232fd61c29abfdc@mail.gmail.com> Message-ID: <1f51d9c0893275ba9dd55144196fb9fa@mail.esd4j.org> X-Sender: mail@jutzig.de User-Agent: RoundCube Webmail/0.2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" X-Virus-Checked: Checked by ClamAV on apache.org Hi Alexander, please see comments inline On Tue, 9 Feb 2010 11:52:59 +0100, Alexander Klimetschek wrote: > On Tue, Feb 9, 2010 at 08:57, Thomas Müller > wrote: >>> the clients connect with RMI. >> >> I'm not sure, but that might be the problem. > > Ideally (and AFAIK when using DataStore), the binary property should > be stored in a temporary file before it is persisted, and that file > stream can be used by the indexer. (Right?) Maybe in case of RMI that > is not the case. Or maybe the config could be changed to a DataStore > to avoid the problem. > Yes, that is what I observed. It creates a temp file and therefore the memory consumption stays low on both client and server side. Before I used a DataStore, Jackrabbit ran out of memory while still transfering the file. After I added a DataStore, I can succesfully transfer the file, but then I get the OutOfMemoryError stated in the first post. So I don't think RMI is the problem here, because the error stays the same no matter if I use RMI or DavEx. > In the worst case, the specific full text indexer loads everything > into memory and is the actual problem. > To me it looks as if that's exactly what's happening and what the heap dump indicates. The question is, what can I do about it :) Thanks for your reply and best regards, Johannes