January 2021 - jboss-jira - Jboss List Archives

[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 updated WFLY-14258: --------------------------------- Component/s: (was: JSF) Description: *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: # WS*1*/index.xhtml --> websocket works # WS*2*/index.xhtml --> websocket does not work (because it seems to be closed on the server side?) # restart Wildfly # WS*2*/index.xhtml --> websocket works # WS*1*/index.xhtml --> websocket does not work (because it seems to be closed on the server side?) # if we had a WS*3*/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] was: *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: # WS*1*/index.xhtml --> websocket works # WS*2*/index.xhtml --> websocket does not work (because it seems to be closed on the server side?) # restart Wildfly # WS*2*/index.xhtml --> websocket works # WS*1*/index.xhtml --> websocket does not work (because it seems to be closed on the server side?) # if we had a WS*3*/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 > 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 > 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: > # WS*1*/index.xhtml --> websocket works > # WS*2*/index.xhtml --> websocket does not work (because it seems to be closed on the server side?) > # restart Wildfly > # WS*2*/index.xhtml --> websocket works > # WS*1*/index.xhtml --> websocket does not work (because it seems to be closed on the server side?) > # if we had a WS*3*/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

1
0
0 / 0

[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 Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFLY-14258?page=com.atlassian.jira.plugi... ] Jeff Mesnil reassigned WFLY-14258: ---------------------------------- Assignee: Farah Juma (was: Jeff Mesnil) > 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 > 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: > # WS*1*/index.xhtml --> websocket works > # WS*2*/index.xhtml --> websocket does not work (because it seems to be closed on the server side?) > # restart Wildfly > # WS*2*/index.xhtml --> websocket works > # WS*1*/index.xhtml --> websocket does not work (because it seems to be closed on the server side?) > # if we had a WS*3*/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

1
0
0 / 0

[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 Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFLY-14258?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFLY-14258: ------------------------------- Component/s: JSF > 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 > Reporter: Ronald Feicht > Assignee: Jeff Mesnil > 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: > # WS*1*/index.xhtml --> websocket works > # WS*2*/index.xhtml --> websocket does not work (because it seems to be closed on the server side?) > # restart Wildfly > # WS*2*/index.xhtml --> websocket works > # WS*1*/index.xhtml --> websocket does not work (because it seems to be closed on the server side?) > # if we had a WS*3*/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

1
0
0 / 0

[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 Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFLY-14258?page=com.atlassian.jira.plugi... ] Jeff Mesnil moved WFCORE-5234 to WFLY-14258: -------------------------------------------- Key: WFLY-14258 (was: WFCORE-5234) Project: WildFly (was: WildFly Core) > 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 > Reporter: Ronald Feicht > Assignee: Jeff Mesnil > 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: > # WS*1*/index.xhtml --> websocket works > # WS*2*/index.xhtml --> websocket does not work (because it seems to be closed on the server side?) > # restart Wildfly > # WS*2*/index.xhtml --> websocket works > # WS*1*/index.xhtml --> websocket does not work (because it seems to be closed on the server side?) > # if we had a WS*3*/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

1
0
0 / 0

[Red Hat JIRA] (WFCORE-5234) 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/WFCORE-5234?page=com.atlassian.jira.plug... ] Ronald Feicht updated WFCORE-5234: ---------------------------------- Description: *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: # WS*1*/index.xhtml --> websocket works # WS*2*/index.xhtml --> websocket does not work (because it seems to be closed on the server side?) # restart Wildfly # WS*2*/index.xhtml --> websocket works # WS*1*/index.xhtml --> websocket does not work (because it seems to be closed on the server side?) # if we had a WS*3*/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 was: *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: # WS*1*/index.xhtml --> websocket works # WS*2*/index.xhtml --> websocket does not work (because it seems to be closed on the server side?) # restart Wildfly # WS*2*/index.xhtml --> websocket works # WS*1*/index.xhtml --> websocket does not work (because it seems to be closed on the server side?) # if we had a WS*3*/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 > 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: WFCORE-5234 > URL: https://issues.redhat.com/browse/WFCORE-5234 > Project: WildFly Core > Issue Type: Bug > Reporter: Ronald Feicht > Assignee: Jeff Mesnil > 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: > # WS*1*/index.xhtml --> websocket works > # WS*2*/index.xhtml --> websocket does not work (because it seems to be closed on the server side?) > # restart Wildfly > # WS*2*/index.xhtml --> websocket works > # WS*1*/index.xhtml --> websocket does not work (because it seems to be closed on the server side?) > # if we had a WS*3*/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

1
0
0 / 0

[Red Hat JIRA] (WFCORE-5234) 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/WFCORE-5234?page=com.atlassian.jira.plug... ] Ronald Feicht updated WFCORE-5234: ---------------------------------- Attachment: ws2.tar.gz > 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: WFCORE-5234 > URL: https://issues.redhat.com/browse/WFCORE-5234 > Project: WildFly Core > Issue Type: Bug > Reporter: Ronald Feicht > Assignee: Jeff Mesnil > 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: > # WS*1*/index.xhtml --> websocket works > # WS*2*/index.xhtml --> websocket does not work (because it seems to be closed on the server side?) > # restart Wildfly > # WS*2*/index.xhtml --> websocket works > # WS*1*/index.xhtml --> websocket does not work (because it seems to be closed on the server side?) > # if we had a WS*3*/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 -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years

