You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by aemitic <ae...@hotmail.it> on 2013/04/18 13:09:21 UTC
FOP memory growing with a lot of
Hi,
I noticed that FOP (any version) uses a constantly growing amount of memory
when creating PDFs. Even if using very small <page-sequence> blocks and no
forward references.
Please refer to this stackoverflow question which contains a small java
program that replicates the issue.
How can I limit the amount of used memory when transforming to PDF an FO
file with a huge number of <page-sequence> blocks? (> 250000)
Thanks for any help
--
View this message in context: http://apache-fop.1065347.n5.nabble.com/FOP-memory-growing-with-a-lot-of-page-sequences-tp38355.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: FOP memory growing with a lot of
Posted by aemitic <ae...@hotmail.it>.
Thanks Luis Bernardo, your explanation is really helpful.
So, it is a Fop limitation.
I shall find the good balance between <fo:page-sequence> blocks number and
the number of pages contained in them.
I guess this info might save a lot of time to someone else in the future.
Especially to business users who are elaborating big big data. Maybe it
should be added to the Fop website under the memory consumption notes? Just
a suggestion.
Thanks again to everyone!
--
View this message in context: http://apache-fop.1065347.n5.nabble.com/FOP-memory-growing-with-a-lot-of-page-sequence-blocks-250000-tp38355p38368.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: FOP memory growing with a lot of
Posted by Luis Bernardo <lm...@gmail.com>.
You can't. Although it is true that memory is regained when a page is
output, there is information that needs to be kept till the end, and
that information keeps growing as you add pages. For instance, byte
offsets for the objects need to be stored till the end to build the xref
table, and right now all that is kept in memory.
You can get somewhat better results if you allow your page sequences to
have more than one page (say, 100 or 1000). Putting all the pages in one
page-sequence will not work either because you will run out of memory
during the initial phase of building the FO tree.
On the other hand you can always increase the memory your jvm uses.
On 4/18/13 12:09 PM, aemitic wrote:
> Hi,
>
> I noticed that FOP (any version) uses a constantly growing amount of memory
> when creating PDFs. Even if using very small <page-sequence> blocks and no
> forward references.
>
> Please refer to this stackoverflow question which contains a small java
> program that replicates the issue.
>
> How can I limit the amount of used memory when transforming to PDF an FO
> file with a huge number of <page-sequence> blocks? (> 250000)
>
> Thanks for any help
>
>
>
> --
> View this message in context: http://apache-fop.1065347.n5.nabble.com/FOP-memory-growing-with-a-lot-of-page-sequences-tp38355.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: FOP memory growing with a lot of
Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
well - it is one print job, has paperhandling marks, goes to an envelope stuffing machine ....
Maruan Sahyoun
Am 19.04.2013 um 14:56 schrieb "Kerry, Richard" <ri...@atos.net>:
>
> Yes I did understand what you wrote, and the earlier correspondent.
>
> I was attempting to ask why.
> It seems illogical to treat many small documents as one large one. Especially if the large one is so large that it is hard to process.
>
>
> Regards,
> Richard.
>
>
>
>
>
> Richard Kerry
> BNCS Engineer
> T: +44 (0)20 82259063
> M: +44 (0)7812 325518
> Room EBX 301, BBC Television Centre, Wood Lane, London, W12 7RJ
> richard.kerry@atos.net
> uk.atos.net
>
>
>
>
>
> This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable
> From: Maruan Sahyoun [sahyoun@fileaffairs.de]
> Sent: 19 April 2013 12:04
> To: fop-users@xmlgraphics.apache.org
> Subject: Re: FOP memory growing with a lot of <page-sequences>
>
> no - that's one document with 100k pages
>
> Maruan Sahyoun
>
> Am 19.04.2013 um 13:04 schrieb "Kerry, Richard" <ri...@atos.net>:
>
>>
>> Surely that's 100k documents, each with one page (or a small number of pages) ?
>>
>>
>> Uncertainly,
>> Richard.
>>
>>
>>
>>
>>
>>
>> Richard Kerry
>> BNCS Engineer
>> T: +44 (0)20 82259063
>> M: +44 (0)7812 325518
>> Room EBX 301, BBC Television Centre, Wood Lane, London, W12 7RJ
>> richard.kerry@atos.net
>> uk.atos.net
>>
>>
>>
>>
>>
>> This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable
>> From: Maruan Sahyoun [sahyoun@fileaffairs.de]
>> Sent: 19 April 2013 11:56
>> To: fop-users@xmlgraphics.apache.org
>> Subject: Re: FOP memory growing with a lot of <page-sequences>
>>
>> Hi
>>
>> e.g. we have a banking customer where account statements are produced and sent for printing. A single PDF has around 100k pages.
>>
>> Maruan
>>
>> Am 19.04.2013 um 11:04 schrieb Paul Womack <su...@papermule.co.uk>:
>>
>>> aemitic wrote:
>>>> Thanks for the suggestion.
>>>>
>>>> This /workaround/ (it's not a solution) cannot be applied. Why:
>>>> - internal pdf links would not work
>>>> - pdf bookmarks would not work
>>>> - page numbering would not be correct
>>>> - creating over 150000 PDFs and then merging them with an external tool is
>>>> unacceptable from a performance point of view
>>>
>>> I cannot imagine a (useful) PDF with 150,000 pages.
>>>
>>> This may well be a limitation of my imagination :-)
>>>
>>> Can you tell me a little about this?
>>>
>>> BugBear
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
>>> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
> <blank>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: FOP memory growing with a lot of
Posted by paul womack <pw...@papermule.co.uk>.
Kerry, Richard wrote:
> Yes I did understand what you wrote, and the earlier correspondent.
>
> I was attempting to ask why.
>
> It seems illogical to treat many small documents as one large one. Especially if the large one is so large that it is hard to process.
That case sounds (to me) like many "documents" in one large "print job".
I suppose one might consider turning a whole wiki (they can get big, I'm told)
into a single hyperlinked PDF. That would be a legitimate, and fairly useful
massive PDF.
BugBear
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
RE: FOP memory growing with a lot of
Posted by "Kerry, Richard" <ri...@atos.net>.
Yes I did understand what you wrote, and the earlier correspondent.
I was attempting to ask why.
It seems illogical to treat many small documents as one large one. Especially if the large one is so large that it is hard to process.
Regards,
Richard.
[Blue line]
Richard Kerry
BNCS Engineer
T: +44 (0)20 82259063[cid:8CFF92A-DBC6-4E1DD-83CD-7AC227DEC5@MimeCtl]<about:blank#>
M: +44 (0)7812 325518[cid:8CFF92A-DBC6-4E1DD-83CD-7AC227DEC5@MimeCtl]<about:blank#>
Room EBX 301, BBC Television Centre, Wood Lane, London, W12 7RJ
richard.kerry@atos.net<https://webmail.siemens-it-solutions.com/owa/redir.aspx?C=9fb20d019e3e4cb99344d708709a3177&URL=mailto%3arichard.kerry%40atos.net>
uk.atos.net<https://webmail.siemens-it-solutions.com/owa/redir.aspx?C=9fb20d019e3e4cb99344d708709a3177&URL=http%3a%2f%2fuk.atos.net%2fen-uk%2f>
[Atos logo]
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable
________________________________
From: Maruan Sahyoun [sahyoun@fileaffairs.de]
Sent: 19 April 2013 12:04
To: fop-users@xmlgraphics.apache.org
Subject: Re: FOP memory growing with a lot of <page-sequences>
no - that's one document with 100k pages
Maruan Sahyoun
Am 19.04.2013 um 13:04 schrieb "Kerry, Richard" <ri...@atos.net>>:
Surely that's 100k documents, each with one page (or a small number of pages) ?
Uncertainly,
Richard.
Richard Kerry
BNCS Engineer
T: +44 (0)20 82259063
M: +44 (0)7812 325518
Room EBX 301, BBC Television Centre, Wood Lane, London, W12 7RJ
richard.kerry@atos.net<https://webmail.siemens-it-solutions.com/owa/redir.aspx?C=9fb20d019e3e4cb99344d708709a3177&URL=mailto%3arichard.kerry%40atos.net>
uk.atos.net<https://webmail.siemens-it-solutions.com/owa/redir.aspx?C=9fb20d019e3e4cb99344d708709a3177&URL=http%3a%2f%2fuk.atos.net%2fen-uk%2f>
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable
________________________________
From: Maruan Sahyoun [sahyoun@fileaffairs.de<ma...@fileaffairs.de>]
Sent: 19 April 2013 11:56
To: fop-users@xmlgraphics.apache.org<ma...@xmlgraphics.apache.org>
Subject: Re: FOP memory growing with a lot of <page-sequences>
Hi
e.g. we have a banking customer where account statements are produced and sent for printing. A single PDF has around 100k pages.
Maruan
Am 19.04.2013 um 11:04 schrieb Paul Womack <su...@papermule.co.uk>>:
aemitic wrote:
Thanks for the suggestion.
This /workaround/ (it's not a solution) cannot be applied. Why:
- internal pdf links would not work
- pdf bookmarks would not work
- page numbering would not be correct
- creating over 150000 PDFs and then merging them with an external tool is
unacceptable from a performance point of view
I cannot imagine a (useful) PDF with 150,000 pages.
This may well be a limitation of my imagination :-)
Can you tell me a little about this?
BugBear
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org<ma...@xmlgraphics.apache.org>
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org<ma...@xmlgraphics.apache.org>
Re: FOP memory growing with a lot of
Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
no - that's one document with 100k pages
Maruan Sahyoun
Am 19.04.2013 um 13:04 schrieb "Kerry, Richard" <ri...@atos.net>:
>
> Surely that's 100k documents, each with one page (or a small number of pages) ?
>
>
> Uncertainly,
> Richard.
>
>
>
>
>
>
> Richard Kerry
> BNCS Engineer
> T: +44 (0)20 82259063
> M: +44 (0)7812 325518
> Room EBX 301, BBC Television Centre, Wood Lane, London, W12 7RJ
> richard.kerry@atos.net
> uk.atos.net
>
>
>
>
>
> This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable
>
> From: Maruan Sahyoun [sahyoun@fileaffairs.de]
> Sent: 19 April 2013 11:56
> To: fop-users@xmlgraphics.apache.org
> Subject: Re: FOP memory growing with a lot of <page-sequences>
>
> Hi
>
> e.g. we have a banking customer where account statements are produced and sent for printing. A single PDF has around 100k pages.
>
> Maruan
>
> Am 19.04.2013 um 11:04 schrieb Paul Womack <su...@papermule.co.uk>:
>
>> aemitic wrote:
>>> Thanks for the suggestion.
>>>
>>> This /workaround/ (it's not a solution) cannot be applied. Why:
>>> - internal pdf links would not work
>>> - pdf bookmarks would not work
>>> - page numbering would not be correct
>>> - creating over 150000 PDFs and then merging them with an external tool is
>>> unacceptable from a performance point of view
>>
>> I cannot imagine a (useful) PDF with 150,000 pages.
>>
>> This may well be a limitation of my imagination :-)
>>
>> Can you tell me a little about this?
>>
>> BugBear
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
>> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>>
>
>
RE: FOP memory growing with a lot of
Posted by "Kerry, Richard" <ri...@atos.net>.
Surely that's 100k documents, each with one page (or a small number of pages) ?
Uncertainly,
Richard.
Richard Kerry
BNCS Engineer
T: +44 (0)20 82259063
M: +44 (0)7812 325518
Room EBX 301, BBC Television Centre, Wood Lane, London, W12 7RJ
richard.kerry@atos.net<https://webmail.siemens-it-solutions.com/owa/redir.aspx?C=9fb20d019e3e4cb99344d708709a3177&URL=mailto%3arichard.kerry%40atos.net>
uk.atos.net<https://webmail.siemens-it-solutions.com/owa/redir.aspx?C=9fb20d019e3e4cb99344d708709a3177&URL=http%3a%2f%2fuk.atos.net%2fen-uk%2f>
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable
________________________________
From: Maruan Sahyoun [sahyoun@fileaffairs.de]
Sent: 19 April 2013 11:56
To: fop-users@xmlgraphics.apache.org
Subject: Re: FOP memory growing with a lot of <page-sequences>
Hi
e.g. we have a banking customer where account statements are produced and sent for printing. A single PDF has around 100k pages.
Maruan
Am 19.04.2013 um 11:04 schrieb Paul Womack <su...@papermule.co.uk>>:
aemitic wrote:
Thanks for the suggestion.
This /workaround/ (it's not a solution) cannot be applied. Why:
- internal pdf links would not work
- pdf bookmarks would not work
- page numbering would not be correct
- creating over 150000 PDFs and then merging them with an external tool is
unacceptable from a performance point of view
I cannot imagine a (useful) PDF with 150,000 pages.
This may well be a limitation of my imagination :-)
Can you tell me a little about this?
BugBear
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org<ma...@xmlgraphics.apache.org>
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org<ma...@xmlgraphics.apache.org>
Re: FOP memory growing with a lot of
Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
Hi
e.g. we have a banking customer where account statements are produced and sent for printing. A single PDF has around 100k pages.
Maruan
Am 19.04.2013 um 11:04 schrieb Paul Womack <su...@papermule.co.uk>:
> aemitic wrote:
>> Thanks for the suggestion.
>>
>> This /workaround/ (it's not a solution) cannot be applied. Why:
>> - internal pdf links would not work
>> - pdf bookmarks would not work
>> - page numbering would not be correct
>> - creating over 150000 PDFs and then merging them with an external tool is
>> unacceptable from a performance point of view
>
> I cannot imagine a (useful) PDF with 150,000 pages.
>
> This may well be a limitation of my imagination :-)
>
> Can you tell me a little about this?
>
> BugBear
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
Re: FOP memory growing with a lot of
Posted by Paul Womack <su...@papermule.co.uk>.
aemitic wrote:
> Thanks for the suggestion.
>
> This /workaround/ (it's not a solution) cannot be applied. Why:
> - internal pdf links would not work
> - pdf bookmarks would not work
> - page numbering would not be correct
> - creating over 150000 PDFs and then merging them with an external tool is
> unacceptable from a performance point of view
I cannot imagine a (useful) PDF with 150,000 pages.
This may well be a limitation of my imagination :-)
Can you tell me a little about this?
BugBear
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: FOP memory growing with a lot of
Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
I'm not a fop expert but
o could you render individual page-sequences to the intermediate format
o stitch the intermediate results together
o do the final rendering based on the intermediate format
Just an idea. Don't know if that would work. I also think that merging 150000 PDF's is not ideal (although I have done that for a banking customer)
Maruan Sahyoun
Am 18.04.2013 um 17:01 schrieb aemitic <ae...@hotmail.it>:
> Thanks for the suggestion.
>
> This /workaround/ (it's not a solution) cannot be applied. Why:
> - internal pdf links would not work
> - pdf bookmarks would not work
> - page numbering would not be correct
> - creating over 150000 PDFs and then merging them with an external tool is
> unacceptable from a performance point of view
>
>
>
>
> --
> View this message in context: http://apache-fop.1065347.n5.nabble.com/FOP-memory-growing-with-a-lot-of-page-sequence-blocks-250000-tp38355p38362.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
Re: FOP memory growing with a lot of
Posted by Glenn Adams <gl...@skynav.com>.
It depends on what tool you use to combine them. In any case, I don't think
you will find an alternative any time soon. Just a heads up. If you care to
create a patch that solves this problem, then please post it and I'll make
sure it is applied ASAP.
On Thu, Apr 18, 2013 at 9:01 AM, aemitic <ae...@hotmail.it> wrote:
> Thanks for the suggestion.
>
> This /workaround/ (it's not a solution) cannot be applied. Why:
> - internal pdf links would not work
> - pdf bookmarks would not work
> - page numbering would not be correct
> - creating over 150000 PDFs and then merging them with an external tool is
> unacceptable from a performance point of view
>
>
>
>
> --
> View this message in context:
> http://apache-fop.1065347.n5.nabble.com/FOP-memory-growing-with-a-lot-of-page-sequence-blocks-250000-tp38355p38362.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
Re: FOP memory growing with a lot of
Posted by aemitic <ae...@hotmail.it>.
Thanks for the suggestion.
This /workaround/ (it's not a solution) cannot be applied. Why:
- internal pdf links would not work
- pdf bookmarks would not work
- page numbering would not be correct
- creating over 150000 PDFs and then merging them with an external tool is
unacceptable from a performance point of view
--
View this message in context: http://apache-fop.1065347.n5.nabble.com/FOP-memory-growing-with-a-lot-of-page-sequence-blocks-250000-tp38355p38362.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: FOP memory growing with a lot of
Posted by Glenn Adams <gl...@skynav.com>.
use a separate tool to combine the PDFs
On Thu, Apr 18, 2013 at 8:31 AM, aemitic <ae...@hotmail.it> wrote:
> @Glenn Adams-2
> Could you please elaborate more?
>
> Transforming multiple XSL-FO files with FOP would mean to produce multiple
> XSL-FO files, wouldn't it?
> I need to produce a single PDF.
>
>
>
> --
> View this message in context:
> http://apache-fop.1065347.n5.nabble.com/FOP-memory-growing-with-a-lot-of-page-sequence-blocks-250000-tp38355p38360.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
Re: FOP memory growing with a lot of
Posted by aemitic <ae...@hotmail.it>.
@Glenn Adams-2
Could you please elaborate more?
Transforming multiple XSL-FO files with FOP would mean to produce multiple
XSL-FO files, wouldn't it?
I need to produce a single PDF.
--
View this message in context: http://apache-fop.1065347.n5.nabble.com/FOP-memory-growing-with-a-lot-of-page-sequence-blocks-250000-tp38355p38360.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: FOP memory growing with a lot of
Posted by Glenn Adams <gl...@skynav.com>.
Put each page-sequence in a separate XSL-FO file.
On Thu, Apr 18, 2013 at 5:09 AM, aemitic <ae...@hotmail.it> wrote:
> Hi,
>
> I noticed that FOP (any version) uses a constantly growing amount of memory
> when creating PDFs. Even if using very small <page-sequence> blocks and no
> forward references.
>
> Please refer to this stackoverflow question which contains a small java
> program that replicates the issue.
>
> How can I limit the amount of used memory when transforming to PDF an FO
> file with a huge number of <page-sequence> blocks? (> 250000)
>
> Thanks for any help
>
>
>
> --
> View this message in context:
> http://apache-fop.1065347.n5.nabble.com/FOP-memory-growing-with-a-lot-of-page-sequences-tp38355.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
Re: FOP memory growing with a lot of blocks
(>250000)
Posted by aemitic <ae...@hotmail.it>.
@Bonekrusher
The test application I created and put in the StackOverflow question (linked
in the post above) clearly shows how the Java's Garbage Collection *can't
and does not* free up the memory.
--
View this message in context: http://apache-fop.1065347.n5.nabble.com/FOP-memory-growing-with-a-lot-of-page-sequence-blocks-250000-tp38355p38359.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: FOP memory growing with a lot of blocks
(>250000)
Posted by Bonekrusher <dj...@yahoo.com>.
Hi,
I've created some pretty large PDFs (e.g 500+ pages) with a lot of graphics.
IMO, although memory usage increases, eventually Java's Garbage Collection
will free up your memory.
--
View this message in context: http://apache-fop.1065347.n5.nabble.com/FOP-memory-growing-with-a-lot-of-page-sequence-blocks-250000-tp38355p38356.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org