[
https://issues.apache.org/jira/browse/NETBEANS-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svatopluk Dedic updated NETBEANS-334:
-------------------------------------
Labels: sd-candidate (was: )
> 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
> Assignee: Svatopluk Dedic
> Priority: Major
> Labels: sd-candidate
>
> I 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
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
