Announcement Announcement Module
Collapse
No announcement yet.
Memory usage of ConfigurationInjectorBeanPostProcessor Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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?

    Using 3.1.0.RELEASE

    Thanks for any suggestions!
    Last edited by ltuska; Oct 10th, 2012, 06:37 AM. Reason: adding thanks

  • #2
    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).

    Comment


    • #3
      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.

      Comment


      • #4
        But at least i registered to this forum :-D

        Comment


        • #5
          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).

          Comment


          • #6
            Thank you very much for the help, i needed to look up "week references" in google, but i think i can handle this now ... :-)

            Comment

            Working...
            X