Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Fri, 25 Apr 2014 01:35:17 +0000 (UTC)
From: "Myrna van Lunteren (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <JIRA.12670476.1380113725344.178095.1398389717973@arcas>
In-Reply-To: <JIRA.12670476.1380113725344@arcas>
References: <JIRA.12670476.1380113725344@arcas>
Subject: [jira] [Commented] (DERBY-6352) Access denied
 ("java.lang.RuntimePermission" "modifyThread") highly intermittent, but
 e.g. in store.RecoveryAfterBackup test
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-6352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13980607#comment-13980607 ] 

Myrna van Lunteren commented on DERBY-6352:
-------------------------------------------

Thanks for the comment Dag, yes, Derby is shutting down the database.

I am fiddling with a couple of options, and trying to make sure I don't mess up...
I'm thinking of basically 2 options:
1. leave the code as it is currently (but remove the no longer needed ibm jvm specific javadump and try to minimize the comments) so catch the exception, then ignore it if we find it's a Finalizer thread
  1.b in sane mode, still throw an assert.
2. only call interrupt except if fActive is a system level thread with the word 'Finalizer' in it.

I am wondering which is best, and experimenting to see which is fastest.


> 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)