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

["Vincent Hennebert (JIRA)" <ji...@apache.org>]

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

Vincent Hennebert commented on FOP-2211:
----------------------------------------

Hi Alexios,

thanks for your patches. It is true that the current situation is less than optimal. Maybe temporary resources shouldn't be handled through URIs at all. However, do we always want to store them in a temp file? Referring to the email thread you mention above, I think Peter has a point in saying that we may want to just store them in memory, and reduce the I/O load on the server. Shouldn't we leave that configurable?

As to the patches: I'm not sure we want to add a delete method to the ResourceResolver interface. That method applies to temporary resources only and the scope of that interface is broader than that. I'd rather have that method on some sub-class implementing that interface.

That said, there seems to be a discrepancy in the code: if I take PSDocumentHandler as an example, there is a TempResourceURIGenerator that is used to create tmp URIs, that are then passed on to the userAgent's ResourceResolver, but nothing indicates that that ResourceResolver can handle tmp URIs. In fact, that may well not be the case if the user configured the FopFactory with a custom ResourceResolver.

In light of this, it's probably best to remove the tmp URI facility altogether and switch back to the createTempFile method for now. I guess we can always think about a RAM version of temp files later on, if the OS' own caching facility proves insufficient.

What do people think?
Vincent
                
> [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: Alexis Giotis
>             Fix For: trunk
>
>         Attachments: fop.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