It is just a guess...
I looked at the printing code and couldn't find anything like "dispose"
or "close".
Btw "29000 to 10000+" is shrinking.
The best would probably be to use the profiler to find out who is
generating that class.
Tilman
Am 11.04.2014 12:09, schrieb Joseph Siddal:
Hi Tilman,
My application does high volumes of printing over the course of a day so
this memory leak takes a few hours before it becomes a problem. My Demo
code just accelerates the memory leak.
The file is being printed. are you saying the fields should shrink once the
file is printed?
Regards
Joseph
On 10 April 2014 18:17, Tilman Hausherr <[email protected]> wrote:
Hi Joseph,
Just a thought - could it be that this fields grow and grow because the
file is never printed? (Obviously, you don't want to print thousands of
print jobs)
Tilman
Am 10.04.2014 13:50, schrieb Joseph Siddal:
Hi,
I've found a memory leak that is caused when doing high volumes of
printing.
The code that reproduces the bug is attached. The code just continuously
sends the same printjob to the default printer. The pdf I'm using is
available here <https://www.dropbox.com/s/7k2uzn0w0fkue11/job.pdf>. The
memory leak is evident after 6mins of running the code. The
sun.print.CustomMediaTray has 2 static ArrayList fields which are
continuously growing in size going from size 29000 to 10000+ after 6
minutes and continuing to climb.
This is using OSX Mavericks, JDK 1.8.0.
Any help would be appreciated.
Regards
Joseph
