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

[Juliano Viana <ju...@logicstyle.com>]

Hi everyone,

I know this issue has already been debated and that a decision was made to
revert this change in a future version of Wicket.
However, the discussions about this issue were centered on the fact starting
threads in web applications is not a good idea anyway, and hence this would
not break applications that are not already broken.
I have found a real case where this breaks an innocent application:
redeploying an application based on  Wicket 1.4.9 on Glassfish 3.0.1 causes
a memory leak due to the use of InheritableThreadLocal.
The problem is that when the application accesses a JDBC resource for the
first time, Glassfish lazily starts a timer (connector-timer-proxy) that has
an associated thread. This timer is started  from the web request processing
thread. This thread never dies, and inherits a reference to the Wicket
Application object.
This only happens on redeployments, but it really hurts development as you
keep having to restart Glassfish due to OOM exceptions.
Removing the InheritableThreadLocal resolves the issue completely and makes
development really smooth again.
So if you are using Wicket 1.4.9 with Glassfish v3 you should consider
patching it until a new Wicket release is out.

Regards,
  - Juliano


On Thu, May 20, 2010 at 2:46 PM, tetsuo <ro...@gmail.com> wrote:

> On Thu, May 20, 2010 at 10:29 AM, Johan Compagner <jcompagner@gmail.com
> >wrote:
>
> > But using
> >
> > final Application app = Application.get()
> > // start thread
> >
> > is exactly the same kind of leakage as using InheritableThreadLocal
> >
> >
> Exactly, the bug is not in Wicket, it's in the application, which doesn't
> manage threads correctly.
>