[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, 3 months
[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, 3 months
[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, 3 months
[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, 3 months
[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, 3 months
[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:
--------------------------------------
Elasticsearch pod was evicted because of message: 'Pod The node had condition: [DiskPressure]. '
I re-created SM with following SMCP CR (it should only keep 2 days now):
{code:java}
apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
namespace: istio-system
name: basic
spec:
tracing:
sampling: 10000
type: Jaeger
policy:
type: Istiod
runtime:
components:
tracing.jaeger.elasticsearch:
container:
resources:
limits:
cpu: '2'
memory: 4Gi
requests:
cpu: 500m
memory: 512Mi
addons:
grafana:
enabled: true
jaeger:
install:
ingress:
enabled: true
storage:
elasticsearch:
nodeCount: 2
indexCleaner:
enabled: true
numberOfDays: 2
type: Elasticsearch
kiali:
enabled: true
prometheus:
enabled: true
version: v2.0
telemetry:
type: Istiod
{code}
> 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, 3 months
[Red Hat JIRA] (DROOLS-5924) String vs Number Coercion behavior difference between standard-drl and exec-model
by Toshiya Kobayashi (Jira)
Toshiya Kobayashi created DROOLS-5924:
-----------------------------------------
Summary: String vs Number Coercion behavior difference between standard-drl and exec-model
Key: DROOLS-5924
URL: https://issues.redhat.com/browse/DROOLS-5924
Project: Drools
Issue Type: Bug
Components: core engine, executable model
Affects Versions: 7.47.0.Final
Reporter: Toshiya Kobayashi
Assignee: Toshiya Kobayashi
If there is a constraint to compare String with Number, standard-drl (MvelConstraint) coerces String to Number so the evaluation will be Number comparison (e.g. 10 > 5). But exec-model coerces Number to String so the evaluation will be String comparison (e.g. "10" < "5").
Note that we need to use a Map to test this because simple comparison String vs Number causes a compilation error.
for example)
{noformat}
$map : Map()
p : Cheese(type < $map.get("key"))
{noformat}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months