[JBoss JIRA] (ISPN-4311) Security tests, Windows, access denied (java.security.SecurityPermission setPolicy)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4311?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4311:
-----------------------------------------------
Jiri Holusa <jholusa(a)redhat.com> changed the Status of [bug 1100259|https://bugzilla.redhat.com/show_bug.cgi?id=1100259] from ON_QA to VERIFIED
> Security tests, Windows, access denied (java.security.SecurityPermission setPolicy)
> -----------------------------------------------------------------------------------
>
> Key: ISPN-4311
> URL: https://issues.jboss.org/browse/ISPN-4311
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Security
> Affects Versions: 7.0.0.Alpha4
> Reporter: Tomas Sykora
> Assignee: Tristan Tarrant
> Labels: 63gablocker, testsuite_stability
> Fix For: 7.0.0.Alpha5
>
>
> A pile of Security tests has problems with denied access when running the test suite on Windows environment.
> Stacktrace
> java.security.AccessControlException: access denied (javax.security.auth.AuthPermission doAs)
> at java.security.AccessControlContext.checkPermission(AccessControlContext.java:374)
> at java.security.AccessController.checkPermission(AccessController.java:549)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
> at javax.security.auth.Subject.doAs(Subject.java:326)
> at org.infinispan.security.QueryAuthorizationTest.createCacheManager(QueryAuthorizationTest.java:44)
> at org.infinispan.test.SingleCacheManagerTest.setup(SingleCacheManagerTest.java:31)
> at org.infinispan.test.SingleCacheManagerTest.createBeforeClass(SingleCacheManagerTest.java:44)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:564)
> at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213)
> at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:138)
> at org.testng.internal.TestMethodWorker.invokeBeforeClassMethods(TestMethodWorker.java:175)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:107)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:662)
> *Affected tests:*
> org.infinispan.security.ExecutionAuthorizationTest.testExecMapReduce
> org.infinispan.security.QueryAuthorizationTest.createBeforeClass
> org.infinispan.security.ExecutionAuthorizationTest.testExecDistExec
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 6 months
[JBoss JIRA] (ISPN-4486) Map/Reduce DefaultCollector needs to be synchronized in certain use cases
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-4486?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic updated ISPN-4486:
--------------------------------------
Description: We have found a random test failure Dan traced to a particular use of DefaultCollector in MapReduceManagerImpl. We did not need synchronization in all other cases but in this one we did. See github PR for a proposed solution (was: We have found a random test failure Dan traced to particular use of Collector in MapReduceManagerImpl. We did not need synchronization in all other cases but in this one we did. See github PR for a proposed solution)
> Map/Reduce DefaultCollector needs to be synchronized in certain use cases
> -------------------------------------------------------------------------
>
> Key: ISPN-4486
> URL: https://issues.jboss.org/browse/ISPN-4486
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Distributed Execution and Map/Reduce
> Reporter: Vladimir Blagojevic
> Assignee: Vladimir Blagojevic
> Fix For: 7.0.0.Alpha5
>
>
> We have found a random test failure Dan traced to a particular use of DefaultCollector in MapReduceManagerImpl. We did not need synchronization in all other cases but in this one we did. See github PR for a proposed solution
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 6 months
[JBoss JIRA] (ISPN-4486) Map/Reduce DefaultCollector needs to be synchronized in certain use cases
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-4486?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic updated ISPN-4486:
--------------------------------------
Description: We have found a random test failure Dan traced to particular use of Collector in MapReduceManagerImpl. We did not need synchronization in all other cases but in this one we did. See github PR for a proposed solution
> Map/Reduce DefaultCollector needs to be synchronized in certain use cases
> -------------------------------------------------------------------------
>
> Key: ISPN-4486
> URL: https://issues.jboss.org/browse/ISPN-4486
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Distributed Execution and Map/Reduce
> Reporter: Vladimir Blagojevic
> Assignee: Vladimir Blagojevic
> Fix For: 7.0.0.Alpha5
>
>
> We have found a random test failure Dan traced to particular use of Collector in MapReduceManagerImpl. We did not need synchronization in all other cases but in this one we did. See github PR for a proposed solution
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 6 months