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 Sun, 01 Mar 2015 01:56:38 GMT
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 <https://twitter.com/rmannibucau> |  Blog
>>>>> <http://rmannibucau.wordpress.com> | Github
>>>>> <https://github.com/rmannibucau> | LinkedIn
>>>>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>>>>> <http://www.tomitribe.com>
>>>>>
>>>>> 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 <https://twitter.com/rmannibucau>
|  Blog
>>>>>>>>> <http://rmannibucau.wordpress.com> | Github
>>>>>>>>> <https://github.com/rmannibucau> | LinkedIn
>>>>>>>>> <https://www.linkedin.com/in/rmannibucau>
>>>>>>>>>
>>>>>>>>> 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 <https://twitter.com/rmannibucau>
|  Blog
>>>>>>>>>>> <http://rmannibucau.wordpress.com> | Github
>>>>>>>>>>> <https://github.com/rmannibucau> | LinkedIn
>>>>>>>>>>> <https://www.linkedin.com/in/rmannibucau>
>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>

Mime
View raw message