Re: [xwiki-devs] [Vote] Add a cache directory concept and make the XWiki launch faster (was: Move the caches files to permdir and make the launch of XWiki faster)

  On 17 Feb 2015 at 14:14:36, Thomas Mortagne (thomas.mortagne@xwiki.com(mailto:thomas.mortagne@xwiki.com)) wrote: Yes I know and the idea would be to introduce a configuration property in xwiki.properties to set the temporary directory in case the user wants to change it. FTR I’ve checked Jetty/Tomcat: * By default recent versions of jetty use the java.io.tmdir by default if not set. We could easily set it in our standalone distribution (we used to have a jetty/temp dir AFAIR). Also not that by default Jetty cleans the temp dir at each restart unless you tell it not to or unless you put your tmp dir inside a work directory. See see http://eclipse.org/jetty/documentation/current/ref-temporary-directories.ht…. Note that the work dir in jetty is just there for backward compat and jetty only uses a temp dir now apparently. * Tomcat has the 2 notions of work and temp directories. I don’t think it cleans the temp directory automatically at each restart though. So we have 2 options: Option 1: we don’t introduce a new concept and we just make our temporary directory configurable Option 2: we do the same as tomcat and introduce a concept of work/cache directory. I think I prefer “work” over “cache” if I have to choose since it’s less restrictive. In this case the difference is small: - temporary directory: anything in there can (and this is what happens with a default, non-configured jetty) be removed between restarts of the container without impacting anything at runtime (no performance degradation for example). This is really used for short-lived temporary files that should be removed when the container stops. - work/cache directory: files that can be removed without endangering the runtime execution of XWiki but it must not be removed at each container restart. Should be removed when performing an XWiki upgrade though. Where would we put where: - work dir: solr/lucene indexes, LESS cache, image resizes, chart-generated images, aether cache, formula-generates images, office viewer, graphviz image cache, svg image cache, TempResourceAction - temporary dir: mail sender AttachmentMimeBodyPartFactory, office conversion result,  oldcore attachment content cache, html export, pdf export So, after more research and thinking, I think there’s a case for differentiating between temp and work/cache directories, as defined above. So I’m +1 for option 2, based on that. Thanks -Vincent