Exactly...
the InheritableThreadLocal is never a problem, its the thread itself not
what it possess
in the other thread this example is given:
final Application application = Application.get();
new Thread(new Runnable()
{
run() {application.xxx}
}).start();
if that thread doesnt die on a redeploy, you have the exact same leak.....
There is no difference what so ever. Its the thread/runnable object holding
on to a application instance.
But i dont mind if that InheritableThreadLocal is reverted, because i dont
see a big win in that anyway
starting new threads like above can be handled as above, but doing the above
thing or with InheritableThreadLocal is a bad design anyway
You shouldnt never just start threads for a request... Then it is so easy to
completely bomb out your server.. just hit that same request 10000 times....
Use pooling for that with a max number of threads doing what you want to
do..
If people would like we could introduce a getExecutor() in (Web)Application
and we handle the Application.set/unset for you in the Executor threads.
We could give you there options for a scheduled or none scheduled and so on.
Then creating threads on the fly isnt needed, there is no need to set the
application anywhere just use the wicket executor...
johan
On Wed, May 19, 2010 at 21:36, Juliano Viana <juli...@logicstyle.com> wrote:
> Hi Adriano,
>
> If your application creates (or uses a library that creates) threads that
> don't die when the application is redeployed then you will have a memory
> leak no matter what Wicket does.
> If, on the other hand, all your theads are well behaved and die properly
> when your application is redeployed, you have no memory leak even with
> InheritableThreadLocal.
>
> So using InheritableThreadLocal or not will not make any difference in this
> case.
>
> Regards,
> - Juliano
>
>
>
>
> On Wed, May 19, 2010 at 4:20 PM, Adriano dos Santos Fernandes <
> adrian...@gmail.com> wrote:
>
> > On 19/05/2010 15:57, Jeremy Thomerson wrote:
> >
> >> Here's how you create a quickstart:
> >> http://www.jeremythomerson.com/blog/2008/11/wicket-quickstart-tutorial/
> >>
> >> If you find that there is a bug, you zip your quickstart directory and
> >> attach it to a JIRA issue. Then we fix it and build a new release and
> >> start
> >> a new vote (if the bug is serious enough).
> >>
> >>
> >>
> > I know, I know... For example, the ones I have in Jira and got closed
> > without analyze, or the ones I attached with fixes.
> >
> > I can't, however, do it now. But I would have no reason to do it knowing
> > some folks just consider a normal thing restart the container to update
> the
> > application. So if Wicket devs are in this way, I could write no
> quickstart
> > to convince.
> >
> > Guice, by its use of thread locals, and considering that Java thread
> locals
> > are not ideal, have the same type of bug. They could solve it with an API
> to
> > close a thing, but they don't. They could ship some fancy classes that
> may
> > work (accordingly to old @crazybob says) in some cases but they also
> didn't.
> > So if you redeploy an app with Guice in Tomcat, it logs about a thread
> local
> > leak.
> >
> > It's going to do the same thing with Wicket.
> >
> >
> > Adriano
> >
> >
>
