Return-Path: Delivered-To: apmail-jackrabbit-users-archive@minotaur.apache.org Received: (qmail 44465 invoked from network); 9 Mar 2009 18:11:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 9 Mar 2009 18:11:25 -0000 Received: (qmail 41087 invoked by uid 500); 9 Mar 2009 18:11:23 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 41075 invoked by uid 500); 9 Mar 2009 18:11:23 -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 41064 invoked by uid 99); 9 Mar 2009 18:11:23 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Mar 2009 11:11:23 -0700 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of monkiki@gmail.com designates 74.125.44.30 as permitted sender) Received: from [74.125.44.30] (HELO yx-out-2324.google.com) (74.125.44.30) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Mar 2009 18:11:14 +0000 Received: by yx-out-2324.google.com with SMTP id 8so1111387yxm.1 for ; Mon, 09 Mar 2009 11:10:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=GLqPEQklM4X5pg9VeVb12MyCRnEANAGHf9vUA8RZsDY=; b=pi/yltkboDNpN3ohdqcwtwLdsFfI0/Vp0+uXUCER5RBN1GkDe2+7vdWQGeqGqeLUMd I6YsF7oebhXSFigXMTSz552F1UNpLD/gTB76jF3gftnqGXyuyXMse/Y8YU6bO8+nOgIQ FNdkAUmnv5G0ZAG4wZUc+AsGi08oLC6gzg/+8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=WAy+mPLIWpycD77z3DeOY01moMdASXB0LlQrA84TgemizrBPBliXhozKhWf4ivcKsA kNAx2HJy5j/uTlt/Es3qD2ad0qQXcseLaFTt4Q81bmA7D3HmMW8+H3zXYHW2EBGpGbaN E99JHBfJJDzhAW/v1sTL0PJuMVOetycrm4VxQ= MIME-Version: 1.0 Received: by 10.100.119.17 with SMTP id r17mr1600176anc.34.1236622253206; Mon, 09 Mar 2009 11:10:53 -0700 (PDT) In-Reply-To: <8f70390903091038x7d192380wb003c4da57834619@mail.gmail.com> References: <8f70390903090936q431b6588qf3e227666862d338@mail.gmail.com> <91f3b2650903090940p4b5e5aeft9aced415142e0e9a@mail.gmail.com> <8f70390903091002p16fbb1e4ied2479c1c8d9100@mail.gmail.com> <510143ac0903091020r3d69e9fbp2547ff6a76724dfa@mail.gmail.com> <8f70390903091038x7d192380wb003c4da57834619@mail.gmail.com> Date: Mon, 9 Mar 2009 19:10:52 +0100 Message-ID: <8f70390903091110l3e98e514y1374f989a8c94236@mail.gmail.com> Subject: Re: Datastore and garbage collection From: Paco Avila To: users@jackrabbit.apache.org Content-Type: multipart/alternative; boundary=001485f546581fad1e0464b38eec X-Virus-Checked: Checked by ClamAV on apache.org --001485f546581fad1e0464b38eec Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit And after run GarbageCollector gc; SessionImpl si = (SessionImpl)session; gc = si.createDataStoreGarbageCollector(); // optional (if you want to implement a progress bar / output): // gc.setScanEventListener(this); gc.scan(); gc.stopScan(); // delete old data gc.deleteUnused(); all deleted documents are supposed to be remove from repository/datastore? On Mon, Mar 9, 2009 at 6:38 PM, Paco Avila wrote: > Do you mean that GC only make sense if I delete documents from the > repository? I don't think that never run GC and keep all the documents > (deleted one included) is a good alternative in repositories with several GB > of size and big documents. > > On Mon, Mar 9, 2009 at 6:20 PM, Jukka Zitting wrote: > >> Hi, >> >> On Mon, Mar 9, 2009 at 6:02 PM, Paco Avila wrote: >> > The real question should be "Do I need to call the garbage collection in >> my >> > app" ? :P >> > >> > And the answer seems to be "YES"! >> >> Well, it depends. If your usage patterns permit, you could also just >> ignore garbage collection entirely. >> >> If you don't have lots of short-lived files (or binary properties) in >> the repository, then the cost of keeping some extra unused binaries in >> the data store may well be smaller than the cost of getting rid of >> them. >> >> It's worth estimating the rate at which you remove binary data from >> the repository, and using the result to calculate the best garbage >> collection intervals. The low (and declining) cost of storage and the >> typical usage patterns of many content applications (especially ones >> with versioning) may well suggest that the most economic alternative >> is to never run the garbage collector. >> >> BR, >> >> Jukka Zitting >> > > > > -- > Paco Avila > GIT Consultors > tel: +34 971 498310 > fax: +34 971496189 > e-mail: pavila@git.es > http://www.git.es > -- Paco Avila GIT Consultors tel: +34 971 498310 fax: +34 971496189 e-mail: pavila@git.es http://www.git.es --001485f546581fad1e0464b38eec--