You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by "Alexios Giotis (JIRA)" <ji...@apache.org> on 2013/04/09 00:42:15 UTC

[jira] [Commented] (FOP-2211) [PATCH] Fix & improve the handling of temporary files using the new URI resource resolvers

    [ https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13625920#comment-13625920 ] 

Alexios Giotis commented on FOP-2211:
-------------------------------------

Peter (or any other committer), will you commit your (Peter's) patch with the exception of the deleteOnExit() method ?

Or do you prefer that I create another (bigger) patch that will not be 100% compatible with the current trunk but will attempt to give an elegant way of handling temp files ?
                
> [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, 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