[
https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633107#comment-13633107
]
Vincent Hennebert commented on FOP-2211:
----------------------------------------
To elaborate a bit, I think we now all agree that temporary files shouldn't be
handled by the URI framework. Those two issues are orthogonal.
The suggestion would be to scrape the tmp:// scheme from the URI framework and
to replace it with a system that manages temporary resources. A good use case
would be the PSDocumentHandler that, when optimize-resources is set to true,
stores the output in a temp file in order to re-arrange it in a second pass.
Instead of storing the whole output in one big temp file, it could be split
into several parts each stored in a different file, and then put together. A
new temporary resource manager should allow to easily do that.
Alexios, if you feel like exploring this idea further (you might have started
already?), then you would be most welcome, and I'll try and spare cycles to
review your work.
Thanks,
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: Alexios Giotis
> Assignee: Peter Hancock
> 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
