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.



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

Reply via email to