Alexios Giotis commented on FOP-2211:

Hi Simon, since DefaultTempResourceResolver and TempAwareResourceResolver are 
both private inner classes of ResourceResolverFactory, I guess your are calling 
the  "public static ResourceResolver createTempAwareResourceResolver()". In 
that case you are passing an  implementation of TempResourceResolver and 
another implementation of ResourceResolver. I will wait for some more input 
before creating another patch. 

In the meantime, it would help to understand why you need to create your own 
temp resource handler. There are currently 3 cases for using temp resources. 

1. CachedRenderPagesModel which is used  "if 
(userAgent.isConserveMemoryPolicyEnabled())". Trying to conserve memory by 
serialising Java objects in memory sounds a bad idea.

2. AFPStream
Writing an AFP document in memory is again questionable. AFP documents are 
typically used for printing and to my experience each AFP file contains 
thousands of pages (unless this is a test).

3. PSDocumentHandler 
This is used to optimise the postscript resources and actually writes the 
postscript output firstly in the temp resource and then in normal output 
stream. So, it depends on the size of the output.

Which use case are you using ? Is there a measurable difference in performance ?

My experience is that FOP performance is CPU and memory bound, not disk bound. 
What is yours ?

> [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

Reply via email to