[
https://issues.apache.org/jira/browse/TOREE-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16953155#comment-16953155
]
Kevin Bates commented on TOREE-421:
-----------------------------------
Thank you for your post Chip! I had been looking at this yesterday and had
come to the same conclusion prior to seeing your response. That said, its
tremendously helpful to have insight into the history of that logic in the
first place - thank you.
Since we know, by virtue of the SecurityManager's existing enforcement, that no
one is leveraging this "functionality", I'm inclined to unconditionally allow
the creation of new thread groups rather than only via a CLI option. IMHO, the
latter still seems inhibiting, although "safe".
Do others have a strong opinion on this - particularly in allowing different
thread groups other than the one Toree is running in? From my understanding,
any new thread groups will "inherit" the attributes (priorities, etc.) from
Toree's.
> KernelSecurityManager doesn't allow users to create their own thread groups
> ---------------------------------------------------------------------------
>
> Key: TOREE-421
> URL: https://issues.apache.org/jira/browse/TOREE-421
> Project: TOREE
> Issue Type: Bug
> Reporter: Piyush Narang
> Priority: Major
>
> I'm trying to run a Spark Scala job using Toree and I'm running into some
> issues as the code in our job calls into one of our libraries which tries to
> create threads in its own ThreadGroup:
> https://github.com/twitter/util/blob/develop/util-core/src/main/scala/com/twitter/concurrent/NamedPoolThreadFactory.scala#L28
> This seems to cause this check in Toree's KernelSecurityManager to trip:
> https://github.com/apache/incubator-toree/blob/master/kernel-api/src/main/scala/org/apache/toree/security/KernelSecurityManager.scala#L121
> Stack looks like:
> {code}
> Name: java.lang.SecurityException
> Message: Not allowed to modify ThreadGroups!
> StackTrace: at
> org.apache.toree.security.KernelSecurityManager.checkAccess(KernelSecurityManager.scala:114)
> at java.lang.ThreadGroup.checkAccess(ThreadGroup.java:315)
> at java.lang.Thread.init(Thread.java:394)
> at java.lang.Thread.init(Thread.java:349)
> at java.lang.Thread.<init>(Thread.java:599)
> at
> com.twitter.concurrent.NamedPoolThreadFactory.newThread(NamedPoolThreadFactory.scala:32)
> ...
> {code}
> Here's a simple repro:
> {code}
> println(Thread.currentThread().getThreadGroup) // default thread group
> val group: ThreadGroup = new
> ThreadGroup(Thread.currentThread().getThreadGroup(), "name")
> val hello = new Thread(group, new Runnable {
> def run() {
> println("hello world")
> }
> })
> println(hello.getThreadGroup)
> hello.start
> {code}
> Any suggestions for working around this?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
