Hi Julien, Deleting the files on disk will not work. Then you get broken properties in the Jackrabbit caches. Are there many files in your temp dir, or just a couple of big ones?
Best regards, Martijn On Wed, Nov 25, 2009 at 9:41 AM, Julien Poffet <[email protected]> wrote: > Hi Martijn, > I tried to setup minimal values to the cache manager: > CacheManager cm = repository.getCacheManager(); > cm.setMaxMemory(16 * 1024); > cm.setMaxMemoryPerCache(8 * 1024); > cm.setMinMemoryPerCache(1024); > cm.setMinResizeInterval(500); > Even with this settings my temp directory grows quickly up to 1 GB... > Another questions, why Jackrabbit do not recreate these cache files if they > are deleted. I tried to remove them but then the WebDav can't render the > files any more. I was supposing that if the cache file is missing, it should > be created again? > Thanks for the JIRA, > Best Regards, > Julien > On Wed, Nov 25, 2009 at 8:42 AM, Martijn Hendriks <[email protected]> wrote: >> >> Hi Julien, >> >> Ok, I see why you choose another approach. I created an issue for >> this: https://issues.apache.org/jira/browse/JCR-2407 >> >> Best regards, >> >> Martijn >> >> On Tue, Nov 24, 2009 at 10:04 AM, Julien Poffet <[email protected]> >> wrote: >> > Hi Martijn, >> > Thanks for the reply. >> > Yes the files look like bin1965159231182123515.tmp. >> > Ok I'll try to configure smaller cache sizes. >> > As fare as I know the import/export API use XML. My source database is >> > about >> > 60go so I don't believe it will work out of the box... >> > Best regards, >> > Julien >> > On Mon, Nov 23, 2009 at 4:33 PM, Martijn Hendriks <[email protected]> >> > wrote: >> >> >> >> Hi Julien, >> >> >> >> Do these files look like bin1965159231182123515.tmp? If so, these are >> >> the contents of binary properties which are cached by Jackrabbit and I >> >> know no way to avoid them. These files should be deleted automatically >> >> when the associated properties are garbage collected. If you have a >> >> lot of big binary properties the contents on disk can indeed grow very >> >> fast. I know of two workarounds: (i) point the java.io.tmpdir to an fs >> >> with a lot of space, and (ii) configure smaller cache sizes in >> >> org.apache.jackrabbit.core.state.CacheManager (available through a >> >> org.apache.jackrabbit.core.RepositoryImpl instance). >> >> >> >> Btw, have you tried to use the import/export API for migrating your >> >> content? >> >> >> >> Best regards, >> >> Martijn >> >> >> >> On Mon, Nov 23, 2009 at 4:17 PM, Julien Poffet <[email protected]> >> >> wrote: >> >> > Here is my situation, >> >> > >> >> > I was using jackrabbit with a non-datastore config. So all the >> >> > content >> >> > of >> >> > jackrabbit were stored in my database. Now I just migrated to a >> >> > cluster/datastore config with a brand new database prefix. >> >> > >> >> > At this point I'm trying to import the content of the old repository >> >> > to >> >> > the >> >> > new one. I have setup the SimpleWebDavServlet to expose the content >> >> > of >> >> > the >> >> > old repository through WebDav. By doing this I can parse the WebDav >> >> > and >> >> > get >> >> > the files to import them in the new repository. So far it's a little >> >> > bit >> >> > slow but it works fine. My problem is that when the source WebDav is >> >> > parsed, >> >> > a lot of binary files (which I assume are a kind of BLOB cache) are >> >> > created >> >> > in my tomcat temp dir. This temporary files are never deleted and my >> >> > server >> >> > runs out of space very quickly. >> >> > >> >> > Is there a way to avoid theses temporary files? >> >> > >> >> > Cheers, >> >> > Julien >> >> > >> > >> > > >
