In general, the dependent objects are destroyed when the
CreationalContext.release() method is called, i.e. when a bean is
destroyed. However, the implementation is a bit convoluted in order to
handle various corner cases.
I'd recommend to track down the beans that reference the problematic CC
instances and verify they're used correctly. A common source of similar
memory leaks is the incorrect usage of javax.enterprise.inject.Instance,
including CDI.current(), i.e. each Instance.get() for a @Dependent bean
results in a new dependent instance that is stored in the relevant
CreationalContext. See also
http://weld.cdi-spec.org/documentation/#6.
HTH
Martin
On 21. 04. 21 17:57, Benjamin Confino wrote:
Hello
I have a customer who is experiencing out of memory errors. A memory
analysis has found a CreationalContextImpl object containing a
Collections$SynchronizedRandomAccessList that in turn contains a lot of
SerializableContextualInstanceImpl objects. While the Memory Analysis
cannot provide field names there are only two lists it could be:
parentDependentInstances and dependentInstances
Given this I was hoping someone could tell me when objects are supposed
to be removed from those two lists, and what/who is responsible for
triggering removal from those two lists? I do not see any code to remove
an object from parentDependentInstances and while objects are removed
from dependentInstances they are done so in the method
destroyDependentInstance, which is not part of either of the public
interfaces implemented by this class:
javax.enterprise.context.spi.CreationalContext and
org.jboss.weld.construction.api.WeldCreationalContext
Thank you for your help
Benjamin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
_______________________________________________
weld-dev mailing list -- weld-dev(a)lists.jboss.org
To unsubscribe send an email to weld-dev-leave(a)lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
--
Martin Kouba
Software Engineer
Red Hat, Czech Republic