[
https://issues.apache.org/jira/browse/FOP-2845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17937091#comment-17937091
]
Björn Kautler edited comment on FOP-2845 at 3/20/25 11:27 AM:
--------------------------------------------------------------
Hey [~ssteiner], sorry, I missed your comment.
Indeed setting that property does help to treat the symptom.
I was about to report this issue again but searched first and found my own
issue. :D
I can now say, that the point about the {{simple-page-master}} *not* being used
is exactly the problem.
In
{{org.apache.fop.apps.io.ResourceResolverFactory.NormalResourceResolver#getResource}}
the stream on the URI is directly opened as {{Resource}} is a subclass of
{{{}FilterInputStream{}}}.
But where the result of
{{org.apache.xmlgraphics.io.ResourceResolver#getResource}} is used, it is not
ensured that the stream that was created is closed.
If the resource is actually used, then the stream is closed.
But if the resource is never used like in the shown example,
then the stream is never closed and thus the file-handle leak appears.
I attached a full example as [^issue-2845.fo].
* Download that file
* put a {{draft.png}} besides it
* Execute {{java -cp 'foo/fop-2.10/fop/build/\*;foo/fop-2.10/fop/lib/\*'
org.apache.fop.cli.Main issue-2845.fo -awt}}
* Try to rename that file *on Windows* (easiest way to verify file-leak or use
any other way like listing open file handles, ...)
* Renaming (or other check) will show that the file handle is still open
* Change in the test file {{master-reference="blank"}} to
{{master-name="draft"}}
* Execute the Java command again
* No file-handle leak will be present now
* Change in the test file {{master-reference="draft"}} back to
{{master-name="blank"}}
* Execute the Java command again with
{{-Dorg.apache.xmlgraphics.image.loader.impl.AbstractImageSessionContext.no-source-reuse=true}}
* Also no file-handle leak will happen
But I think the
{{-Dorg.apache.xmlgraphics.image.loader.impl.AbstractImageSessionContext.no-source-reuse=true}}
is just symptom treatment and not an actual fix.
>From the name I would assume that this would make things slower as images that
>are needed multiple times would then be read multiple times instead of being
>taken from RAM.
was (Author: vampire):
Hey [~ssteiner], sorry, I missed your comment.
Indeed setting that property does help to treat the symptom.
I was about to report this issue again but searched first and found my own
issue. :D
I can now say, that the point about the {{simple-page-master}} *not* being used
is exactly the problem.
In
{{org.apache.fop.apps.io.ResourceResolverFactory.NormalResourceResolver#getResource}}
the stream on the URI is directly opened as {{Resource}} is a subclass of
{{{}FilterInputStream{}}}.
But where the result of
{{org.apache.xmlgraphics.io.ResourceResolver#getResource}} is used, it is not
ensured that the stream that was created is closed.
If the resource is actually used, then the stream is closed.
But if the resource is never used like in the shown example,
then the stream is never closed and thus the file-handle leak appears.
I attached a full example as [^issue-2845.fo].
* Download that file
* put a {{draft.png}} besides it
* Execute {{java -cp 'foo/fop-2.10/fop/build/*;foo/fop-2.10/fop/lib/*'
org.apache.fop.cli.Main issue-2845.fo -awt}}
* Try to rename that file *on Windows* (easiest way to verify file-leak or use
any other way like listing open file handles, ...)
* Renaming (or other check) will show that the file handle is still open
* Change in the test file {{master-reference="blank"}} to
{{master-name="draft"}}
* Execute the Java command again
* No file-handle leak will be present now
* Change in the test file {{master-reference="draft"}} back to
{{master-name="blank"}}
* Execute the Java command again with
{{-Dorg.apache.xmlgraphics.image.loader.impl.AbstractImageSessionContext.no-source-reuse=true}}
* Also no file-handle leak will happen
But I think the
{{-Dorg.apache.xmlgraphics.image.loader.impl.AbstractImageSessionContext.no-source-reuse=true}}
is just symptom treatment and not an actual fix.
>From the name I would assume that this would make things slower as images that
>are needed multiple times would then be read multiple times instead of being
>taken from RAM.
> File leak to background-image
> -----------------------------
>
> Key: FOP-2845
> URL: https://issues.apache.org/jira/browse/FOP-2845
> Project: FOP
> Issue Type: Bug
> Affects Versions: 2.3
> Reporter: Björn Kautler
> Assignee: Matthias Reischenbacher
> Priority: Major
> Attachments: issue-2845.fo
>
>
> I use FOP from within my Gradle build to produce documentation PDFs.
> So the VM usually is not closed, but the Gradle Daemon that executes the
> build stays alive.
> I built some PDF and then tried to delete the folder as it was just a test,
> but one file was still locked by the Gradle process, so FOP seems to leak
> that file resource.
> It was the {{draft.png}} that is set as {{background-image}} in this snippet.
> Also interesting, this page master was not even used, so it is even more
> suspicious why the file was opened for reading at all, but that it stays
> locked is pretty unnice.
> {code:xml}
> <fo:simple-page-master margin-right="0cm" margin-left="0cm"
> margin-bottom="0cm" margin-top="0cm" page-height="297mm" page-width="210mm"
> master-name="my-titlepage-first-draft">
> <fo:region-body column-count="1"
> column-gap="12pt"
> margin-top="0cm"
> margin-bottom="0cm"
>
> background-image="url(../../common/images/decorative/draft.png)"
> background-attachment="fixed"
> background-repeat="no-repeat"
> background-position-horizontal="center"
> background-position-vertical="center"/>
> <fo:region-before display-align="before" extent="0cm"
> region-name="xsl-region-before-first"/>
> <fo:region-after display-align="after" extent="0cm"
> region-name="xsl-region-after-first"/>
> </fo:simple-page-master>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
