0

i am currently investigating a memory leak in an application i have written. After doing some analysis on heap dumps i obtained I zeroed in on an odd behavior of MyFaces CODI.

I make heavy use of the ViewAccessScope and recently modified my code to log @PostConstruct and @PreDestroy callbacks together with the hashcode for the corresponding instance.

The PostConstruct callback is executed as I would expect, e.g. when coming from a totally different view which didn't use the bean. What bugs me is that the @PreDestroy callback is never invoked (even though i (think i) made sure there are no references to the bean anywhere on the following views).

What makes this even more confusing for me is the fact that I wrote a simple little test program with 3 views, each backed by a ViewAccesScoped Bean. When changeing the view the beans get destroyed just as I'd expect because the bean i am coming from is not referenced anywhere in the bean for the view i am navigating to.

So i guess my question would be, are there any other factors besides bean references to consider regarding the cleanup / destroy behaviour of ViewAccessScoped beans ?

I am using MyFaces CODI in Version 1.0.5 on JBoss AS Final 7.1.1

salgmachine
  • 519
  • 1
  • 3
  • 14

1 Answers1

0

I am going to answer my own question here-

The reason why the beans in question never are destroyed is because they indeed share an object which never gets unscoped. It is an object which is provided by a custom CDI portable extension.

So CODI is actually working as intended, the memory leak is not caused by CODI but by the custom CDI extension.

As I see it, the problem is that the object provided by the extension is not proxied but the instance created by the CDI extension is shared across all consuming beans.

salgmachine
  • 519
  • 1
  • 3
  • 14