Thank you both. I'll be sure to ask the customer if they're using Instance.

Regards
Benjamin



From:        Matej Novotny <manovotn@redhat.com>
To:        Martin Kouba <mkouba@redhat.com>
Cc:        Benjamin Confino <BENJAMIC@uk.ibm.com>, weld-dev@lists.jboss.org
Date:        22/04/2021 09:09
Subject:        [EXTERNAL] Re: [weld-dev] Re: When are objects removed from CreationalContextImpl's lists of ContextualInstance?

---

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 ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
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


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