You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by harvey waters <ha...@googlemail.com> on 2007/09/07 13:29:20 UTC
Bundled PM tmp files filling up tomcat
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
Re: Bundled PM tmp files filling up tomcat
Posted by Yoav Landman <yl...@gmail.com>.
I am seeing this too with Jetty and Derby bundle PM. Sun JDK 1.5 on RHEL.
The /tmp folder is filled up with bin*.tmp files.
Lori wrote:
>
> No. I work with SQL Server.
>
> Two of my colleagues use hypersonic for testing purposes and most of the
> time see the temp files disappear only on shutdown (not while the
> application running). I tried running against hypersonic also and I never
> see the files disappear on shutdown. I am reviewing our configurations -
> though so far they look the same. I do believe I'm using a newer version
> of Tomcat, but only 5.5.028 vs. 5.5.023.
>
>
>
> Nick Stolwijk-3 wrote:
>>
>> We have worked with the OracleFileSystem and when the OutputStreams for
>> blob's don't get closed, the tmp file also won't get deleted.
>>
>> So, do you work with the OracleFileSystem?
>>
>> Hth,
>>
>> Nick Stolwijk
>>
>> Stefan Guggisberg wrote:
>>> hi lori,
>>>
>>> On 9/19/07, Lori <lo...@yahoo.com> 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 <ha...@googlemail.com> 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 <th...@gmail.com> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> What version did you use, and do you have a simple test case?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Thomas
>>>>>>>
>>>>>>> On 9/7/07, harvey waters <ha...@googlemail.com> 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#a13638333
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Bundled PM tmp files filling up tomcat
Posted by Lori <lr...@translations.com>.
No. I work with SQL Server.
Two of my colleagues use hypersonic for testing purposes and most of the
time see the temp files disappear only on shutdown (not while the
application running). I tried running against hypersonic also and I never
see the files disappear on shutdown. I am reviewing our configurations -
though so far they look the same. I do believe I'm using a newer version of
Tomcat, but only 5.5.028 vs. 5.5.023.
Nick Stolwijk-3 wrote:
>
> We have worked with the OracleFileSystem and when the OutputStreams for
> blob's don't get closed, the tmp file also won't get deleted.
>
> So, do you work with the OracleFileSystem?
>
> Hth,
>
> Nick Stolwijk
>
> Stefan Guggisberg wrote:
>> hi lori,
>>
>> On 9/19/07, Lori <lo...@yahoo.com> 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 <ha...@googlemail.com> 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 <th...@gmail.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> What version did you use, and do you have a simple test case?
>>>>>>
>>>>>> Thanks,
>>>>>> Thomas
>>>>>>
>>>>>> On 9/7/07, harvey waters <ha...@googlemail.com> 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#a13165603
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Bundled PM tmp files filling up tomcat
Posted by Nick Stolwijk <ni...@planet.nl>.
We have worked with the OracleFileSystem and when the OutputStreams for
blob's don't get closed, the tmp file also won't get deleted.
So, do you work with the OracleFileSystem?
Hth,
Nick Stolwijk
Stefan Guggisberg wrote:
> hi lori,
>
> On 9/19/07, Lori <lo...@yahoo.com> 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 <ha...@googlemail.com> 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 <th...@gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> What version did you use, and do you have a simple test case?
>>>>>
>>>>> Thanks,
>>>>> Thomas
>>>>>
>>>>> On 9/7/07, harvey waters <ha...@googlemail.com> 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.
>>
>>
>>
>
>
Re: Bundled PM tmp files filling up tomcat
Posted by Stefan Guggisberg <st...@gmail.com>.
On 10/2/07, Lori <lr...@translations.com> 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 <lo...@yahoo.com> 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 <ha...@googlemail.com> 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 <th...@gmail.com> wrote:
> >> >> >
> >> >> > Hi,
> >> >> >
> >> >> > What version did you use, and do you have a simple test case?
> >> >> >
> >> >> > Thanks,
> >> >> > Thomas
> >> >> >
> >> >> > On 9/7/07, harvey waters <ha...@googlemail.com> 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.
>
>
Re: Bundled PM tmp files filling up tomcat
Posted by Lori <lr...@translations.com>.
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 <lo...@yahoo.com> 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 <ha...@googlemail.com> 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 <th...@gmail.com> wrote:
>> >> >
>> >> > Hi,
>> >> >
>> >> > What version did you use, and do you have a simple test case?
>> >> >
>> >> > Thanks,
>> >> > Thomas
>> >> >
>> >> > On 9/7/07, harvey waters <ha...@googlemail.com> 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.
Re: Bundled PM tmp files filling up tomcat
Posted by Stefan Guggisberg <st...@gmail.com>.
hi lori,
On 9/19/07, Lori <lo...@yahoo.com> 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 <ha...@googlemail.com> 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 <th...@gmail.com> wrote:
> >> >
> >> > Hi,
> >> >
> >> > What version did you use, and do you have a simple test case?
> >> >
> >> > Thanks,
> >> > Thomas
> >> >
> >> > On 9/7/07, harvey waters <ha...@googlemail.com> 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.
>
>
Re: Bundled PM tmp files filling up tomcat
Posted by Lori <lo...@yahoo.com>.
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?
-Lori
Stefan Guggisberg wrote:
>
> On 9/7/07, harvey waters <ha...@googlemail.com> 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 <th...@gmail.com> wrote:
>> >
>> > Hi,
>> >
>> > What version did you use, and do you have a simple test case?
>> >
>> > Thanks,
>> > Thomas
>> >
>> > On 9/7/07, harvey waters <ha...@googlemail.com> 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.
Re: Bundled PM tmp files filling up tomcat
Posted by Thomas Mueller <th...@gmail.com>.
> Will the datastore replace these temp binaries in the long term anyway ?
Yes, that's the plan. But probably there will be some exceptions at
first (for example when using RMI). If you are interested:
http://issues.apache.org/jira/browse/JCR-926
Thomas
Re: Bundled PM tmp files filling up tomcat
Posted by Stefan Guggisberg <st...@gmail.com>.
On 9/7/07, harvey waters <ha...@googlemail.com> 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 <th...@gmail.com> wrote:
> >
> > Hi,
> >
> > What version did you use, and do you have a simple test case?
> >
> > Thanks,
> > Thomas
> >
> > On 9/7/07, harvey waters <ha...@googlemail.com> 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
> > >
> >
>
Re: Bundled PM tmp files filling up tomcat
Posted by harvey waters <ha...@googlemail.com>.
OK I'll see if I can replicate in a seperate test case. I guess that'll also
allow me to see if its my stuff thats gone wrong. Will the datastore replace
these tem binaries in the long term anyway ?
On 9/7/07, Thomas Mueller <th...@gmail.com> wrote:
>
> Hi,
>
> Sorry, I don't think I can help you, I don't know enough about the
> mechanism. Maybe all temp files older than a day could be removed?
>
> If you have a simple standalone test case that inserts one blob so
> that multiple duplicate temp files are created, please log a bug.
> Solving the problem will be very hard without test case...
>
> I'm currently working on DataStore, where creating temporary files is
> avoided (in most cases). But this is not available for version 1.3 of
> Jackrabbit...
>
> Thomas
>
>
>
> On 9/7/07, harvey waters <ha...@googlemail.com> 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.
> >
> > Currently we're on version 1.3 of JackRabbit.
> >
> > On 9/7/07, Thomas Mueller <th...@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > What version did you use, and do you have a simple test case?
> > >
> > > Thanks,
> > > Thomas
> > >
> > > On 9/7/07, harvey waters <ha...@googlemail.com> 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
> > > >
> > >
> >
>
Re: Bundled PM tmp files filling up tomcat
Posted by Thomas Mueller <th...@gmail.com>.
Hi,
Sorry, I don't think I can help you, I don't know enough about the
mechanism. Maybe all temp files older than a day could be removed?
If you have a simple standalone test case that inserts one blob so
that multiple duplicate temp files are created, please log a bug.
Solving the problem will be very hard without test case...
I'm currently working on DataStore, where creating temporary files is
avoided (in most cases). But this is not available for version 1.3 of
Jackrabbit...
Thomas
On 9/7/07, harvey waters <ha...@googlemail.com> 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.
>
> Currently we're on version 1.3 of JackRabbit.
>
> On 9/7/07, Thomas Mueller <th...@gmail.com> wrote:
> >
> > Hi,
> >
> > What version did you use, and do you have a simple test case?
> >
> > Thanks,
> > Thomas
> >
> > On 9/7/07, harvey waters <ha...@googlemail.com> 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
> > >
> >
>
Re: Bundled PM tmp files filling up tomcat
Posted by harvey waters <ha...@googlemail.com>.
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.
Currently we're on version 1.3 of JackRabbit.
On 9/7/07, Thomas Mueller <th...@gmail.com> wrote:
>
> Hi,
>
> What version did you use, and do you have a simple test case?
>
> Thanks,
> Thomas
>
> On 9/7/07, harvey waters <ha...@googlemail.com> 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
> >
>
Re: Bundled PM tmp files filling up tomcat
Posted by Thomas Mueller <th...@gmail.com>.
Hi,
What version did you use, and do you have a simple test case?
Thanks,
Thomas
On 9/7/07, harvey waters <ha...@googlemail.com> 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
>