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

["Chris Bowditch (JIRA)" <ji...@apache.org>]

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

Chris Bowditch edited comment on FOP-2211 at 2/21/13 10:43 AM:
---------------------------------------------------------------

Hi Alexios.

A Virtual File System is a really useful tool in a cloud environment as different components running on different physical machines can talk to each other and read/write data to shared resources, without having to rely on shared drives.

It may be unlikely that a temp file written by tenant A can be read by tenant B, but compliance dictates that we should put safeguards in place to ensure 0% risk of such an occurance, We have the virtual file system which is partitioned by tenant so why not use that? Just need an interface in FOP to allow temp files to be handled in a way other than temp files. Of course that interface should not prevent temporary data still being handled in temp files, so we will look to make the necessary revisions to ensure both use cases are possible.

Thanks,

Chris
                
      was (Author: cbowditch):
    Hi Alexios.

A Virtual File System is a really useful tool in a cloud environment as different components running on different physical machines can talk to each other and read/write data to shared resources, without having to rely on shared drives.

It may be unlikely that a temp file written by tenant A can be read by tenant B, but compliance dictates that we should put safeguards in place to esnure 0% risk of such an occurance, We have the virtual file system which is partitioned by tenant so why not use that? Just need an interface in FOP to allow temp files to be handled in a way other than temp files. Of course that interface should not prevent temporary data still being handled in temp files, so we will look to make the necessary revisions to ensure both use cases are possible.

Thanks,

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