[
https://issues.apache.org/jira/browse/WICKET-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman updated WICKET-2846:
---------------------------------
Attachment: wicket-application-leak.tar.gz
Here's a quickstart that can be used to show the "leak" of the Application
object into the Java2D Disposer thread. You have to use jvisualvm heap dump to
see it, but it's there:
1. Go to the "Classes" view.
2. Find the java.lang.Thread class.
3. Click on it and it will bring up a list of instances.
4. Find the thread with the name "Java2D Disposer" (#13 for me).
5. Look for the field called "inheritableThreadLocals" and look in its "table"
6. In there, you'll find a reference to the WicketApplication object.
The Java2D Disposer thread runs for the duration of the VM and it will keep
that reference to the application object.
> Store Application in InheritableThreadLocal instead of ThreadLocal
> ------------------------------------------------------------------
>
> Key: WICKET-2846
> URL: https://issues.apache.org/jira/browse/WICKET-2846
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Reporter: Alexandru Objelean
> Assignee: Igor Vaynberg
> Priority: Minor
> Fix For: 1.4.9
>
> Attachments: wicket-application-leak.tar.gz
>
>
> Is there any particular reason why Application class wouldn't be stored in
> InheritableThreadLocal instead of ThreadLocal? The problem is that I need to
> be able to access Application class from a thread created when a button is
> pressed. Using InheritableThreadLocal instead of ThreadLocal would solve
> this problem.
> Use case example:
> public class MyPage extends Page {
> @SpringBean
> private MyService service;
> //perform a polling of long running process triggered by a button click
> onClickButton() {
> new Thread() {
> run() {
> service.executeLongRunningProcess();
> }
> }.start();
> }
> }
> The following example won't work well if the Application is not stored in
> InheritableThreadLocal. The reason why it doesn't work, as I understand that,
> is because @SpringBean lookup depends on Application instance which is not
> accessible from within the thread. Having it stored inside of ITL would solve
> the problem.
> Thanks!
> Alex
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
