[
https://issues.apache.org/jira/browse/HDFS-14251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16758294#comment-16758294
]
Uwe Schindler commented on HDFS-14251:
--------------------------------------
In addition in Java 9 and later, the "no privilges" at all also applies to any
ForkJoinPool, not only the common pool. The Javadocs aren't very specific about
that, but the ForkJoinPool source code shows this: When a security manager is
enabled, all the threads spawned by it use no privilges at all, they are
started with AccessController.doPrivileged and a "nothing allowed" policy.
The common pool and also ForkJoinPools should never ever be used for
IO-intensive stuff, they should be used for computations only (to enhance CPU
thorughput). This may be one reason why the pool's threads don't get any
privileges!
> BlockPoolSlice ForkJoinPool introduced by HDFS-13768 breaks under Java
> SecurityManager
> ---------------------------------------------------------------------------------------
>
> Key: HDFS-14251
> URL: https://issues.apache.org/jira/browse/HDFS-14251
> Project: Hadoop HDFS
> Issue Type: Bug
> Affects Versions: 2.10.0, 3.2.0, 3.1.2
> Reporter: Kevin Risden
> Priority: Major
>
> HDFS-13768 introduced ForkJoinPool to improve performance of BlockPoolSlice.
> The created ForkJoinPool doesn't pass in a custom thread factory and by
> default the thread factory prevents all privileges under the Java
> SecurityManager.
> This broke when integrating Hadoop 3.2.0 with Apache Solr in SOLR-9515.
> It isn't clear that the ForkJoinPool is necessary when a regular normal
> executor could work instead?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
