Martin is right, the first suspect is a dependent bean that is somewhere repeatedly created via Instance and never destroyed. Try to find which beans are those, it should be a noticeable chunk on the heap.

Normally CDI handles destroy itself and dependent beans are destroyed along with the bean they "belong" to. However, dynamic resolution via Instance is a special case where CDI container doesn't know when to destroy those beans and so references can be held for prolonged periods of time.

Matej

On Thu, Apr 22, 2021 at 8:37 AM Martin Kouba <mkouba@redhat.com> wrote:
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@lists.jboss.org
> To unsubscribe send an email to weld-dev-leave@lists.jboss.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>

--
Martin Kouba
Software Engineer
Red Hat, Czech Republic
_______________________________________________
weld-dev mailing list -- weld-dev@lists.jboss.org
To unsubscribe send an email to weld-dev-leave@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s