Return-Path: Delivered-To: apmail-jackrabbit-users-archive@locus.apache.org Received: (qmail 43152 invoked from network); 2 Oct 2007 21:56:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 2 Oct 2007 21:56:06 -0000 Received: (qmail 23218 invoked by uid 500); 2 Oct 2007 21:55:54 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 23134 invoked by uid 500); 2 Oct 2007 21:55:54 -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 23125 invoked by uid 99); 2 Oct 2007 21:55:54 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Oct 2007 14:55:54 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of lists@nabble.com designates 216.139.236.158 as permitted sender) Received: from [216.139.236.158] (HELO kuber.nabble.com) (216.139.236.158) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Oct 2007 21:55:55 +0000 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1IcpiI-0005WP-KA for users@jackrabbit.apache.org; Tue, 02 Oct 2007 14:55:34 -0700 Message-ID: <13008872.post@talk.nabble.com> Date: Tue, 2 Oct 2007 14:55:34 -0700 (PDT) From: Lori To: users@jackrabbit.apache.org Subject: Re: Bundled PM tmp files filling up tomcat In-Reply-To: <90a8d1c00709200255n29e59d0bl9536d2be70f64855@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: lronning@translations.com 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> X-Virus-Checked: Checked by ClamAV on apache.org 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 objects? Or is there some tuning or something with using XASession that may be causing a problem? I will try to test out again and get a memory dump. 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.