Yes, as I said the annotation was just there by accident.
But thanks for making it clear.
I guess using ObjectLocator.proxy has the same effect? One has to be careful
not to misuse this feature.
Well, Howards, thanks for taking the minute :-)
I already had a peek at the latest 5.4 code and even got a small test-app
running without problems so far. Great job!
Am 30.11.2012 um 18:52 schrieb Howard Lewis Ship:
> Per-thread scope means to create a new implementation, via the builder
> method, once for every request: buldUserCacheSupport() is invoked the first
> time any method of UserCacheSupport is invoked.
>
> EnvironmentalBuilder creates a proxy class and instance, and is intended to
> only be invoked once per service; that is, a singleton service. Since it
> is being invoked multiple times, it is creating one proxy class after
> another, and these are accumulating in PermGen.
>
> There is no need to make UserCacheSupport per-thread, since everything in
> the Environment is already per-thread.
>
>
> On Fri, Nov 30, 2012 at 9:48 AM, Christian Riedel
> <cr.ml...@googlemail.com>wrote:
>
>> Hi everone,
>>
>> today I found the reason for a recent memory leak and I thought I'd ask
>> what you think of it:
>>
>> Rather by accident I annotated one of the
>> EnvironmentalShadowBuilder-methods with @Scope(PERTHREAD)
>>
>> @Scope(ScopeConstants.PERTHREAD)
>> public UserCacheSupport buildUserCacheSupport() {
>>
>> return environmentalBuilder.build(UserCacheSupport.class);
>> }
>>
>> (UserCacheSupport is just a custom environmental)
>>
>> So I removed the annotation and everything is ok again.
>>
>> But: Isn't that strange? Is that a known behavior? Using jhat I found
>> thousands of undead UserCacheSupport classes tied to a PlasticClassLoader.
>> So Plastic creates one class per request (i.e. per thread) and.. somehow
>> keeps it. Without the explicit @Scope setting there should also be one new
>> object per thread, but it does not cause a leak (since there's not a new
>> class for each request, I guess). I'm wondering if it's actually a bug in
>> Tapestry?
>>
>> Cheers
>> Christian
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
