[Red Hat JIRA] (WFLY-14258) The first websocket that gets triggered from any deployed war file on server prevents all websockets in all other deployed war files from working
by Ronald Feicht (Jira)
[ https://issues.redhat.com/browse/WFLY-14258?page=com.atlassian.jira.plugi... ]
Ronald Feicht commented on WFLY-14258:
--------------------------------------
Yes and it is even worse with 21.0.2.Final, because a server restart does not "reset" the issue. Instead one needs to undeploy the war files to "reset" their behavior.
> The first websocket that gets triggered from any deployed war file on server prevents all websockets in all other deployed war files from working
> -------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-14258
> URL: https://issues.redhat.com/browse/WFLY-14258
> Project: WildFly
> Issue Type: Bug
> Components: JSF, Web Sockets
> Reporter: Ronald Feicht
> Assignee: Farah Juma
> Priority: Major
> Attachments: ws1.tar.gz, ws2.tar.gz
>
>
> *Two* war files are deployed on the same Wildfly instance and both use websockets. The *first* page with f:websocket that gets loaded by the browser works perfectly well. Any websocket on any other page of the *same* war file also works perfectly well. Yet, any websocket of the *second* war file will not work until the server is restartet. Then the first page with a websocket that gets loaded determines which war file's websockets will work.
> Example:
> # WS1/index.xhtml --> websocket works
> # WS2/index.xhtml --> websocket does not work (because it seems to be closed on the server side?)
> # restart Wildfly
> # WS2/index.xhtml --> websocket works
> # WS1/index.xhtml --> websocket does not work (because it seems to be closed on the server side?)
> # if we had a WS3/index.xhtml its websockets would also not work
> issue found on: Mojarra 2.3.9.SP11 on WildFly Full 20.0.1.Final (WildFly Core 12.0.3.Final)
> Example war files attached for you to easily confirm this issue:
> ws1.tar.gz
> ws2.tar.gz
>
> Created the same bug report here because I cannot tell whether the bug is in Mojarra or the Wildfly integration of Mojarra: [https://github.com/eclipse-ee4j/mojarra/issues/4799]
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months
[Red Hat JIRA] (DROOLS-5926) Executable Model compiler interprets numeric strings with leading 0 as Octal values
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5926?page=com.atlassian.jira.plug... ]
Mario Fusco updated DROOLS-5926:
--------------------------------
Sprint: 2020 Week 52-03 (from Dec 21)
> Executable Model compiler interprets numeric strings with leading 0 as Octal values
> -----------------------------------------------------------------------------------
>
> Key: DROOLS-5926
> URL: https://issues.redhat.com/browse/DROOLS-5926
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.47.0.Final
> Reporter: Matteo Casalino
> Assignee: Mario Fusco
> Priority: Major
> Attachments: integer-string-interpreted-as-octal-value-with-exec-model.zip
>
>
> The Executable Model compiler interprets numeric strings with leading 0 as Octal values. This behaviour breaks compatibility with the MVEL compiler, which interprets them as decimal.
> For example the following rule will fail to compile with Executable Model, because 800 is not a valid octal value:
> {noformat}
> rule "Test"
> when
> Fact(x == "0800")
> then
> end
> {noformat}
> The following error is given at compilation time:
> {noformat}
> Error Messages:
> Message [id=1, level=ERROR, path=src/main/java/org/build/example/rules/Rules3F1F75C706B36DFEDB0E8DD2A7622BF6RuleMethods0.java, line=23, column=123
> text=integer number too large]
> {noformat}
> The compilation works fine with the MVEL compiler.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months
[Red Hat JIRA] (WFLY-11365) Test JSONBTestCase fails with security manager
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-11365?page=com.atlassian.jira.plugi... ]
Brian Stansberry resolved WFLY-11365.
-------------------------------------
Resolution: Out of Date
If anyone knows a Fix Version please feel free to re-resolve as 'Done' for that fix version.
> Test JSONBTestCase fails with security manager
> ----------------------------------------------
>
> Key: WFLY-11365
> URL: https://issues.redhat.com/browse/WFLY-11365
> Project: WildFly
> Issue Type: Bug
> Components: EE, Test Suite
> Affects Versions: 15.0.0.Beta1
> Reporter: Martin Choma
> Assignee: Bartosz Baranowski
> Priority: Major
> Labels: security-manager
> Attachments: sm-fix.patch
>
>
> {noformat}
> org.jboss.as.test.integration.json (1)
> JSONBTestCase.testJsonbServlet
> {noformat}
> {noformat}
> java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/store/repository/org/eclipse/yasson/1.0.2/yasson-1.0.2.jar" "read")" in code source "(vfs:/content/jsonb10-test.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.jsonb10-test.war" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:294)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:191)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:359)
> at java.util.zip.ZipFile.<init>(ZipFile.java:216)
> at java.util.zip.ZipFile.<init>(ZipFile.java:155)
> 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:99)
> at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
> at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:152)
> at java.net.URL.openStream(URL.java:1045)
> at java.util.ServiceLoader.parse(ServiceLoader.java:304)
> at java.util.ServiceLoader.access$200(ServiceLoader.java:185)
> at java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:357)
> at java.util.ServiceLoader$LazyIterator.access$600(ServiceLoader.java:323)
> at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:396)
> at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:395)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:398)
> at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474)
> at javax.json.bind.spi.JsonbProvider.provider(JsonbProvider.java:112)
> at javax.json.bind.JsonbBuilder.create(JsonbBuilder.java:108)
> at org.jboss.as.test.integration.json.JSONBServlet.doGet(JSONBServlet.java:46) ...
> {noformat}
> Looks to me similar to WFLY-11337
> [1] https://ci.wildfly.org/viewLog.html?buildId=128138&buildTypeId=WF_MasterS...
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months
[Red Hat JIRA] (WFLY-14243) New JAXB tests in WFLY-13968 fails on ee9 profile
by Richard Opalka (Jira)
[ https://issues.redhat.com/browse/WFLY-14243?page=com.atlassian.jira.plugi... ]
Richard Opalka commented on WFLY-14243:
---------------------------------------
Thanks [~brian.stansberry]
> New JAXB tests in WFLY-13968 fails on ee9 profile
> -------------------------------------------------
>
> Key: WFLY-14243
> URL: https://issues.redhat.com/browse/WFLY-14243
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Ricardo Martin Camarero
> Assignee: Ricardo Martin Camarero
> Priority: Minor
> Fix For: 22.0.0.Final
>
>
> The new JAXB tests introduced in WFLY-13968 fails when using the ee9 profile:
> * org.jboss.as.test.integration.jaxb.unit.JAXBContextSystemPropCustomTestCase
> * org.jboss.as.test.integration.jaxb.unit.JAXBContextUsingPropertiesTestCase
> The reason is that in ee9 the system property and the keys inside the {{jaxb.properties}} file needs to be prefixed by {{jakarta}} instead of {{javax}}.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months
[Red Hat JIRA] (WFLY-14260) ClassCastException during expiration scheduling
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-14260?page=com.atlassian.jira.plugi... ]
Paul Ferraro updated WFLY-14260:
--------------------------------
Description:
This appears to be a regression due to:
https://github.com/wildfly/wildfly/commit/ff22a98553a4168a9cd47a8fbf59afa...
As seen on CI:
{noformat}
[0m09:30:39,897 INFO [org.wildfly.clustering.ee.infinispan] (default task-2) WFLYCLEEINF0002: Failed to schedule 3wnQESQq-yAwHD6_ygq39emcPLeSonW6P-oDO-0N on primary owner.: java.lang.ClassCastException: org.infinispan.remoting.transport.jgroups.JGroupsAddress cannot be cast to org.jgroups.Address
at org.wildfly.clustering.server.dispatcher.ChannelCommandDispatcherFactory.createNode(ChannelCommandDispatcherFactory.java:98)
at org.wildfly.clustering.ee.infinispan.PrimaryOwnerLocator.apply(PrimaryOwnerLocator.java:57)
at org.wildfly.clustering.ee.infinispan.PrimaryOwnerLocator.apply(PrimaryOwnerLocator.java:39)
at org.wildfly.clustering.ee.infinispan.scheduler.PrimaryOwnerScheduler$1.get(PrimaryOwnerScheduler.java:81)
at org.wildfly.clustering.ee.infinispan.scheduler.PrimaryOwnerScheduler$1.get(PrimaryOwnerScheduler.java:78)
at org.wildfly.clustering.ee.cache.retry.RetryingInvoker.invoke(RetryingInvoker.java:72)
at org.wildfly.clustering.ee.infinispan.scheduler.PrimaryOwnerScheduler.executeOnPrimaryOwner(PrimaryOwnerScheduler.java:86)
at org.wildfly.clustering.ee.infinispan.scheduler.PrimaryOwnerScheduler.schedule(PrimaryOwnerScheduler.java:59)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.accept(InfinispanSessionManager.java:123)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.accept(InfinispanSessionManager.java:119)
at org.wildfly.clustering.web.cache.session.ValidSession.close(ValidSession.java:89)
at org.wildfly.clustering.web.cache.session.ConcurrentSessionManager$ConcurrentSession.closeSession(ConcurrentSessionManager.java:151)
at org.wildfly.clustering.web.cache.session.ConcurrentSessionManager$1.accept(ConcurrentSessionManager.java:55)
at org.wildfly.clustering.web.cache.session.ConcurrentSessionManager$1.accept(ConcurrentSessionManager.java:52)
at org.wildfly.clustering.ee.cache.SimpleManager$1.run(SimpleManager.java:55)
at org.wildfly.clustering.web.cache.session.ConcurrentSessionManager$ConcurrentSession.close(ConcurrentSessionManager.java:182)
at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:98)
at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:960)
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:590)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:328)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:105)
at java.security.AccessController.doPrivileged(Native Method)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:102)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:387)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:841)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1280)
at java.lang.Thread.run(Thread.java:748)
{noformat}
To fix, we should rollback the changes to InfinispanSessionManagerFactoryServiceConfigurator, and leverage the new web-passivation layer where needed.
was:
This appears to be a regression due to:
https://github.com/wildfly/wildfly/commit/ff22a98553a4168a9cd47a8fbf59afa...
As seen on CI:
{noformat}
[0m09:30:39,897 INFO [org.wildfly.clustering.ee.infinispan] (default task-2) WFLYCLEEINF0002: Failed to schedule 3wnQESQq-yAwHD6_ygq39emcPLeSonW6P-oDO-0N on primary owner.: java.lang.ClassCastException: org.infinispan.remoting.transport.jgroups.JGroupsAddress cannot be cast to org.jgroups.Address
at org.wildfly.clustering.server.dispatcher.ChannelCommandDispatcherFactory.createNode(ChannelCommandDispatcherFactory.java:98)
at org.wildfly.clustering.ee.infinispan.PrimaryOwnerLocator.apply(PrimaryOwnerLocator.java:57)
at org.wildfly.clustering.ee.infinispan.PrimaryOwnerLocator.apply(PrimaryOwnerLocator.java:39)
at org.wildfly.clustering.ee.infinispan.scheduler.PrimaryOwnerScheduler$1.get(PrimaryOwnerScheduler.java:81)
at org.wildfly.clustering.ee.infinispan.scheduler.PrimaryOwnerScheduler$1.get(PrimaryOwnerScheduler.java:78)
at org.wildfly.clustering.ee.cache.retry.RetryingInvoker.invoke(RetryingInvoker.java:72)
at org.wildfly.clustering.ee.infinispan.scheduler.PrimaryOwnerScheduler.executeOnPrimaryOwner(PrimaryOwnerScheduler.java:86)
at org.wildfly.clustering.ee.infinispan.scheduler.PrimaryOwnerScheduler.schedule(PrimaryOwnerScheduler.java:59)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.accept(InfinispanSessionManager.java:123)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.accept(InfinispanSessionManager.java:119)
at org.wildfly.clustering.web.cache.session.ValidSession.close(ValidSession.java:89)
at org.wildfly.clustering.web.cache.session.ConcurrentSessionManager$ConcurrentSession.closeSession(ConcurrentSessionManager.java:151)
at org.wildfly.clustering.web.cache.session.ConcurrentSessionManager$1.accept(ConcurrentSessionManager.java:55)
at org.wildfly.clustering.web.cache.session.ConcurrentSessionManager$1.accept(ConcurrentSessionManager.java:52)
at org.wildfly.clustering.ee.cache.SimpleManager$1.run(SimpleManager.java:55)
at org.wildfly.clustering.web.cache.session.ConcurrentSessionManager$ConcurrentSession.close(ConcurrentSessionManager.java:182)
at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:98)
at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:960)
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:590)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:328)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:105)
at java.security.AccessController.doPrivileged(Native Method)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:102)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:387)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:841)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1280)
at java.lang.Thread.run(Thread.java:748)
{noformat}
> ClassCastException during expiration scheduling
> -----------------------------------------------
>
> Key: WFLY-14260
> URL: https://issues.redhat.com/browse/WFLY-14260
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 22.0.0.Beta1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Critical
>
> This appears to be a regression due to:
> https://github.com/wildfly/wildfly/commit/ff22a98553a4168a9cd47a8fbf59afa...
> As seen on CI:
> {noformat}
> [0m09:30:39,897 INFO [org.wildfly.clustering.ee.infinispan] (default task-2) WFLYCLEEINF0002: Failed to schedule 3wnQESQq-yAwHD6_ygq39emcPLeSonW6P-oDO-0N on primary owner.: java.lang.ClassCastException: org.infinispan.remoting.transport.jgroups.JGroupsAddress cannot be cast to org.jgroups.Address
> at org.wildfly.clustering.server.dispatcher.ChannelCommandDispatcherFactory.createNode(ChannelCommandDispatcherFactory.java:98)
> at org.wildfly.clustering.ee.infinispan.PrimaryOwnerLocator.apply(PrimaryOwnerLocator.java:57)
> at org.wildfly.clustering.ee.infinispan.PrimaryOwnerLocator.apply(PrimaryOwnerLocator.java:39)
> at org.wildfly.clustering.ee.infinispan.scheduler.PrimaryOwnerScheduler$1.get(PrimaryOwnerScheduler.java:81)
> at org.wildfly.clustering.ee.infinispan.scheduler.PrimaryOwnerScheduler$1.get(PrimaryOwnerScheduler.java:78)
> at org.wildfly.clustering.ee.cache.retry.RetryingInvoker.invoke(RetryingInvoker.java:72)
> at org.wildfly.clustering.ee.infinispan.scheduler.PrimaryOwnerScheduler.executeOnPrimaryOwner(PrimaryOwnerScheduler.java:86)
> at org.wildfly.clustering.ee.infinispan.scheduler.PrimaryOwnerScheduler.schedule(PrimaryOwnerScheduler.java:59)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.accept(InfinispanSessionManager.java:123)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.accept(InfinispanSessionManager.java:119)
> at org.wildfly.clustering.web.cache.session.ValidSession.close(ValidSession.java:89)
> at org.wildfly.clustering.web.cache.session.ConcurrentSessionManager$ConcurrentSession.closeSession(ConcurrentSessionManager.java:151)
> at org.wildfly.clustering.web.cache.session.ConcurrentSessionManager$1.accept(ConcurrentSessionManager.java:55)
> at org.wildfly.clustering.web.cache.session.ConcurrentSessionManager$1.accept(ConcurrentSessionManager.java:52)
> at org.wildfly.clustering.ee.cache.SimpleManager$1.run(SimpleManager.java:55)
> at org.wildfly.clustering.web.cache.session.ConcurrentSessionManager$ConcurrentSession.close(ConcurrentSessionManager.java:182)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:98)
> at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:960)
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:590)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:328)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
> at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:105)
> at java.security.AccessController.doPrivileged(Native Method)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:102)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:387)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:841)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1280)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> To fix, we should rollback the changes to InfinispanSessionManagerFactoryServiceConfigurator, and leverage the new web-passivation layer where needed.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months
[Red Hat JIRA] (WFLY-14258) The first websocket that gets triggered from any deployed war file on server prevents all websockets in all other deployed war files from working
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/WFLY-14258?page=com.atlassian.jira.plugi... ]
Farah Juma commented on WFLY-14258:
-----------------------------------
[~scsynergy] Have you checked if you still see this issue with the latest WildFly release (21.0.2.Final)?
> The first websocket that gets triggered from any deployed war file on server prevents all websockets in all other deployed war files from working
> -------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-14258
> URL: https://issues.redhat.com/browse/WFLY-14258
> Project: WildFly
> Issue Type: Bug
> Components: JSF, Web Sockets
> Reporter: Ronald Feicht
> Assignee: Farah Juma
> Priority: Major
> Attachments: ws1.tar.gz, ws2.tar.gz
>
>
> *Two* war files are deployed on the same Wildfly instance and both use websockets. The *first* page with f:websocket that gets loaded by the browser works perfectly well. Any websocket on any other page of the *same* war file also works perfectly well. Yet, any websocket of the *second* war file will not work until the server is restartet. Then the first page with a websocket that gets loaded determines which war file's websockets will work.
> Example:
> # WS1/index.xhtml --> websocket works
> # WS2/index.xhtml --> websocket does not work (because it seems to be closed on the server side?)
> # restart Wildfly
> # WS2/index.xhtml --> websocket works
> # WS1/index.xhtml --> websocket does not work (because it seems to be closed on the server side?)
> # if we had a WS3/index.xhtml its websockets would also not work
> issue found on: Mojarra 2.3.9.SP11 on WildFly Full 20.0.1.Final (WildFly Core 12.0.3.Final)
> Example war files attached for you to easily confirm this issue:
> ws1.tar.gz
> ws2.tar.gz
>
> Created the same bug report here because I cannot tell whether the bug is in Mojarra or the Wildfly integration of Mojarra: [https://github.com/eclipse-ee4j/mojarra/issues/4799]
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months