1
0
0 / 0

[Red Hat JIRA] (WFCORE-5234) 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/WFCORE-5234?page=com.atlassian.jira.plug... ] Ronald Feicht updated WFCORE-5234: ---------------------------------- Description: *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: # WS*1*/index.xhtml --> websocket works # WS*2*/index.xhtml --> websocket does not work (because it seems to be closed on the server side?) # restart Wildfly # WS*2*/index.xhtml --> websocket works # WS*1*/index.xhtml --> websocket does not work (because it seems to be closed on the server side?) # if we had a WS*3*/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 > 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: WFCORE-5234 > URL: https://issues.redhat.com/browse/WFCORE-5234 > Project: WildFly Core > Issue Type: Bug > Reporter: Ronald Feicht > Assignee: Jeff Mesnil > 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: > # WS*1*/index.xhtml --> websocket works > # WS*2*/index.xhtml --> websocket does not work (because it seems to be closed on the server side?) > # restart Wildfly > # WS*2*/index.xhtml --> websocket works > # WS*1*/index.xhtml --> websocket does not work (because it seems to be closed on the server side?) > # if we had a WS*3*/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 -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years

1
0
0 / 0

[Red Hat JIRA] (WFCORE-5234) 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/WFCORE-5234?page=com.atlassian.jira.plug... ] Ronald Feicht updated WFCORE-5234: ---------------------------------- Attachment: ws1.tar.gz > 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: WFCORE-5234 > URL: https://issues.redhat.com/browse/WFCORE-5234 > Project: WildFly Core > Issue Type: Bug > Reporter: Ronald Feicht > Assignee: Jeff Mesnil > 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: > # WS*1*/index.xhtml --> websocket works > # WS*2*/index.xhtml --> websocket does not work (because it seems to be closed on the server side?) > # restart Wildfly > # WS*2*/index.xhtml --> websocket works > # WS*1*/index.xhtml --> websocket does not work (because it seems to be closed on the server side?) > # if we had a WS*3*/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 -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years

1
0
0 / 0

[Red Hat JIRA] (WFCORE-5234) 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)

Ronald Feicht created WFCORE-5234: ------------------------------------- Summary: 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: WFCORE-5234 URL: https://issues.redhat.com/browse/WFCORE-5234 Project: WildFly Core Issue Type: Bug Reporter: Ronald Feicht Assignee: Jeff Mesnil -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years

1
0
0 / 0

[Red Hat JIRA] (SWSQE-1248) Kiali soak test

by Filip Brychta (Jira)

[ https://issues.redhat.com/browse/SWSQE-1248?page=com.atlassian.jira.plugi... ] Filip Brychta commented on SWSQE-1248: -------------------------------------- Also updated cluster to OCP 4.6.9 > Kiali soak test > --------------- > > Key: SWSQE-1248 > URL: https://issues.redhat.com/browse/SWSQE-1248 > Project: Kiali QE > Issue Type: QE Task > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > > We need some long running instance of SM -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2021