openwebbeans-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Kildén <karl.kil...@gmail.com>
Subject Re: Memleak using Instance<> with dependent
Date Sat, 28 Feb 2015 10:20:35 GMT
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