[
https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13577086#comment-13577086
]
Alexios Giotis commented on FOP-2211:
-------------------------------------
Hi Vincent,
Thanks for your prompt comment. I don't think that the patch prevents anyone
from plugging another implementation keeping files in memory but I also see
that discrepancy. My opinion is indeed that temporary resources should not be
handled through URIs. As you might noticed in the patch, it makes code more
complex. I had to keep a map from the 'unique' tmp URI to the actual unique
file. A non-URI related class handling them could use the
DeferredFileOutputStream [1] of commons-io (an existing FOP dependency). This
stream has a threshold for switching from memory to disk. If there is a need to
customize something besides that threshold, then we could extract another
interface and have a default implementation using such a stream.
If there is a consensus, I could remove the delete() method from the
ResourceResolver and write a new class for handling temp resources (or an
interface if this needs to be configurable). I think it will be better than
switching back to the createTempFile.
[1]
http://commons.apache.org/io/api-1.3/org/apache/commons/io/output/DeferredFileOutputStream.html
> [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, 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
