[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)
8 years
[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)
8 years
[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)
8 years
[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)
8 years
[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 commented on WFCORE-1503:
---------------------------------------
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)
8 years
[JBoss JIRA] (WFLY-6573) Allow Vault encrypted strings to be updated without a restart
by Brad Maxwell (JIRA)
Brad Maxwell created WFLY-6573:
----------------------------------
Summary: Allow Vault encrypted strings to be updated without a restart
Key: WFLY-6573
URL: https://issues.jboss.org/browse/WFLY-6573
Project: WildFly
Issue Type: Feature Request
Components: Security
Affects Versions: 10.0.0.Final
Reporter: Brad Maxwell
Assignee: Darran Lofthouse
When a new vault string is created the affected servers in the domain have to be restarted before the encrypted value is applied. This makes it difficult to test a new configuration in CLI.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (WFLY-6315) session.invalidate() behaviour not conform Servlet specification in HA profile
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6315?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-6315:
------------------------------------
[~sammychu] "We are using Jasig CAS as the SSO authentication provider and using their official client Jasig CAS client which by default using this mechanism."
The approach taken by Jasig CAS relies on the ability to access an HttpSession outside the scope of an HttpServletRequest.
https://github.com/Jasig/java-cas-client/blob/master/cas-client-core/src/...
This is fundamentally incompatible with a distributable servlet container, since, per the servlet specification, the container can migrate (i.e. passivate) a non-active session at any time, rendering the cache instances of HttpSession in the HashMapBackedSessionMappingStorage invalid.
"Our App working in JBoss AS 7"
The distributed session manager implementation in WF10 was rewritten since AS7. WF10 also uses Undertow as its servlet container, whereas AS7 used JBoss Web (a fork of Tomcat).
If you want to use distributed sessions, you should look into WildFly's built-in SSO support. If you want to stick with Jasig CAS, you will need to use a non-distributed web application.
> session.invalidate() behaviour not conform Servlet specification in HA profile
> ------------------------------------------------------------------------------
>
> Key: WFLY-6315
> URL: https://issues.jboss.org/browse/WFLY-6315
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Environment: Wildfly 8.2.1-Final
> JDK 1.8.0_66-b17
> Windows & Linux
> Reporter: Sammy Chu
> Assignee: Paul Ferraro
> Priority: Blocker
> Attachments: session-invalidate-noreplication.war, session-invalidate-noreplication.war, session-invalidate-replication-attribute.war, session-invalidate-replication-attribute.war, session-invalidate-replication-session.war, session-invalidate-replication-session.war
>
>
> We suspected that calling session.invalidate() on an already invalidated session with replication-granularity set to "ATTRIBUTE" will throw a NullPointerException, but from the specification it should throw an IllegalStateException instead.
> Stack trace as below:
> {noformat}
> 13:12:35,554 ERROR [io.undertow.request] (default task-32) UT005023: Exception handling request to /<our system url>: java.lang.NullPointerException
> at org.wildfly.clustering.web.infinispan.session.fine.FineSessionFactory$1.invoke(FineSessionFactory.java:103)
> at org.wildfly.clustering.web.infinispan.session.fine.FineSessionFactory$1.invoke(FineSessionFactory.java:100)
> at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34)
> at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:87)
> at org.wildfly.clustering.web.infinispan.session.fine.FineSessionFactory.remove(FineSessionFactory.java:109)
> at org.wildfly.clustering.web.infinispan.session.fine.FineSessionFactory.remove(FineSessionFactory.java:53)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSession.invalidate(InfinispanSession.java:74)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$SchedulableSession.invalidate(InfinispanSessionManager.java:359)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:140)
> at io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:199) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
> ... // our application code, just calling "session.invalidate()"
> {noformat}
> We also enclosed the simplified samples to reproduce this issue (session-invalidate-noreplication.war, session-invalidate-replication-attribute.war, session-invalidate-replication-session.war). In general they are the same except the replication-granularity (in jboss-web.xml => replication-granularity) settings.
> # session-invalidate-noreplication.war and session-invalidate-replication-session.war works correctly as they are throwing IllegalStateException.
> # session-invalidate-replication-attribute.war is buggy because it throw NullPointerException instead.
> For more information, please refer to https://developer.jboss.org/message/947295
> *Updated in 2016-04-27*
> Test again in Wildfly 8.2.1.Final, Wildfly 10.0.0.Final and Wildfly 10.1.0.Final-SNAPSHOT (master branch), with HA profile (2 nodes in same machine), with my updated WARs, detail as below:
> *Wildfly 8.2.1.Final*:
> * session-invalidate-noreplication.war - throwing IllegalStateException in the index.jsp (line 62), which is expected, detail stacktrace as below:
> {noformat}
> 15:42:56,424 INFO [stdout] (default task-9) {} session.invalidate() throw IllegalStateException, but it is intended!!!
> 15:42:56,424 ERROR [stderr] (default task-9) {} java.lang.IllegalStateException: UT000021: Session already invalidated
> 15:42:56,424 ERROR [stderr] (default task-9) {} at io.undertow.server.session.InMemorySessionManager$SessionImpl.invalidate(InMemorySessionManager.java:415)
> 15:42:56,425 ERROR [stderr] (default task-9) {} at io.undertow.server.session.InMemorySessionManager$SessionImpl.invalidate(InMemorySessionManager.java:404)
> 15:42:56,425 ERROR [stderr] (default task-9) {} at io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:199)
> 15:42:56,425 ERROR [stderr] (default task-9) {} at org.apache.jsp.index_jsp._jspService(index_jsp.java:62)
> 15:42:56,425 ERROR [stderr] (default task-9) {} at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:69)
> 15:42:56,425 ERROR [stderr] (default task-9) {} at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> 15:42:56,426 ERROR [stderr] (default task-9) {} at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:366)
> 15:42:56,426 ERROR [stderr] (default task-9) {} at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326)
> 15:42:56,426 ERROR [stderr] (default task-9) {} at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259)
> 15:42:56,426 ERROR [stderr] (default task-9) {} at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> 15:42:56,426 ERROR [stderr] (default task-9) {} at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
> 15:42:56,426 ERROR [stderr] (default task-9) {} at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
> 15:42:56,426 ERROR [stderr] (default task-9) {} at com.jboss.test.StoreSessionFilter.doFilter(StoreSessionFilter.java:72)
> 15:42:56,426 ERROR [stderr] (default task-9) {} at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> 15:42:56,427 ERROR [stderr] (default task-9) {} at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> 15:42:56,427 ERROR [stderr] (default task-9) {} at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
> 15:42:56,427 ERROR [stderr] (default task-9) {} at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> 15:42:56,427 ERROR [stderr] (default task-9) {} at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> 15:42:56,427 ERROR [stderr] (default task-9) {} at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 15:42:56,427 ERROR [stderr] (default task-9) {} at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 15:42:56,427 ERROR [stderr] (default task-9) {} at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> 15:42:56,427 ERROR [stderr] (default task-9) {} at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> 15:42:56,428 ERROR [stderr] (default task-9) {} at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 15:42:56,428 ERROR [stderr] (default task-9) {} at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 15:42:56,428 ERROR [stderr] (default task-9) {} at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 15:42:56,428 ERROR [stderr] (default task-9) {} at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> 15:42:56,428 ERROR [stderr] (default task-9) {} at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
> 15:42:56,428 ERROR [stderr] (default task-9) {} at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> 15:42:56,428 ERROR [stderr] (default task-9) {} at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 15:42:56,428 ERROR [stderr] (default task-9) {} at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 15:42:56,429 ERROR [stderr] (default task-9) {} at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 15:42:56,429 ERROR [stderr] (default task-9) {} at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 15:42:56,429 ERROR [stderr] (default task-9) {} at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261)
> 15:42:56,429 ERROR [stderr] (default task-9) {} at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:248)
> 15:42:56,429 ERROR [stderr] (default task-9) {} at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:77)
> 15:42:56,429 ERROR [stderr] (default task-9) {} at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:167)
> 15:42:56,429 ERROR [stderr] (default task-9) {} at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> 15:42:56,429 ERROR [stderr] (default task-9) {} at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:761)
> 15:42:56,430 ERROR [stderr] (default task-9) {} at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 15:42:56,430 ERROR [stderr] (default task-9) {} at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 15:42:56,430 ERROR [stderr] (default task-9) {} at java.lang.Thread.run(Thread.java:745)
> {noformat}
> * session-invalidate-replication-session.war - do *NOT* throw IllegalStateException when invalidating an already invalidated session, which is incorrect. My test just print:
> {noformat}
> 15:38:38,568 ERROR [stderr] (default task-4) {} Should not reach here!!! That means session.invalidate() do NOT throw IllegalStateException
> {noformat}
> * session-invalidate-replication-attribute.war - throwing NullPointerException in the index.jsp (line 62), which is incorrect. Detail stacktrace as below:
> {noformat}
> 15:38:57,894 ERROR [io.undertow.request] (default task-6) {} UT005023: Exception handling request to /session-invalidate-replication-attribute/index.jsp: org.apache.jasper.JasperException: JBWEB004038: An exception occurred processing JSP page /index.jsp at line 7
> 4: <%
> 5: if (request.getParameter("logout") != null) {
> 6: try {
> 7: session.invalidate(); // invalidate the invalidated session
> 8: System.err.println("Should not reach here!!! That means session.invalidate() do NOT throw IllegalStateException");
> 9: } catch (IllegalStateException e) {
> 10: // expected to throw IllegalStateException when invalidate a invalidated session
> Stacktrace:
> at org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:494) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:408) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
> at com.jboss.test.StoreSessionFilter.doFilter(StoreSessionFilter.java:72) [classes:]
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.1.8.Final.jar:1.1.8.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.8.Final.jar:1.1.8.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.8.Final.jar:1.1.8.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:248) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:77) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:167) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) [undertow-core-1.1.8.Final.jar:1.1.8.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:761) [undertow-core-1.1.8.Final.jar:1.1.8.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_92]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_92]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_92]
> Caused by: java.lang.NullPointerException
> at org.wildfly.clustering.web.infinispan.session.fine.FineSessionFactory$1.invoke(FineSessionFactory.java:103)
> at org.wildfly.clustering.web.infinispan.session.fine.FineSessionFactory$1.invoke(FineSessionFactory.java:100)
> at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34)
> at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:87)
> at org.wildfly.clustering.web.infinispan.session.fine.FineSessionFactory.remove(FineSessionFactory.java:109)
> at org.wildfly.clustering.web.infinispan.session.fine.FineSessionFactory.remove(FineSessionFactory.java:53)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSession.invalidate(InfinispanSession.java:74)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$SchedulableSession.invalidate(InfinispanSessionManager.java:359)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:140)
> at io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:199) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
> at org.apache.jsp.index_jsp._jspService(index_jsp.java:62)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:69) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:366) [jastow-1.0.0.Final.jar:1.0.0.Final]
> ... 34 more
> {noformat}
> *Wildfly-10.0.0.Final:*
> * session-invalidate-noreplication.war - same as Wildfly 8 to throw IllegalStateException which is intended.
> * session-invalidate-replication-session.war - throwing IllegalStateException in the filter!!! (Yes, in the filter, NOT in the index.jsp!!!) which is incorrect. Detail as below:
> {noformat}
> 16:00:28,742 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-5) {} ISPN000136: Error executing command GetKeyValueCommand, writing keys []: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=5}, status=3} is not in a valid state to be invoking cache operations on.
> at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:394)
> at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:350)
> at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:344)
> at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:330)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:405)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleDefault(StateTransferInterceptor.java:390)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:76)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411)
> at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:403)
> at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286)
> at org.wildfly.clustering.server.registry.CacheRegistry.getEntry(CacheRegistry.java:128)
> at org.wildfly.clustering.web.infinispan.session.InfinispanRouteLocator.locate(InfinispanRouteLocator.java:58)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionIdentifierCodec.encode(DistributableSessionIdentifierCodec.java:48)
> at org.wildfly.extension.undertow.session.CodecSessionConfig.clearSession(CodecSessionConfig.java:51)
> at io.undertow.servlet.spec.ServletContextImpl$ServletContextSessionConfig.clearSession(ServletContextImpl.java:985)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:184)
> at io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:199)
> at com.jboss.test.StoreSessionFilter.doFilter(StoreSessionFilter.java:58)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> 16:00:28,743 ERROR [com.jboss.test.StoreSessionFilter] (default task-5) {} Transaction DummyTransaction{xid=DummyXid{id=5}, status=3} is not in a valid state to be invoking cache operations on.: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=5}, status=3} is not in a valid state to be invoking cache operations on.
> at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:394)
> at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:350)
> at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:344)
> at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:330)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:405)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleDefault(StateTransferInterceptor.java:390)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:76)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411)
> at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:403)
> at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286)
> at org.wildfly.clustering.server.registry.CacheRegistry.getEntry(CacheRegistry.java:128)
> at org.wildfly.clustering.web.infinispan.session.InfinispanRouteLocator.locate(InfinispanRouteLocator.java:58)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionIdentifierCodec.encode(DistributableSessionIdentifierCodec.java:48)
> at org.wildfly.extension.undertow.session.CodecSessionConfig.clearSession(CodecSessionConfig.java:51)
> at io.undertow.servlet.spec.ServletContextImpl$ServletContextSessionConfig.clearSession(ServletContextImpl.java:985)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:184)
> at io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:199)
> at com.jboss.test.StoreSessionFilter.doFilter(StoreSessionFilter.java:58)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> 16:00:28,745 ERROR [stderr] (default task-5) {} Should not reach here!!! That means session.invalidate() do NOT throw IllegalStateException
> {noformat}
> * session-invalidate-replication-session.war - same behaviour as session-invalidate-replication-attribute.war as in Wildfly 10.0.0.Final, which throw exception in filter and do NOT throw exception in index.jsp, which is incorrect.
> *Wildfly 10.1.0.Final-SNAPSHOT*:
> those 3 cases behaviour identical as Wildfly 10.0.0.Final.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (WFLY-6572) ageout-history does not report failures
by Dennis Reed (JIRA)
Dennis Reed created WFLY-6572:
---------------------------------
Summary: ageout-history does not report failures
Key: WFLY-6572
URL: https://issues.jboss.org/browse/WFLY-6572
Project: WildFly
Issue Type: Bug
Affects Versions: 10.0.0.Final
Reporter: Dennis Reed
Assignee: Jason Greene
When ageout-history cannot delete the old CP files, it silently fails and returns "success".
LocalAgeoutHistoryHandler#recursiveDelete does keep track of whether the
delete failed or succeeded, but the return value from this method is ignored
in execute(...).
If recursiveDelete returns false, it should report a failure.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years