We only ever exposed the thread killing functionality through capturing the interrupt signal on the kernel process. This was to support the stop button in Jupyter notebooks.
I can't remember if that code still exists as it was a bit flakey, relying on a Sun API to capture the signal and respond. If we remove the support in security manager, we should make sure that the signal capture code is also removed. If we add a flag to disable support, we'd want to update the signal capture code to not register since it would serve no purpose. On Sun, Oct 20, 2019, 9:50 AM Kevin Bates (Jira) <j...@apache.org> wrote: > > [ > https://issues.apache.org/jira/browse/TOREE-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16955516#comment-16955516 > ] > > Kevin Bates commented on TOREE-421: > ----------------------------------- > > bq. enable different thread groups properly > > I don't think anything has to happen to enable proper thread group > creation other than NOT preventing its creation via the SecurityManager. > > Although I'd prefer to not have to support an additional CLI option, I'm > wondering if a boolean option such as {{--prevent-new-thread-groups}} that > defaults to {{false}} would be beneficial. This would open up thread group > creation by default, but any applications that require their prevention > could then add the CLI option. I realize this could be considered a > "regression", but I suspect most won't be needing this, and applications > that require its prevention have probably already been "trained" to not > attempt thread group creation in the first place (due to its previous > prevention). > > If others feel we don't need a CLI option, we can simply remove this > portion of the SecurityManager and move on. > > Thoughts? > > > 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) >
