11:57 a.m.
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
2:36 a.m.
New subject: When are objects removed from CreationalContextImpl's lists of ContextualInstance?
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
4:08 a.m.
New subject: 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 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(a)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(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
_______________________________________________
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
6:53 a.m.
New subject: When are objects removed from CreationalContextImpl's lists of ContextualInstance?
Thank you both. I'll be sure to ask the customer if they're using
Instance.
Regards
Benjamin
From: Matej Novotny <manovotn(a)redhat.com>
To: Martin Kouba <mkouba(a)redhat.com>
Cc: Benjamin Confino <BENJAMIC(a)uk.ibm.com>, weld-dev(a)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(a)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(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
_______________________________________________
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
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
1097
days inactive
1098
days old
3 comments
3 participants
participants (3)
-
Benjamin Confino -
Martin Kouba -
Matej Novotny