On Jul 30, 2008, at 00:19, Jeremias Maerki wrote:
On 28.07.2008 21:03:09 Andreas Delmelle wrote:
As Jeremias already noted, no obvious bugs present. All FOP does, is
open a standard InputStream and properly close it when it is no
longer needed. After that, it's up to the InputStream
the GC won't ensure immediate garbage collection.
I guess for now we can survive with Linux servers as it seems the open
handle could be safely ignored on unix systems.
Matthieu
--
View this message in context:
http://www.nabble.com/Fop-instance-keeping-handle-on-font-file-tp18689197p18716243.html
On 28.07.2008 21:03:09 Andreas Delmelle wrote:
On Jul 28, 2008, at 18:03, Matthieu Siggen wrote:
Hi
FWIW:
While debugging I found out that the fopFactory.newFop call
obtains the
handle. Unfortunately, the handle seems to be arbitrarly
released, ie. a
garbage collection is
with Java 6 on Vista)
Thank you in advance for your help :)
Regards,
Matthieu
--
View this message in context:
http://www.nabble.com/Fop-instance-keeping-handle-on-font-file-tp18689197p18689197.html
Sent from the FOP - Users mailing list archive at Nabble.com
in advance for your help :)
Regards,
Matthieu
--
View this message in context:
http://www.nabble.com/Fop-instance-keeping-handle-on-font-file-tp18689197p18689197.html
Sent from the FOP - Users mailing list archive at Nabble.com.
Jeremias Maerki
On Jul 28, 2008, at 18:03, Matthieu Siggen wrote:
Hi
FWIW:
While debugging I found out that the fopFactory.newFop call
obtains the
handle. Unfortunately, the handle seems to be arbitrarly
released, ie. a
garbage collection is sometimes necessary to free the handle.
OK, this seems to
Andreas Delmelle wrote:
If FOP itself would unnecessarily hold on to a TTF, then a GC will not
magically release it.
But if it had a FileInputStream (for example) open and forgot to close
it, then the FileInputStream finaliser would close it later, resulting
in the exact same symptoms
