Oct 10th, 2012, 05:25 AM
[SOLVED] Memory usage of ConfigurationInjectorBeanPostProcessor
Hi dear all, i am new to this forum, so please be gentle... :-D
I have created an app which reads ids from a queue, and processes records from a database with those ids. To do that i created a taskExecutor object which uses a thread pool.
To make sure that there will be no "interferences", i use prototype-scoped processing beans.
I run a "burn-in" test the day before Yesterday, and everything went fine, except the memory usage... It seemed that there was a memory leak. Using my favourite memory analyzer, it turned out, that the ConfigurationInjectorBeanPostProcessor holds references to all already configured beans (List<Object> alreadyConfiguredBeans), and i end up with ~70k objects which i don't want to have any more (no other references to them)...
So is there a way to instruct this class not to save all references, or clean them up after the processing is complete? Or should i write my own PostProcessor?
Thanks for any suggestions!
Last edited by ltuska; Oct 10th, 2012 at 06:37 AM.
Reason: adding thanks
Oct 10th, 2012, 05:42 AM
Why use prototype-scoped beans, as long as your processor is thread safe (i.e. no state held at class level) a singleton is fine. I consider, lets use a prototype-scoped bean because we can a and it might prevent issues, a premature optimization (IMHO ofcourse).
However I now my fair share of spring classes and for the life of me Ì cannot find this class... Also it is only a reference so the beans are there (knowing spring those will be weak references) and it is only a pointer, if your prototype-scoped beans remain there must be some other references holding on (else they would be cleaned).
Oct 10th, 2012, 06:35 AM
OMG! You are very right... It is not even spring, this class comes from my company... it is just in a subpackage called Spring.
Sorry about that! My fault.
Oct 10th, 2012, 06:36 AM
But at least i registered to this forum :-D
Oct 10th, 2012, 06:56 AM
That's true ... But if it is one of your custom classes fix it Make the 'alreadyConfiguredBeans' hold weak references (you might need to change to another type or something but alas).
Oct 10th, 2012, 07:12 AM
Thank you very much for the help, i needed to look up "week references" in google, but i think i can handle this now ... :-)
Tags for this Thread