Hi Peter, I am not reusing in any way the temp files. Since FOP creates them, I believe FOP should also delete them. This should happen when temp files are no longer required and not when the JVM will terminate. This is what FOP does in version 1.1 or before. I could setup my own resource handler and override the close method of the Resource to delete the temp file, as you suggested. But fixing this in FOP is cleaner and benefits other people which use FOP embedded in their Java application.
Is it clear ? Do you agree ? Thanks, Alexios On 7 Mar 2013, at 12:21, Peter Hancock <peter.hanc...@gmail.com> wrote: > Hi Alexios, > > I take it you are you reading from the temp files more than once, > otherwise you could reluctantly hook into the close method of Resource > to do the file deletion. I am interested to know how you are > benefiting from reusing the temp file. > > Thanks, > > Peter > > On Tue, Mar 5, 2013 at 10:55 AM, Alexios Giotis (JIRA) <j...@apache.org> > wrote: >> >> [ >> https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13593313#comment-13593313 >> ] >> >> Alexios Giotis commented on FOP-2211: >> ------------------------------------- >> >> Hi Simon, >> >> Thank you for the patch. I looked at it and it does not resolve the issue of >> keeping on disk many and big files. In a test we did last week, the temp >> file was 100GB and for sure we don't wish to keep such files until the JVM >> is normally terminated. For us, this is several months or a year. >> >> Also, I don't think that backwards compatibility is an issue here. This is >> trunk, there are many changes since 1.1 that do affect users embedding FOP >> in their apps and this is not one of them. I am sure it will be easy to >> change your code or to create an adapter. >> >> I will try to find some time to submit updated versions of the patches that >> take into account the comments above. >> >> >>> [PATCH] Fix & improve the handling of temporary files using the new URI >>> resource resolvers >>> ------------------------------------------------------------------------------------------ >>> >>> Key: FOP-2211 >>> URL: https://issues.apache.org/jira/browse/FOP-2211 >>> Project: Fop >>> Issue Type: Bug >>> Components: general >>> Affects Versions: trunk >>> Reporter: Alexios Giotis >>> Fix For: trunk >>> >>> Attachments: fop.patch, tempurisimple.patch, xgc.patch >>> >>> >>> As written in http://markmail.org/message/zelumstxxsdyvkcz , after the >>> merge of the Temp_URI_Resolution branch (Sept 2012), the actual pattern of >>> using temp files has changed from: >>> {code} >>> File tmpFile = File.createTempFile(....); >>> // Write and read from the file >>> tmpFile.delete(); >>> {code} >>> to: >>> {code} >>> File tmpFile = new File(System.getProperty("java.io.tmpdir"), >>> counterStartingFrom1AsString); >>> tmpFile.deleteOnExit(); >>> // Write and read from the file >>> {code} >>> This is fine when FOP is executed from the command line (which I guess this >>> is how most people use it) but it introduces a number of bad side effects >>> for long running processes that use FOP embedded. >>> >>> 1. Different FOP processes can't be executed in parallel on the same system >>> because creating the same temp file fails. >>> 2. If the JVM is not normally terminated, the temp files are never deleted >>> and the next invocation of the JVM fails to run. >>> 3. deleteOnExit() keeps for the life of the JVM an unknown number of temp >>> files both on disk and a reference in memory. >>> There should not be a need to implement a custom resource resolver when >>> using FOP embedded in order to fix those issues. The default implementation >>> should work at least as good as it worked in FOP 1.1 or earlier. >>> Attached are 2 patches, one for XGC and one for FOP that should fix and >>> improve the handling of at least the temporary files. >>> For reference, [1] lists some reasons for implementing the new URI resource >>> resolvers. >>> [1] http://wiki.apache.org/xmlgraphics-fop/URIResolution >> >> -- >> This message is automatically generated by JIRA. >> If you think it was sent incorrectly, please contact your JIRA administrators >> For more information on JIRA, see: http://www.atlassian.com/software/jira
