Re: WICKET-2846 - Store Application in InheritableThreadLocal instead of ThreadLocal

[James Carman <ja...@carmanconsulting.com>]

Why would the application object itself need to be garbage collected?

On Wed, May 19, 2010 at 8:53 AM, Adriano dos Santos Fernandes
<ad...@gmail.com> wrote:
> On 19/05/2010 09:50, Alex Objelean wrote:
>>
>> I still don't see why using InheritableThreadLocal would introduce memory
>> leaks when dealing with threads. Do you have a good example to prove it? I
>> don't see any difference...
>>
>
> The application instance would go to arbitrary (like ones possible created
> by Java core library) and would never be garbaged collected.
>
>
> Adriano
>
>

Re: WICKET-2846 - Store Application in InheritableThreadLocal instead of ThreadLocal

[Adriano dos Santos Fernandes <ad...@gmail.com>]

On 19/05/2010 14:35, James Carman wrote:
> On Wed, May 19, 2010 at 11:56 AM, Adriano dos Santos Fernandes
> <ad...@gmail.com>  wrote:
>    
>> I suggest to not change something in a minor release that breaks things that
>> is working. I also suggest this shouldn't be done by default in major
>> releases as well.
>>
>> I see no way JRebel or any tool going to remove thread locals knowing what
>> its being done.
>>      
> JRebel won't require totally blowing away your application object.
> It'll just swap out the underlying logic behind it when you restart
> your application.
>    
AFAIU, JRebel has nothing to do with the problem I referred, sorry. I've 
no problem with redeploy, at least, not caused by Wicket so far, and it 
would be very desirable that Wicket doesn't go this way.


Adriano

Re: WICKET-2846 - Store Application in InheritableThreadLocal instead of ThreadLocal

[tetsuo <ro...@gmail.com>]

JRebel is intended to be used in development, not in production. In
production, you want to undeploy and redeploy your application and,
hopefully, leave no old ClassLoader reference behind.

I'm not sure if InheritableThreadLocal will create memory leaks, but I know
it is something to be very carefully considered.



On Wed, May 19, 2010 at 2:35 PM, James Carman <ja...@carmanconsulting.com>wrote:

> On Wed, May 19, 2010 at 11:56 AM, Adriano dos Santos Fernandes
> <ad...@gmail.com> wrote:
> >
> > I suggest to not change something in a minor release that breaks things
> that
> > is working. I also suggest this shouldn't be done by default in major
> > releases as well.
> >
> > I see no way JRebel or any tool going to remove thread locals knowing
> what
> > its being done.
>
> JRebel won't require totally blowing away your application object.
> It'll just swap out the underlying logic behind it when you restart
> your application.
>

Re: WICKET-2846 - Store Application in InheritableThreadLocal instead of ThreadLocal

[James Carman <ja...@carmanconsulting.com>]

On Wed, May 19, 2010 at 11:56 AM, Adriano dos Santos Fernandes
<ad...@gmail.com> wrote:
>
> I suggest to not change something in a minor release that breaks things that
> is working. I also suggest this shouldn't be done by default in major
> releases as well.
>
> I see no way JRebel or any tool going to remove thread locals knowing what
> its being done.

JRebel won't require totally blowing away your application object.
It'll just swap out the underlying logic behind it when you restart
your application.

Re: WICKET-2846 - Store Application in InheritableThreadLocal instead of ThreadLocal

[Adriano dos Santos Fernandes <ad...@gmail.com>]

On 19/05/2010 12:50, James Carman wrote:
> Use JRebel!  Problem solved. :)
>    
I suggest to not change something in a minor release that breaks things 
that is working. I also suggest this shouldn't be done by default in 
major releases as well.

I see no way JRebel or any tool going to remove thread locals knowing 
what its being done.


Adriano

Re: WICKET-2846 - Store Application in InheritableThreadLocal instead of ThreadLocal

[James Carman <ja...@carmanconsulting.com>]

Use JRebel!  Problem solved. :)

On Wed, May 19, 2010 at 10:03 AM, Adriano dos Santos Fernandes
<ad...@gmail.com> wrote:
> On 19/05/2010 10:57, James Carman wrote:
>>
>> Why would the application object itself need to be garbage collected?
>>
>
> To hot-deployment not eat your memory.
>
>
> Adriano
>
> PS: I'm much more worried in production environments. Restarting the
> container because you need to update the application is something I consider
> an awful practice.
>
>

Re: WICKET-2846 - Store Application in InheritableThreadLocal instead of ThreadLocal

[Adriano dos Santos Fernandes <ad...@gmail.com>]

On 19/05/2010 10:57, James Carman wrote:
> Why would the application object itself need to be garbage collected?
>    
To hot-deployment not eat your memory.


Adriano

PS: I'm much more worried in production environments. Restarting the 
container because you need to update the application is something I 
consider an awful practice.