[JBoss JIRA] (WFLY-9631) "Failed to reinstate timer" warning is shown when creating large number of EJB timers
by Marian Macik (Jira)
[ https://issues.jboss.org/browse/WFLY-9631?page=com.atlassian.jira.plugin.... ]
Marian Macik commented on WFLY-9631:
------------------------------------
So just to check if I understand it. Since those timers were removed, then on the next refresh - they were considered as "new" timers from db, but they were already registered as timer resource. But since the check is done based on the content of the cache, EAP wants to register them which results in duplication?
> "Failed to reinstate timer" warning is shown when creating large number of EJB timers
> -------------------------------------------------------------------------------------
>
> Key: WFLY-9631
> URL: https://issues.jboss.org/browse/WFLY-9631
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Environment: EAP 7.0.8.GA
> Oracle 12 c
> [Configuration of datasources|https://github.com/MarianMacik/timers-testing/blob/c7dde64d27...] - XA Datasource for jBPM - our application - and a separate XA Datasource for EJB Timers in a different schema.
> Reporter: Marian Macik
> Assignee: Cheng Fang
> Priority: Major
> Attachments: WFLY-9631-reproducer.zip
>
>
> Hi, [~manovotn],
> as we discussed before, I am creating a JIRA for an issue I experienced when testing EJB Timers with jBPM.
> What I did was that I started a large number of processes with jBPM, let's say 10 000 and more. Each process contains a timer which jBPM will create an EJB Timer for. Each timer was configured to fire at exactly the same time, e.g. 12:00 PM. During the test I got this warning displayed about 5 times for each 10 000 timers created:
> {code:java}
> WARN [org.jboss.as.ejb3] (Timer-1) WFLYEJB0161: Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' (id=09afab21-6b0f-41b0-9338-403b4a12e507) from its persistent state: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource 09afab21-6b0f-41b0-9338-403b4a12e507
> at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290)
> at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169)
> at org.jboss.as.ejb3.subsystem.deployment.TimerServiceResource.timerCreated(TimerServiceResource.java:193)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.registerTimerResource(TimerServiceImpl.java:1094)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.startTimer(TimerServiceImpl.java:767)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl$TimerRefreshListener.timerAdded(TimerServiceImpl.java:1235)
> at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence$RefreshTask.run(DatabaseTimerPersistence.java:820)
> at java.util.TimerThread.mainLoop(Timer.java:555)
> at java.util.TimerThread.run(Timer.java:505)
> {code}
> The result of these warnings was that when I had only one EAP instance to fire these timers, it wouldn't fire exactly the timers with ids that were in those warnings, e.g. if it was id=09afab21-6b0f-41b0-9338-403b4a12e507 then this timer wouldn't fire. I had waited for minutes to be sure there is another tick of a refresh interval (configured to 1 min) but nothing happened. But when I started the second EAP instance, they were immediately picked up by that instance and fired. It seems that if there is this warning on a particular instance, the instance won't pick up the timer whatsoever. They will be picked up only by some other instances if there are any. With 2 EAP instances there were warnings too, but all timers fired since I guess affected timers were picked up each time by the other instance.
> Another interesting observation is that when I configured a refresh interval to be shorter, e.g. 5 seconds, these warnings were showing up almost every 5 seconds. When I set it to 30 minutes, I didn't get warnings at all, since all timers fired earlier than a refresh occurred.
> So I think it has something to do with refresh interval.
> Can you please have a look at it? For further configuration details, check the Environment field.
> Thank you very much!
> Marian Macik
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 5 months
[JBoss JIRA] (WFCORE-4551) Cannot add Elytron jdbc-realm using embedded server in admin mode
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFCORE-4551?page=com.atlassian.jira.plugi... ]
Darran Lofthouse reassigned WFCORE-4551:
----------------------------------------
Assignee: (was: Darran Lofthouse)
> Cannot add Elytron jdbc-realm using embedded server in admin mode
> -----------------------------------------------------------------
>
> Key: WFCORE-4551
> URL: https://issues.jboss.org/browse/WFCORE-4551
> Project: WildFly Core
> Issue Type: Bug
> Components: Embedded, Security
> Affects Versions: 8.0.0.Final, 9.0.1.Final
> Reporter: David Gill
> Priority: Critical
>
> On a fresh a Wildfly install (tested on 16.final and 17.final) the following jboss-cli commands will fail to add an Elytron jdbc-realm to an embedded server using the ExampleDS data source that is predefined out-of-the-box:
> {noformat}
> embed-server --server-config=standalone.xml
> /subsystem=elytron/jdbc-realm=MyRealm:add(principal-query=[{sql="SELECT * FROM Users WHERE username = ?", data-source=ExampleDS}])
> {noformat}
> Resulting in this error:
> {noformat}
> ERROR [org.jboss.as.controller.management-operation] (pool-3-thread-1) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("jdbc-realm" => "MyRealm")
> ]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.data-source.ExampleDS"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.security-realm.MyRealm is missing [org.wildfly.data-source.ExampleDS]"]
> }
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.data-source.ExampleDS"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.security-realm.MyRealm is missing [org.wildfly.data-source.ExampleDS]"]
> },
> "rolled-back" => true
> }
> {noformat}
> If you instead embed the server using {{--admin-only=false}} then the jdbc-realm will be added successfully.
> A workaround seems to be to first add and remove some other type of realm with the same name as the jdbc-realm you want to add, here for example using an identity-realm:
> {noformat}
> embed-server --server-config=standalone.xml
> # First add & remove a dummy realm with the same name as the jdbc-realm you want to add
> /subsystem=elytron/identity-realm=MyRealm:add(identity='dummy identity realm')
> /subsystem=elytron/identity-realm=MyRealm:remove
> # Now the jdbc-realm will add successfully
> /subsystem=elytron/jdbc-realm=MyRealm:add(principal-query=[{sql="SELECT * FROM Users WHERE username = ?", data-source=ExampleDS}])
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 5 months
[JBoss JIRA] (WFCORE-4551) Cannot add Elytron jdbc-realm using embedded server in admin mode
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFCORE-4551?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-4551:
-------------------------------------
Priority: Critical (was: Major)
> Cannot add Elytron jdbc-realm using embedded server in admin mode
> -----------------------------------------------------------------
>
> Key: WFCORE-4551
> URL: https://issues.jboss.org/browse/WFCORE-4551
> Project: WildFly Core
> Issue Type: Bug
> Components: Embedded, Security
> Affects Versions: 8.0.0.Final, 9.0.1.Final
> Reporter: David Gill
> Assignee: Darran Lofthouse
> Priority: Critical
>
> On a fresh a Wildfly install (tested on 16.final and 17.final) the following jboss-cli commands will fail to add an Elytron jdbc-realm to an embedded server using the ExampleDS data source that is predefined out-of-the-box:
> {noformat}
> embed-server --server-config=standalone.xml
> /subsystem=elytron/jdbc-realm=MyRealm:add(principal-query=[{sql="SELECT * FROM Users WHERE username = ?", data-source=ExampleDS}])
> {noformat}
> Resulting in this error:
> {noformat}
> ERROR [org.jboss.as.controller.management-operation] (pool-3-thread-1) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("jdbc-realm" => "MyRealm")
> ]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.data-source.ExampleDS"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.security-realm.MyRealm is missing [org.wildfly.data-source.ExampleDS]"]
> }
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.data-source.ExampleDS"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.security-realm.MyRealm is missing [org.wildfly.data-source.ExampleDS]"]
> },
> "rolled-back" => true
> }
> {noformat}
> If you instead embed the server using {{--admin-only=false}} then the jdbc-realm will be added successfully.
> A workaround seems to be to first add and remove some other type of realm with the same name as the jdbc-realm you want to add, here for example using an identity-realm:
> {noformat}
> embed-server --server-config=standalone.xml
> # First add & remove a dummy realm with the same name as the jdbc-realm you want to add
> /subsystem=elytron/identity-realm=MyRealm:add(identity='dummy identity realm')
> /subsystem=elytron/identity-realm=MyRealm:remove
> # Now the jdbc-realm will add successfully
> /subsystem=elytron/jdbc-realm=MyRealm:add(principal-query=[{sql="SELECT * FROM Users WHERE username = ?", data-source=ExampleDS}])
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 5 months
[JBoss JIRA] (DROOLS-3879) Create Kogito version of Test Scenarios designer
by Gabriele Cardosi (Jira)
[ https://issues.jboss.org/browse/DROOLS-3879?page=com.atlassian.jira.plugi... ]
Gabriele Cardosi updated DROOLS-3879:
-------------------------------------
Description:
Create the *Kogito* versions of scesim editor.
No Home Page, no Library, No preferences, no other editors.
was:
Create the *Kogito* (standalone) version of scesim editor.
No Home Page, no Library, No preferences, no other editors.
> Create Kogito version of Test Scenarios designer
> ------------------------------------------------
>
> Key: DROOLS-3879
> URL: https://issues.jboss.org/browse/DROOLS-3879
> Project: Drools
> Issue Type: Feature Request
> Components: Scenario Simulation and Testing
> Reporter: Gabriele Cardosi
> Assignee: Gabriele Cardosi
> Priority: Major
>
> Create the *Kogito* versions of scesim editor.
> No Home Page, no Library, No preferences, no other editors.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 5 months
[JBoss JIRA] (DROOLS-4162) Scenario Test: UX for background data
by Tao Zhu (Jira)
[ https://issues.jboss.org/browse/DROOLS-4162?page=com.atlassian.jira.plugi... ]
Tao Zhu commented on DROOLS-4162:
---------------------------------
[~danielezonca] I have created three demo for background data.
*Design 01* add a new tab to show the Background.
(weakness:Some user may not notice this tab sometimes)
!design1.png|thumbnail!
*Design 02* add the background on the top of the form.
(weakness:It may take up a lot of space, but we can use a folded panel or a modal)
!design2.png|thumbnail!
*Design 03* add the background in the right panel
!design3.png|thumbnail!
What do you think about these designs?
> Scenario Test: UX for background data
> -------------------------------------
>
> Key: DROOLS-4162
> URL: https://issues.jboss.org/browse/DROOLS-4162
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Tao Zhu
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
> Attachments: design1.png, design2.png, design3.png
>
>
> As user I want to be able to specify a set of data shared by all the scenarios inside a simulation. All the data will be not editable.
> Please refer to Cucumber background feature for details https://cucumber.io/docs/gherkin/reference/#background
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 5 months
[JBoss JIRA] (WFLY-11356) Test MaximumTimeoutTestCase fails with security manager
by Thomas Jenkinson (Jira)
[ https://issues.jboss.org/browse/WFLY-11356?page=com.atlassian.jira.plugin... ]
Thomas Jenkinson commented on WFLY-11356:
-----------------------------------------
[~kabirkhan] this issue looks to be resolved? So perhaps it is a different issue?
> Test MaximumTimeoutTestCase fails with security manager
> --------------------------------------------------------
>
> Key: WFLY-11356
> URL: https://issues.jboss.org/browse/WFLY-11356
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite, Transactions
> Affects Versions: 15.0.0.Beta1
> Reporter: Martin Choma
> Assignee: Michael Musgrove
> Priority: Critical
> Labels: security-manager
> Fix For: 15.0.0.Final
>
>
> {noformat}
> org.jboss.as.test.integration.transaction (3)
> MaximumTimeoutTestCase.testDefaultTimeout
> MaximumTimeoutTestCase.testLogFile
> MaximumTimeoutTestCase.testMaximumTimeout
> {noformat}
> {noformat}
> java.lang.RuntimeException: java.io.IOException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.jboss.remoting3.security.RemotingPermission" "createEndpoint")" in code source "(vfs:/content/becf34fa-0b6c-447e-b047-17d59027b753.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.becf34fa-0b6c-447e-b047-17d59027b753.jar" from Service Module Loader")
> at org.jboss.as.test.integration.transaction.MaximumTimeoutTestCase.executeForResult(MaximumTimeoutTestCase.java:124)
> at org.jboss.as.test.integration.transaction.MaximumTimeoutTestCase.setDefaultTimeout(MaximumTimeoutTestCase.java:107)
> at org.jboss.as.test.integration.transaction.MaximumTimeoutTestCase.testMaximumTimeout(MaximumTimeoutTestCase.java:137)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:379)
> at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:85)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:143)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:85)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:92)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:92)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:92)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:143)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136)
> at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:372)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:246)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:431)
> at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:55)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:260)
> at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:324)
> at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:85)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:92)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:92)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:92)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:143)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
> at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:317)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:205)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:431)
> at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:55)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:219)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:167)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66)
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180)
> at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:200)
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162)
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141)
> at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:176)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1475)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724)
> at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
> at org.jboss.as.jmx.AuthorizingMBeanServer.invoke(AuthorizingMBeanServer.java:258)
> at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:71)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:66)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:313)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:270)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:66)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.IOException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.jboss.remoting3.security.RemotingPermission" "createEndpoint")" in code source "(vfs:/content/becf34fa-0b6c-447e-b047-17d59027b753.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.becf34fa-0b6c-447e-b047-17d59027b753.jar" from Service Module Loader")
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:149)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75)
> at org.jboss.as.test.integration.transaction.MaximumTimeoutTestCase.executeForResult(MaximumTimeoutTestCase.java:120)
> ... 143 more
> Caused by: org.jboss.arquillian.test.spi.ArquillianProxyException: java.security.AccessControlException : WFSM000001: Permission check failed (permission "("org.jboss.remoting3.security.RemotingPermission" "createEndpoint")" in code source "(vfs:/content/becf34fa-0b6c-447e-b047-17d59027b753.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.becf34fa-0b6c-447e-b047-17d59027b753.jar" from Service Module Loader") [Proxied because : Original exception caused: class java.io.NotSerializableException: org.wildfly.security.util.StringEnumeration]
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:294)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:191)
> at org.jboss.remoting3.EndpointBuilder.build(EndpointBuilder.java:125)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:128)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:60)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:135)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:110)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147)
> ... 145 more
> {noformat}
> [1] https://ci.wildfly.org/viewLog.html?buildId=128138&buildTypeId=WF_MasterS...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 5 months