[
https://issues.apache.org/jira/browse/DERBY-6352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13980805#comment-13980805
]
Knut Anders Hatlen commented on DERBY-6352:
-------------------------------------------
Or perhaps we should ignore all SecurityExceptions when calling interrupt() in
this method, regardless of which thread it is? I'm thinking this because:
* I'm not sure we can rely on every JVM having the same name for the finalizer
thread.
* There could be other system threads doing database work.
* The interrupt in this method looks like an optimization (active threads will
stop earlier), and not an essential part of the shutdown, so it's probably not
necessary to abort the shutdown if it is not allowed to interrupt the thread.
I'm still a little curious to know which finalize() method is causing this,
since I didn't think the finalizers in the engine were doing work that would
require a context stack.
> Access denied ("java.lang.RuntimePermission" "modifyThread") highly
> intermittent, but e.g. in store.RecoveryAfterBackup test
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-6352
> URL: https://issues.apache.org/jira/browse/DERBY-6352
> Project: Derby
> Issue Type: Bug
> Components: Test
> Affects Versions: 10.9.2.2, 10.10.1.1
> Environment: IBM java 7 Derby version 10.10.1.2 - (1494414)
> Reporter: Kathey Marsden
> Attachments: DERBY-6352_trunk.diff, DERBY-6352_trunk2.diff,
> javacore_1.zip, javacore_2.zip, test-case.diff
>
>
> I got a report of the following intermittent (6/60) exception in
> store.RecoveryAfterBackupTest.
> Exception in thread "main" java.security.AccessControlException: Access
> denied ("java.lang.RuntimePermission" "modifyThread")
> at
> java.security.AccessController.throwACE(AccessController.java:100)
> at
> java.security.AccessController.checkPermission(AccessController.java:174)
> at
> java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> at
> java.lang.SecurityManager.checkAccess(SecurityManager.java:676)
> at java.lang.Thread.checkAccess(Thread.java:459)
> at java.lang.Thread.interrupt(Thread.java:588)
> at
> org.apache.derby.iapi.services.context.ContextService$1.run(Unknown Source)
> at
> java.security.AccessController.doPrivileged(AccessController.java:274)
> at
> org.apache.derby.iapi.services.context.ContextService.notifyAllActiveThreads(Unknown
> Source)
> at
> org.apache.derby.impl.services.monitor.BaseMonitor.shutdown(Unknown Source)
> at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source)
> at org.apache.derby.jdbc.Driver20.connect(Unknown Source)
> at org.apache.derby.jdbc.AutoloadedDriver.connect(Unknown
> Source)
> at java.sql.DriverManager.getConnection(DriverManager.java:571)
> at java.sql.DriverManager.getConnection(DriverManager.java:233)
> at
> org.apache.derbyTesting.functionTests.util.TestUtil.getConnection(TestUtil.java:836)
> at
> org.apache.derbyTesting.functionTests.tests.store.RecoveryAfterBackup.main(RecoveryAfterBackup.java:82)
> modifyThread is a necessary permission if interrupting a thread other than
> the current thread but is not in our policy file for derby.jar.
> The relevant code in ContextService is:
> for (ContextManager cm : allContexts) {
> Thread active = cm.activeThread;
> if (active == me)
> continue;
> if (active == null)
> continue;
> final Thread fActive = active;
> if (cm.setInterrupted(c))
> {
> AccessController.doPrivileged(
> new PrivilegedAction<Void>() {
> public Void run() {
> fActive.interrupt();
> return null;
> }
> });
> }
>
> I am not sure why this has never come up before. Are we expecting in this
> context that fActive is the current thread?
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
