[
https://issues.redhat.com/browse/WFLY-14258?page=com.atlassian.jira.plugi...
]
Farah Juma commented on WFLY-14258:
-----------------------------------
[~scsynergy] Thanks for checking that. Can you provide more details on "websocket
does not work (because it seems to be closed on the server side?)" and where/how you
are observing this? Just tried quickly deploying the reproducers with WildFly 21.0.2.Final
and first clicked on the Push button for WS1 and then clicked on the Push button for WS2.
For both cases, I saw the "PUSHED" output in the server log, without needing to
restart the server or undeploy the apps. Is there somewhere else I should be looking to
see that the websocket does not work with your reproducer?
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)