[
https://issues.apache.org/jira/browse/NETBEANS-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svatopluk Dedic updated NETBEANS-334:
-------------------------------------
Description:
In run tasks in a dedicated RequestProcessor; sometimes the task gets an
unexpected context ClassLoader in the worker thread. The RequestProcessor code
tries to remember the context CL in effect when it enqueues a Runnable.
But it seems that the remembered CL is only applied if a new Processor (thread)
is immediately available within the RP's limits. If the task is enqueued for
later execution because limited RP's throughput, the CL is not set to the
Processor prior to execution of the task.
The value of Thread.currentThread().getContrextClassLoader() is therefore
undefined in code run within RP. If some other task that was incidentally run
by the same thread-Processor does not clean up its changes of context CL, the
messed up CL will be used for subsequent unrelated tasks processed by that
thread.
The source however suggests that the original idea was to transfer both
(global) Lookup and context classloader to the worker code.
was:
In run tasks in a dedicated RequestProcessor; sometimes the task gets an
unexpected context ClassLoader in the worker thread. The RequestProcessor code
tries to remember the context CL in effect when it enqueues a Runnable.
But it seems that the remembered CL is only applied if a new Processor (thread)
is immediately available within the RP's limits. If the task is enqueued for
later execution because limited RP's throughput, the CL is not set to the
Processor prior to execution of the task.
The value of Thread.currentThread().getContrextClassLoader() is therefore
undefined in code run within RP.
The source however suggests that the original idea was to transfer both
(global) Lookup and context classloader to the worker code.
> RequestProcessor does not prevent from accidental Thread.contextClassLoader
> changes
> -----------------------------------------------------------------------------------
>
> Key: NETBEANS-334
> URL: https://issues.apache.org/jira/browse/NETBEANS-334
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Other
> Affects Versions: 8.2
> Reporter: Svatopluk Dedic
> Priority: Major
>
> In run tasks in a dedicated RequestProcessor; sometimes the task gets an
> unexpected context ClassLoader in the worker thread. The RequestProcessor
> code tries to remember the context CL in effect when it enqueues a Runnable.
> But it seems that the remembered CL is only applied if a new Processor
> (thread) is immediately available within the RP's limits. If the task is
> enqueued for later execution because limited RP's throughput, the CL is not
> set to the Processor prior to execution of the task.
> The value of Thread.currentThread().getContrextClassLoader() is therefore
> undefined in code run within RP. If some other task that was incidentally
> run by the same thread-Processor does not clean up its changes of context CL,
> the messed up CL will be used for subsequent unrelated tasks processed by
> that thread.
> The source however suggests that the original idea was to transfer both
> (global) Lookup and context classloader to the worker code.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
