[JBoss JIRA] (WFLY-3884) Integrate mod_cluster subsystem with Elytron security subsystem for SSL configuration
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3884?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-3884:
---------------------------------
Summary: Integrate mod_cluster subsystem with Elytron security subsystem for SSL configuration (was: Integrate mod_cluster subsystem with security subsystem for SSL configuration)
> Integrate mod_cluster subsystem with Elytron security subsystem for SSL configuration
> -------------------------------------------------------------------------------------
>
> Key: WFLY-3884
> URL: https://issues.jboss.org/browse/WFLY-3884
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 9.0.0.Alpha1
> Reporter: Paul Ferraro
> Assignee: Radoslav Husar
> Fix For: 11.0.0.CR1
>
>
> Currently, the SSL certificate configuration is embedded within the mod_cluster subsystem configuration. Ideally, mod_cluster would reference this configuration from the security subsystem.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (WFLY-6469) Some tests from "org.jboss.as.test.integration.security.xacml.*" fail with security manager
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-6469?page=com.atlassian.jira.plugin.... ]
Ivo Studensky closed WFLY-6469.
-------------------------------
Resolution: Duplicate Issue
Covered by JBEE-166.
> Some tests from "org.jboss.as.test.integration.security.xacml.*" fail with security manager
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-6469
> URL: https://issues.jboss.org/browse/WFLY-6469
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Jan Tymel
> Assignee: Ivo Studensky
>
> *org.jboss.as.test.integration.security.xacml.EjbXACMLAuthorizationModuleTestCase#testAuthenticationCache*
> *org.jboss.as.test.integration.security.xacml.EjbXACMLAuthorizationModuleTestCase#testAuthz*
> *org.jboss.as.test.integration.security.xacml.EjbXACMLAuthorizationModuleTestCase#testNotAuthn*
> *org.jboss.as.test.integration.security.xacml.EjbXACMLAuthorizationModuleTestCase#testNotAuthz*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.security.xacml.EjbXACMLAuthorizationModuleTestCase -Dsecurity.manager}}
> Fail with:
> {code}
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/jtymel/test/jboss-eap-7.0.0.ER7/dist/target/jboss-eap-7.0/modules/system/layers/base/com/sun/xml/bind/main/jaxb-runtime-2.2.11.redhat-4.jar" "read")" in code source "(vfs:/content/test-custom-xacml.jar <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:377)
> at java.util.zip.ZipFile.<init>(ZipFile.java:210)
> at java.util.zip.ZipFile.<init>(ZipFile.java:149)
> at java.util.jar.JarFile.<init>(JarFile.java:166)
> at java.util.jar.JarFile.<init>(JarFile.java:103)
> at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:93)
> at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:69)
> at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:84)
> at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
> at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:150)
> at java.net.URL.openStream(URL.java:1045)
> at javax.xml.bind.ContextFinder.find(ContextFinder.java:292)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:412)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:375)
> at org.jboss.security.xacml.core.JBossPDP.<clinit>(JBossPDP.java:126)
> ... 202 more
> {code}
> *org.jboss.as.test.integration.security.xacml.JBossPDPInteroperabilityTestCase#testInteropTestWithObjects*
> *org.jboss.as.test.integration.security.xacml.JBossPDPInteroperabilityTestCase#testInteropTestWithXMLRequests*
> *org.jboss.as.test.integration.security.xacml.JBossPDPInteroperabilityTestCase#testPoliciesLoadedFromDir*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.security.xacml.JBossPDPInteroperabilityTestCase -Dsecurity.manager}}
> Fail with:
> {code}
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/jtymel/test/jboss-eap-7.0.0.ER7/dist/target/jboss-eap-7.0/modules/system/layers/base/com/sun/xml/bind/main/jaxb-runtime-2.2.11.redhat-4.jar" "read")" in code source "(vfs:/content/pdp-service-bean.jar <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:377)
> at java.util.zip.ZipFile.<init>(ZipFile.java:210)
> at java.util.zip.ZipFile.<init>(ZipFile.java:149)
> at java.util.jar.JarFile.<init>(JarFile.java:166)
> at java.util.jar.JarFile.<init>(JarFile.java:103)
> at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:93)
> at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:69)
> at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:84)
> at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
> at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:150)
> at java.net.URL.openStream(URL.java:1045)
> at javax.xml.bind.ContextFinder.find(ContextFinder.java:292)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:412)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:375)
> at org.jboss.security.xacml.core.JBossPDP.<clinit>(JBossPDP.java:126)
> ... 152 more
> {code}
> *org.jboss.as.test.integration.security.xacml.JBossPDPServletInitializationTestCase#testPdpServlet*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.security.xacml.JBossPDPServletInitializationTestCase#testPdpServlet -Dsecurity.manager}}
> Fails with:
> {code}
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/jtymel/test/jboss-eap-7.0.0.ER7/dist/target/jboss-eap-7.0/modules/system/layers/base/com/sun/xml/bind/main/jaxb-runtime-2.2.11.redhat-4.jar" "read")" in code source "(vfs:/content/pdp-service-bean.war/WEB-INF/classes <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:377)
> at java.util.zip.ZipFile.<init>(ZipFile.java:210)
> at java.util.zip.ZipFile.<init>(ZipFile.java:149)
> at java.util.jar.JarFile.<init>(JarFile.java:166)
> at java.util.jar.JarFile.<init>(JarFile.java:103)
> at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:93)
> at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:69)
> at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:84)
> at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
> at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:150)
> at java.net.URL.openStream(URL.java:1045)
> at javax.xml.bind.ContextFinder.find(ContextFinder.java:292)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:412)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:375)
> at org.jboss.security.xacml.core.JBossPDP.<clinit>(JBossPDP.java:126)
> ... 34 more
> {code}
> *org.jboss.as.test.integration.security.xacml.WebXACMLAuthorizationModuleTestCase#testWebUsingCustomXACMLAuthz*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.security.xacml.WebXACMLAuthorizationModuleTestCase#testWebUsingCustomXACMLAuthz -Dsecurity.manager}}
> {code}
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/jtymel/test/jboss-eap-7.0.0.ER7/dist/target/jboss-eap-7.0/modules/system/layers/base/com/sun/xml/bind/main/jaxb-runtime-2.2.11.redhat-4.jar" "read")" in code source "(vfs:/content/custom-xacml-web-test.war/WEB-INF/classes <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:377)
> at java.util.zip.ZipFile.<init>(ZipFile.java:210)
> at java.util.zip.ZipFile.<init>(ZipFile.java:149)
> at java.util.jar.JarFile.<init>(JarFile.java:166)
> at java.util.jar.JarFile.<init>(JarFile.java:103)
> at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:93)
> at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:69)
> at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:84)
> at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
> at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:150)
> at java.net.URL.openStream(URL.java:1045)
> at javax.xml.bind.ContextFinder.find(ContextFinder.java:292)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:412)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:375)
> at org.jboss.security.xacml.core.JBossPDP.<clinit>(JBossPDP.java:126)
> ... 44 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (WFLY-6476) PasswordMaskingInContainerTestCase fails with security manager
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-6476?page=com.atlassian.jira.plugin.... ]
Ivo Studensky closed WFLY-6476.
-------------------------------
Resolution: Duplicate Issue
Fixed by WFLY-6468.
> PasswordMaskingInContainerTestCase fails with security manager
> --------------------------------------------------------------
>
> Key: WFLY-6476
> URL: https://issues.jboss.org/browse/WFLY-6476
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Jan Tymel
> Assignee: Ivo Studensky
>
> *org.jboss.as.test.integration.security.passwordmasking.PasswordMaskingInContainerTestCase#datasourceOperationsTest*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.security.passwordmasking.PasswordMaskingInContainerTestCase#datasourceOperationsTest -Dsecurity.manager}}
> Fails with:
> {code}
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getProtectionDomain")" in code source "(vfs:/content/passwordMasking.war/WEB-INF/classes <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.Class.getProtectionDomain(Class.java:2299)
> at org.jboss.as.test.integration.security.passwordmasking.PasswordMaskingInContainerTestCase.<clinit>(PasswordMaskingInContainerTestCase.java:178)
> ... 62 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (JBASMP-77) ConcurrentModificationException in deploy-artifact
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/JBASMP-77?page=com.atlassian.jira.plugin.... ]
Tomas Remes commented on JBASMP-77:
-----------------------------------
I am seeing this error as well. Any updates on this?
> ConcurrentModificationException in deploy-artifact
> --------------------------------------------------
>
> Key: JBASMP-77
> URL: https://issues.jboss.org/browse/JBASMP-77
> Project: JBoss AS Maven Plugins
> Issue Type: Bug
> Components: deploy
> Affects Versions: 7.7.Final
> Reporter: Daniele Gaffuri
>
> In the same situation of JBASMP-57 deploy-artifact throws the following exception:
> {code}
> [ERROR] Failed to execute goal org.jboss.as.plugins:jboss-as-maven-plugin:7.7.SCE:deploy-artifact (deploy) on project sideup-integration: Could not execute goal deploy-artifact on null. Reason: null: ConcurrentModificationException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.jboss.as.plugins:jboss-as-maven-plugin:7.7.SCE:deploy-artifact (deploy) on project sideup-integration: Could not execute goal deploy-artifact on null. Reason: null
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Could not execute goal deploy-artifact on null. Reason: null
> at org.jboss.as.plugin.deployment.AbstractDeployment.doExecute(AbstractDeployment.java:159)
> at org.jboss.as.plugin.deployment.AbstractDeployment.execute(AbstractDeployment.java:112)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: java.util.ConcurrentModificationException
> at java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:394)
> at java.util.LinkedHashMap$KeyIterator.next(LinkedHashMap.java:405)
> at java.util.AbstractCollection.addAll(AbstractCollection.java:341)
> at org.jboss.as.plugin.deployment.DeployArtifact.validate(DeployArtifact.java:84)
> at org.jboss.as.plugin.deployment.AbstractDeployment.doExecute(AbstractDeployment.java:136)
> ... 22 more
> {code}
> This is probably due to changes in related commit [37bc2c1], causing both deploy and undeploy validate methods to add the set of dependencies to itself:
> {code}
> final Set<Artifact> dependencies = project.getDependencyArtifacts();
> // Allows provided dependencies to be seen
> dependencies.addAll(project.getDependencyArtifacts());
> {code}
> {code}
> final Set<Artifact> dependencies = project.getDependencyArtifacts();
> dependencies.addAll(this.project.getDependencyArtifacts());
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (WFLY-6561) EJB Timers Intermittently Execute Repeatedly on Server Restart with Error Code WFLYEJB0043
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6561?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-6561:
--------------------------------------
Would it be possible to get some more information on this?
In particular if you could log:
- The time in ms that is being passed to start
- Timer.getNextTimeout().getTime() when the timer is created
- Timer.getNextTimeout().getTime() in the timer method itself
This may help figure out what is going on.
> EJB Timers Intermittently Execute Repeatedly on Server Restart with Error Code WFLYEJB0043
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-6561
> URL: https://issues.jboss.org/browse/WFLY-6561
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final
> Reporter: Kevin Chen
> Assignee: Stuart Douglas
>
> On Wildfly10, we are experiencing intermittent problems where on server startup, an @Timeout annotated method can be executed hundreds of times in a second (log below). Going through the references to the @Timeout methods and the @Scheduled methods, all scheduled methods are set to be non-persistent (ex: timerConfig.setPersistent(false), persistent=false) so we don't know how this could occur. It is not consistent and our only solution has been to kill the Wildfly10 server process and restart.
> 13:47:27,824 WARN [org.jboss.as.ejb3] (EJB default - 6) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 96) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 97) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 37) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (WFLY-6561) EJB Timers Intermittently Execute Repeatedly on Server Restart with Error Code WFLYEJB0043
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6561?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-6561:
------------------------------------
Component/s: EJB
(was: EE)
Assignee: Stuart Douglas
> EJB Timers Intermittently Execute Repeatedly on Server Restart with Error Code WFLYEJB0043
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-6561
> URL: https://issues.jboss.org/browse/WFLY-6561
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final
> Reporter: Kevin Chen
> Assignee: Stuart Douglas
>
> On Wildfly10, we are experiencing intermittent problems where on server startup, an @Timeout annotated method can be executed hundreds of times in a second (log below). Going through the references to the @Timeout methods and the @Scheduled methods, all scheduled methods are set to be non-persistent (ex: timerConfig.setPersistent(false), persistent=false) so we don't know how this could occur. It is not consistent and our only solution has been to kill the Wildfly10 server process and restart.
> 13:47:27,824 WARN [org.jboss.as.ejb3] (EJB default - 6) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 96) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 97) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 37) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (WFCORE-1503) Reading the logging subsystem resource can be slow if several log files exist
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1503?page=com.atlassian.jira.plugi... ]
James Perkins edited comment on WFCORE-1503 at 4/28/16 6:54 PM:
----------------------------------------------------------------
In the {{org.jboss.as.logging.LoggingResource}} the {{log-file}} child is a dynamic resource. When reading the resource it looks like {{Resource.getChildren()}} is invoked then {{Resource.getChild()}} for each child. Because the {{log-file}} resource is dynamic it walks the directory tree looking for log files. This happens for every invocation of {{Resource.getChild()}} or {{Resource.requireChild()}}. This is why the performance is slow. The more files present, including rotated files, the more the tree walking occurs.
Locally testing the performance doesn't seem terrible. However JConsole is slow to load MBeans and the web console is a bit slow when loading the logging subsystem configuration.
One option is to not walk the entire tree and just return the path on a match. Not an ideal approach as it still could be rather slow with many file handlers that have several rotated files.
Another option would be to be less dynamic and register resources when file handlers are added. This is not done elsewhere and there would be issues with adding rotated files after the add operation.
was (Author: jamezp):
In the {{org.jboss.as.logging.LoggingResource}} the {{log-file}} child is a dynamic resource. When reading the resource it looks like {{Resource.getChildren()}} is invoked then {{Resource.getChild()}} for each child. Because the {{log-file}} resource is dynamic it walks the directory tree looking for log files. This happens for every invocation of {{Resource.getChild()}} or {{Resource.requireChild()}}. This is why the performance is slow. The more files present, including rotated files, the more the tree walking occurs.
One option is to not walk the entire tree and just return the path on a match. Not an ideal approach as it still could be rather slow with many file handlers that have several rotated files.
Another option would be to be less dynamic and register resources when file handlers are added. This is not done elsewhere and there would be issues with adding rotated files after the add operation.
> Reading the logging subsystem resource can be slow if several log files exist
> -----------------------------------------------------------------------------
>
> Key: WFCORE-1503
> URL: https://issues.jboss.org/browse/WFCORE-1503
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
>
> The logging subsystem uses a dynamic resource to list log files as resources. These are the files that are allowed to be read or downloaded and are attached to known file handlers.
> When several file handlers are defined the file tree walker is invoked several times per {{read-resource-operation}}. This may be happening for each stage of an operation. Ideally we could either cache the file listing per-operation or only execute at the runtime stage. This may not be an option for dynamic resources however.
> As a result of this poor performance the web console is very slow to load the logging subsystem configuration. This is not an issue with the web console.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months