From users-return-5123-apmail-jackrabbit-users-archive=jackrabbit.apache.org@jackrabbit.apache.org Wed Oct 03 12:00:54 2007 Return-Path: Delivered-To: apmail-jackrabbit-users-archive@locus.apache.org Received: (qmail 17872 invoked from network); 3 Oct 2007 12:00:53 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 3 Oct 2007 12:00:53 -0000 Received: (qmail 45162 invoked by uid 500); 3 Oct 2007 12:00:42 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 44795 invoked by uid 500); 3 Oct 2007 12:00:42 -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 44786 invoked by uid 99); 3 Oct 2007 12:00:42 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Oct 2007 05:00:42 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of stefan.guggisberg@gmail.com designates 209.85.134.184 as permitted sender) Received: from [209.85.134.184] (HELO mu-out-0910.google.com) (209.85.134.184) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Oct 2007 12:00:41 +0000 Received: by mu-out-0910.google.com with SMTP id w1so5282120mue for ; Wed, 03 Oct 2007 05:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=MkeKY6x9+r0R79m/V1Ki1AZz15hGosQNp2T+CXy3hvs=; b=UC+cLvugl+H2ATfs4Dx0xbSVU0dftXqNCJMRIv6swXNW4+pYHW9+ghAAd9aySPyK5NvX9BrGK4UZpmlRoEj5bFrNS4kFW1VZRgx8drPvNiVZ9sN5cuaLzfgUnh0ZNnIysMn3SDh/vBba16/V3du3vLHyyLUV/3KP3QrkvQ0VL0A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VzoUcng0m2jS5qfJjckU6s4cF2Hhx/Noe4c52rkJ0D5bnGF1uRgJo+ZuXPmbcytn8v3eLuAGeAGUaW9Tv9yIebQOtOb68zZ1T5t3OHpuxu4nG4PVJ+s7nAsGW3qYu7oyLXF71vRhv/HpCiXDc9286tXnyHs2SoUmRadECNCBxwM= Received: by 10.82.146.14 with SMTP id t14mr9739497bud.1191412819309; Wed, 03 Oct 2007 05:00:19 -0700 (PDT) Received: by 10.82.171.9 with HTTP; Wed, 3 Oct 2007 05:00:19 -0700 (PDT) Message-ID: <90a8d1c00710030500u4c76bb9btc07e0ee3bdc9b746@mail.gmail.com> Date: Wed, 3 Oct 2007 14:00:19 +0200 From: "Stefan Guggisberg" To: users@jackrabbit.apache.org Subject: Re: Bundled PM tmp files filling up tomcat In-Reply-To: <13008872.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <235bf4ca0709070429m3a95e327k3a84df85b1881c29@mail.gmail.com> <5f211bd50709070437s7cd3a907ub4cdead2e17e7d96@mail.gmail.com> <235bf4ca0709070634u678f2b3cpbfd15d8b91c3570f@mail.gmail.com> <90a8d1c00709070731i595c6472g9cfb32462f50747e@mail.gmail.com> <12782072.post@talk.nabble.com> <90a8d1c00709200255n29e59d0bl9536d2be70f64855@mail.gmail.com> <13008872.post@talk.nabble.com> X-Virus-Checked: Checked by ClamAV on apache.org On 10/2/07, Lori wrote: > > Sorry about the delay in replying. > We are using Jackrabbit 1.3. We did change from using the Session to the > XASession in preparation to use JTA, though haven't moved to that yet. > Looking at our code that builds a wrapper around the jackrabbit APIs it > appears to login and logout appropriately, and still the tmp files exist. > The jdts???.tmp files seem to appear and disappear as the records/files are > accessed from the db, however the bin???.tmp files continue to exist. > > If I add a binary file to jackrabbit through its API it will appear in the > temp directory and doesn't seem to disappear. If I add an html or other > text type file it doesn't seem to need to use the temp directory, or maybe > it is just that its size is small. When I shut down our application, which > in turn shuts down jackrabbit appropriately - the tmp files from jackrabbit > are still left there. I then can remove them all and start up again. > > After restarting I retrieved a file from jackrabbit (through our app calling > the jackrabbit API) and a binary tmp file is created in the temp directory. > I move away from using it, logout of our app, etc.. .(the session has been > logged out at this point) and still the tmp files exist. > > So at this point you are thinking our app is holding on to the cached yes, that's currently my best guess. > objects? Or is there some tuning or something with using XASession that may > be causing a problem? hmm, good point. dominique might be able to answer this... > > I will try to test out again and get a memory dump. great. could you perhaps also construct a small case which demonstrates this issue? cheers stefan > Thanks > -Lori > > > > Stefan Guggisberg wrote: > > > > hi lori, > > > > On 9/19/07, Lori wrote: > >> > >> I am having the same problem where the tomcat temp directory is > >> filled with bin????.tmp files. The files are stored in the database with > >> (i.e. externalBlobs=false). Sometimes the files go away, but many times > >> they just stick around. I haven't identified why they aren't released, > >> but right now the temp directory has almost 2 Gig's worth of these > >> binary files. If we shut our application down it appears that we can > >> clear out the temp directory. However we can't be shutting it down all > >> the > >> time. We tried removing the files that were 2 days old, and then ran > >> into some problems of files that couldn't be accessed - so we have just > >> left them there till restart. > >> Any ideas, suggestions, configuration help would be apprectiated. Is > >> there a known bug where they are left around? > > > > the only situation i can think of where such temp files could be left > > around > > is when the repository is not shut down properly (e.g. by killing the jvm > > process) or an application on top of jackrabbit holds on to/caches > > properties/streams returned from the JCR api. > > > > if you store the blob's in the db, the blob will be spooled to a temp file > > when it's requested (e.g. by a node.getProperty() call). the property > > is cached, holding a reference to the temp file. once the property is > > evicted from the cache, the temp file will go away. > > > > therefore, if you have lots of binary properties and they're requested > > frequently, it's possible that you'll see lots of such temp files since > > their associated properties are cached. > > > > what jackrabbit version are you using? how many temp files > > do you typically see? > > > > could you perhaps provide a memory dump of your jvm, taken > > when you observe lots of such temp files? i'd like to analyze it > > using a profiler. > > > > btw: the current blob handling will be significantly improved by > > using a global data store for binaries > > (see http://issues.apache.org/jira/browse/JCR-926). > > > > cheers > > stefan > > > >> -Lori > >> > >> > >> Stefan Guggisberg wrote: > >> > > >> > On 9/7/07, harvey waters wrote: > >> >> No sorry I don't have a test case. I just got a 'Disk Full' error on > >> our > >> >> live server and then took a look in the tomcat temp directory and > >> found > >> >> all > >> >> the binaries going back to when we installed the system. I thought > >> these > >> >> binaries were used as a BLOB cache for JackRabbit, if so I guessed > >> there > >> >> might be a way of managing them. > >> > > >> > assuming you configured jackrabbit to store blobs in the db > >> > (i.e. externalBlobs=false), reading a binary property value > >> > (e.g. node.getProperty("bin").getStream()) will cause the blob > >> > to be spooled from the db to a temp file. note that only *one* > >> > temp file will be created. the temp file will be automatically > >> > deleted when it's not being referenced anymore and the associated > >> > Property object is evicted from the cache. life expectancy of > >> > such a temp file should therefore be rather short. > >> > > >> > cheers > >> > stefan > >> > > >> >> > >> >> Currently we're on version 1.3 of JackRabbit. > >> >> > >> >> On 9/7/07, Thomas Mueller wrote: > >> >> > > >> >> > Hi, > >> >> > > >> >> > What version did you use, and do you have a simple test case? > >> >> > > >> >> > Thanks, > >> >> > Thomas > >> >> > > >> >> > On 9/7/07, harvey waters wrote: > >> >> > > Is there anyway I can stop the bundled PM from filling up the temp > >> >> > directory > >> >> > > in Tomcat. I aslo noticed that on loading a binary into JackRabbit > >> I > >> >> > ended > >> >> > > up with 9 duplicated tmp files. Have I done soemthing wrong here > >> or > >> >> is > >> >> > it > >> >> > > JackRabbit ? > >> >> > > > >> >> > > Many Thanks > >> >> > > > >> >> > > Harvery > >> >> > > > >> >> > > >> >> > >> > > >> > > >> > >> -- > >> View this message in context: > >> http://www.nabble.com/Bundled-PM-tmp-files-filling-up-tomcat-tf4400812.html#a12782072 > >> Sent from the Jackrabbit - Users mailing list archive at Nabble.com. > >> > >> > > > > > > -- > View this message in context: http://www.nabble.com/Bundled-PM-tmp-files-filling-up-tomcat-tf4400812.html#a13008872 > Sent from the Jackrabbit - Users mailing list archive at Nabble.com. > >