openwebbeans-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lars-Fredrik Smedberg <itsme...@gmail.com>
Subject Re: Memleak using Instance<> with dependent
Date Mon, 02 Mar 2015 08:57:04 GMT
@Mark

Some questions

1. Is the problem with produces/@Inject method you talk about only a
problem if the producer methods class is @ApplicationScoped? Can you show
by example and maybe how to work around it?
2. When you say not care about Provider I guess I can still use
Instance<...> and call get and get it working?
3. So exactly what happens (when is the produced Child destroyed? Are any
@Observes @Destroyed caled?) if I do the following:

@ApplicationScoped
public Mother {

  @Inject @TransientReference @Instance<Child> children;  //Assuming
@Inject @TransientReference @Provider<Child> will not work??

  public void doSomething() {
    Child child = children.get(); //assuming one implementation only
    child.doSomething();
  }
}



On Mon, Mar 2, 2015 at 9:11 AM, Mark Struberg <struberg@yahoo.de> wrote:

> Hi!
>
> As Romain already explained there was only the chance to not cleanup
> dependent beans properly (which might create a mem leak), or to collect
> them to be able to release them laster. Which in case of @ApplicationScoped
> parent means another mem leak. The very same problem appears if you e.g.
> inject a @Dependent bean into a producer method or @Inject method. This
> case is only fixed in the CDI-1.1 spec by marking the injection point as
> @TransientReference. I would need to dig the spec if we only let this apply
> to Instance<T>. And we do not really care about Provider<T> at all in CDI,
> except that Instance<T> extends Provider<T>.
>
> An easy solution would be to simply use DeltaSpike
> BeanProvider#getDependent. That way you can also properly destroy the bean
> _inside_ your loop already.
>
> LieGrue,
> strub
>
>
>
>
> > Am 01.03.2015 um 18:02 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
> >:
> >
> > https://issues.apache.org/jira/browse/OWB-1032
> >
> > impl should be quite easy if you want to give it a try
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
> >
> > 2015-03-01 17:58 GMT+01:00 Lars-Fredrik Smedberg <itsmeden@gmail.com>:
> > @Romain could u send the link to the jira (s)? Thanks
> >
> > On Mar 1, 2015 5:34 PM, "Lars-Fredrik Smedberg" <itsmeden@gmail.com>
> wrote:
> > @Romain Yes... we use Provider when we know there is one implementation
> and we like to lazy initialize a dep bean inside an application scoped bean
> method.... guess we could use Instance and destroy until it gets fixed in
> owb. .
> >
> > We have cases for instance where thr factory that injects instance is
> application scoped but in that case the bean implementations are scoped and
> not dependent.
> >
> > On Mar 1, 2015 5:13 PM, "Romain Manni-Bucau" <rmannibucau@gmail.com>
> wrote:
> > Yes and no. In owb it does ATM - opened a jira linked to it - but
> actually provider can be a single instance with lazy eval where Instance is
> by design multiple instances.
> > Le 1 mars 2015 16:32, "Lars-Fredrik Smedberg" <itsmeden@gmail.com> a
> écrit :
> > Shouldn't Provider faces the same issue as Instance?
> >
> > On Mar 1, 2015 10:44 AM, "Romain Manni-Bucau" <rmannibucau@gmail.com>
> wrote:
> > Owb 1.5
> >
> > I dont think it is in provider api
> >
> > Le 1 mars 2015 03:13, "Lars-Fredrik Smedberg" <itsmeden@gmail.com> a
> écrit :
> > @Romain btw destroy should work on Provider also right?
> >
> > On Mar 1, 2015 2:56 AM, "Lars-Fredrik Smedberg" <itsmeden@gmail.com>
> wrote:
> > Thanks Romain for the explanation... I guess this will solve alot of the
> use-cases / cases we talked about.
> >
> > Do you know what version of OWB this is implemented in?
> >
> > On Feb 28, 2015 10:08 PM, "Romain Manni-Bucau" <rmannibucau@gmail.com>
> wrote:
> > Well issue before was release was not bound to the created instance but
> znclosing class. Cdi 1.1 fixed it and now created instances can have their
> own lifecycle and be handled by themselves. A bit like what Unmanaged
> allows.
> >
> > @Inject Instance<A> a;
> >
> > A inst = a.get();
> > a.destroy(inst);
> >
> > Le 28 févr. 2015 17:56, "Lars-Fredrik Smedberg" <itsmeden@gmail.com> a
> écrit :
> > @Romain maybe I'm slow today (i am on vacation :-)) do u mind explain
> with an example?
> >
> > On Feb 28, 2015 5:44 PM, "Romain Manni-Bucau" <rmannibucau@gmail.com>
> wrote:
> > It call release on the instance creational context and each instance has
> a child creational context of the parent. Said otherwise it is as if the
> bean as a scope handled manually
> >
> > Le 28 févr. 2015 17:32, "Lars-Fredrik Smedberg" <itsmeden@gmail.com> a
> écrit :
> > @Romain
> >
> > Can explain to me what difference it will make (what the fix does)
> >
> > On Feb 28, 2015 3:49 PM, "Romain Manni-Bucau" <rmannibucau@gmail.com>
> wrote:
> > PS: to be complete CDI 1.x, x > 0 added destroy(X) in Instance API to
> fix it
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
> >
> > 2015-02-28 11:20 GMT+01:00 Karl Kildén <karl.kilden@gmail.com>:
> > Got it, thanks all!
> >
> > On 27 February 2015 at 19:54, John D. Ament <johndament@apache.org>
> wrote:
> > It's a good approach, I do something similar at times.  However, you
> need to make sure the beans have scopes to avoid this memory leak.
> >
> >
> > On Fri, Feb 27, 2015 at 1:47 PM Karl Kildén <karl.kilden@gmail.com>
> wrote:
> > Hrmm not sure what you mean. This is not a framework it is business
> logic and I really like to put validators in a list like this instead of if
> else if else if else if
> >
> > On 27 February 2015 at 19:37, Romain Manni-Bucau <rmannibucau@gmail.com>
> wrote:
> > Mark will surely say you that configuring anyThingCriterion will make
> your iterable size (if i can say it) = 1 even if you have 100 criterions ;)
> >
> > this is not a real spi
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Github | LinkedIn
> >
> > 2015-02-27 19:34 GMT+01:00 Karl Kildén <karl.kilden@gmail.com>:
> > Hi John!
> >
> > Summary: we use it as iterable
> >
> > Long story for completeness:
> >
> > Basically we get a thing from our business partner (inputThing) and map
> it to our representation of thing (ProcessedThing)
> >
> > Each ThingCriterion can veto the processedThing and then they used
> inputThing to print a pretty error message. When the Thing is enhanced
> (happens all the time) we implement new ThingCriterion  and they get picked
> up automatically...
> >
> >
> >
> >     @Inject
> >     private Instance<ThingCriterion> thingCriteria;
> >
> >
> >     public List<ValidationProblem> validateList(final ProcessedThing
> thing, final InputThing inputThing) {
> >         List<ValidationProblem> results = new ArrayList<>();
> >         for (final ThingCriterion criterion : thingCriteria) {
> >             results.addAll(criterion.validate(thing, inputThing));
> >         }
> >         return results;
> >     }
> >
> >
> > Romain,
> >
> > Thanks for your help. Great suggestion will it have better perf then
> just putting @ApplicationScoped on my ThingCriterion beans? Probably not
> important just curious.
> >
> > cheers
> >
> > On 27 February 2015 at 19:25, Romain Manni-Bucau <rmannibucau@gmail.com>
> wrote:
> > When I used this pattern I always did (for perf reason but side effect
> is  behavior is what you want):
> >
> > @PostConstruct
> > private void resolve() {
> >    value = instance......get();
> > }
> >
> > then in the code don't use instance at all but value.
> >
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Github | LinkedIn
> >
> > 2015-02-27 19:15 GMT+01:00 John D. Ament <john.d.ament@gmail.com>:
> > Are you calling get() on the Instance with each request (or whatever0
> that comes into this bean?
> >
> > On Fri, Feb 27, 2015 at 1:13 PM Karl Kildén <karl.kilden@gmail.com>
> wrote:
> > To explain myself further ALL I had on my heap was my
> Instance<MyInterface>... and gc released 0.5% memory :)
> >
> > I had 200 000 of them at least. They where supposed to be four
> singletons. My idea was inject into @ApplicationScoped and omit to give
> them scope because they will be @ApplicationScoped anyways... Seems every
> invocation of my @ApplicationScoped bean recreated all instances.
> >
> > What I had was unrecoverable mem leak. Now I could be doing something
> stupid or Instance<MyInterface> has a problem or something else...
> >
> > Cheers
> >
> >
> >
> > On 27 February 2015 at 19:05, Romain Manni-Bucau <rmannibucau@gmail.com>
> wrote:
> > If dependent it will be kept in enclosing bean.
> > Le 27 févr. 2015 19:00, "Lars-Fredrik Smedberg" <itsmeden@gmail.com> a
> écrit :
> >
> > So does this mean that there will be a memory leak in the case Karl
> described?
> >
> > I have used similar constructs before so im curios (@Inject @Provider
> <some dep scoped bean> in an @ApplicationScoped bean and called get () on
> the injected provider).
> >
> > I thought for a while that it might get garbage collected when the
> created bean is outof scope or maybe then there is no way for @PreDestroy
> to be called?
> >
> > Regards
> > LF
> >
> > I thought that the created dep scoped bean would be
> >
> > On Feb 27, 2015 6:07 PM, "Romain Manni-Bucau" <rmannibucau@gmail.com>
> wrote:
> > Yes.
> >
> > Will be destoyed with the bean where it is injected IIRC so the app here.
> >
> > Le 27 févr. 2015 16:59, <karl.kilden@gmail.com> a écrit :
> > Hello! I have a bean with @ApplicationScoped. When I inject
> Instance<MyInterface> instance and my actual beans implementing MyInstance
> are dependentscoped they get recreated over and over and are not gc'd.
> >
> > Expected behavior?
> >
> > Cheers
> >
> >
> >
> >
> >
> >
> >
> >
>
>


-- 
Med vänlig hälsning / Best regards

Lars-Fredrik Smedberg

STATEMENT OF CONFIDENTIALITY:
The information contained in this electronic message and any
attachments to this message are intended for the exclusive use of the
address(es) and may contain confidential or privileged information. If
you are not the intended recipient, please notify Lars-Fredrik Smedberg
immediately at itsmeden@gmail.com, and destroy all copies of this
message and any attachments.

Mime
View raw message