[JBoss JIRA] (WFWIP-248) Avoid Route unavailability caused by load balancer recreation on CRD change
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFWIP-248?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil resolved WFWIP-248.
-------------------------------
Resolution: Done
> Avoid Route unavailability caused by load balancer recreation on CRD change
> ---------------------------------------------------------------------------
>
> Key: WFWIP-248
> URL: https://issues.jboss.org/browse/WFWIP-248
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Petr Kremensky
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: operator
>
> Tracked by https://github.com/wildfly/wildfly-operator/issues/117
> Reproduce:
> {code:sh}
> ### REPRODUCER TERMINAL
> # deploy quickstart project
> oc new-project wildfly-test
> wildfly-operator]$ ./build/run-openshift.sh
> oc apply -f deploy/crds/quickstart-cr.yaml
> wildfly-operator]$ oc get pods
> NAME READY STATUS RESTARTS AGE
> quickstart-0 1/1 Running 0 34s
> quickstart-1 1/1 Running 0 34s
> wildfly-operator-7f555b86d5-jkctc 1/1 Running 0 99s
> # verify the app is responsive
> ROUTE=quickstart-route-wildfly-test.apps-crc.testing
> curl $ROUTE
> {"ip":"10.128.1.43"}
> # watch pods
> oc get pods -w &
> # verify route readiness
> ROUTE=quickstart-route-wildfly-test.apps-crc.testing
> # I've seen some weird bash optimization using `while true` in past which I'd like to avoid here...
> for i in {0..100000} ; do
> echo '----------------------------------------'
> date
> curl -sI $ROUTE | grep HTTP
> curl -s $ROUTE | head -n 1
> echo ''
> oc describe service/quickstart-loadbalancer | grep Endpoints
> sleep 0.5
> done
> ### ADMIN TERMINAL - scale the application
> oc patch wildflyserver quickstart -p '[{"op":"replace", "path":"/spec/replicas", "value":3}]' --type json
> {code}
> output:
> {noformat}
> ----------------------------------------
> Mon 14 Oct 2019 01:12:09 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> quickstart-2 0/1 Pending 0 0s
> quickstart-2 0/1 Pending 0 0s
> quickstart-2 0/1 Pending 0 0s
> quickstart-2 0/1 Pending 0 0s
> quickstart-2 0/1 ContainerCreating 0 0s
> quickstart-2 0/1 ContainerCreating 0 0s
> Error from server (NotFound): services "quickstart-loadbalancer" not found
> ----------------------------------------
> Mon 14 Oct 2019 01:12:09 PM CEST
> HTTP/1.0 503 Service Unavailable
> <html>
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:10 PM CEST
> HTTP/1.0 503 Service Unavailable
> <html>
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:11 PM CEST
> HTTP/1.0 503 Service Unavailable
> <html>
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:12 PM CEST
> HTTP/1.0 503 Service Unavailable
> <html>
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:13 PM CEST
> HTTP/1.0 503 Service Unavailable
> <html>
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:13 PM CEST
> HTTP/1.0 503 Service Unavailable
> <html>
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:14 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:15 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:16 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080
> quickstart-2quickstart-2 0/10/1 ContainerCreatingContainerCreating 00 8s8s
> ----------------------------------------
> Mon 14 Oct 2019 01:12:17 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080
> quickstart-2 1/1 Running 0 8s
> quickstart-2 1/1 Running 0 8s
> ----------------------------------------
> Mon 14 Oct 2019 01:12:17 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:18 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:19 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:20 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:24 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:24 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:25 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:26 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:27 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:28 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:28 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:29 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:30 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:31 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:32 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:32 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:33 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:34 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:35 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.43"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:36 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.47"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFLY-12669) Clustering: scattered cache errors
by Tommasso Borgato (Jira)
[ https://issues.jboss.org/browse/WFLY-12669?page=com.atlassian.jira.plugin... ]
Tommasso Borgato updated WFLY-12669:
------------------------------------
Description:
The issue is about scattered cache replication across cluster nodes;
WildFly is started in clustered mode using a scattered cache for replicating HTTP session data across cluster nodes; all 4 nodes in the cluster are initialized with the following `cli` script:
{noformat}
embed-server --server-config=standalone-ha.xml
/subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcp)
/subsystem=infinispan/cache-container=web/scattered-cache=testScattered:add()
/subsystem=infinispan/cache-container=web:write-attribute(name=default-cache, value=testScattered)
{noformat}
The test is run with version `wildfly-18.0.0.Final.zip`; the same tests run with version `wildfly-17.0.1.Final.zip` do not have any problem; hence this looks like a regression;
As usual, we test that the serial value stored in the scattered cache is incremented at every call: when this is not true, we say we have a *sampling error*;
Using MOD_JK as load balancer, we have a 22.46% of *sampling errors* with wildfly-18.0.0.Final.zip (0% with wildfly-17.0.1.Final.zip):
- OK [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-17.0.1.Final.zip](https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.re...
- ERROR [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-18.0.0.Final.zip](https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.re...
Using HAPROXY as load balancer, we have a 1.71% of *sampling errors* with wildfly-18.0.0.Final.zip (0% with wildfly-17.0.1.Final.zip):
- OK [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-17.0.1.Final.zip](https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.re...
- ERROR [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-18.0.0.Final.zip](https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.re...
On the server we deploy, as usual, `clusterbench` (see attachment clusterbench-ee8.ear).
was:
The issue is about scattered cache replication across cluster nodes;
WildFly is started in clustered mode using a scattered cache for replicating HTTP session data across cluster nodes; all 4 nodes in the cluster are initialized with the following `cli` script:
{noformat}
embed-server --server-config=standalone-ha.xml
/subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcp)
/subsystem=infinispan/cache-container=web/scattered-cache=testScattered:add()
/subsystem=infinispan/cache-container=web:write-attribute(name=default-cache, value=testScattered)
{noformat}
The test is run with version `wildfly-18.0.0.Final.zip`; the same tests run with version `wildfly-17.0.1.Final.zip` do not have any problem; hence this looks like a regression:
- OK [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-17.0.1.Final.zip](https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.re...
- ERROR [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-18.0.0.Final.zip](https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.re...
On the server we deploy, as usual, `clusterbench` (see attachment clusterbench-ee8.ear).
As usual, we test that the serial value stored in the scattered cache is incremented at every call: we observed 97617 inconsistencies meaning e.g. 3 was expected but 2 was received;
> Clustering: scattered cache errors
> ----------------------------------
>
> Key: WFLY-12669
> URL: https://issues.jboss.org/browse/WFLY-12669
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 18.0.0.Final
> Reporter: Tommasso Borgato
> Assignee: Paul Ferraro
> Priority: Critical
> Attachments: clusterbench-ee8.ear
>
>
> The issue is about scattered cache replication across cluster nodes;
> WildFly is started in clustered mode using a scattered cache for replicating HTTP session data across cluster nodes; all 4 nodes in the cluster are initialized with the following `cli` script:
> {noformat}
> embed-server --server-config=standalone-ha.xml
> /subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcp)
> /subsystem=infinispan/cache-container=web/scattered-cache=testScattered:add()
> /subsystem=infinispan/cache-container=web:write-attribute(name=default-cache, value=testScattered)
> {noformat}
> The test is run with version `wildfly-18.0.0.Final.zip`; the same tests run with version `wildfly-17.0.1.Final.zip` do not have any problem; hence this looks like a regression;
> As usual, we test that the serial value stored in the scattered cache is incremented at every call: when this is not true, we say we have a *sampling error*;
> Using MOD_JK as load balancer, we have a 22.46% of *sampling errors* with wildfly-18.0.0.Final.zip (0% with wildfly-17.0.1.Final.zip):
> - OK [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-17.0.1.Final.zip](https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.re...
> - ERROR [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-18.0.0.Final.zip](https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.re...
> Using HAPROXY as load balancer, we have a 1.71% of *sampling errors* with wildfly-18.0.0.Final.zip (0% with wildfly-17.0.1.Final.zip):
> - OK [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-17.0.1.Final.zip](https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.re...
> - ERROR [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-18.0.0.Final.zip](https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.re...
> On the server we deploy, as usual, `clusterbench` (see attachment clusterbench-ee8.ear).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFWIP-248) Avoid Route unavailability caused by load balancer recreation on CRD change
by Petr Kremensky (Jira)
[ https://issues.jboss.org/browse/WFWIP-248?page=com.atlassian.jira.plugin.... ]
Petr Kremensky commented on WFWIP-248:
--------------------------------------
[~jmesnil] Scale up/down scenarios no longer shows the route unavailability. I'll few more tests, but this could be resolved for now. Thanks.
> Avoid Route unavailability caused by load balancer recreation on CRD change
> ---------------------------------------------------------------------------
>
> Key: WFWIP-248
> URL: https://issues.jboss.org/browse/WFWIP-248
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Petr Kremensky
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: operator
>
> Tracked by https://github.com/wildfly/wildfly-operator/issues/117
> Reproduce:
> {code:sh}
> ### REPRODUCER TERMINAL
> # deploy quickstart project
> oc new-project wildfly-test
> wildfly-operator]$ ./build/run-openshift.sh
> oc apply -f deploy/crds/quickstart-cr.yaml
> wildfly-operator]$ oc get pods
> NAME READY STATUS RESTARTS AGE
> quickstart-0 1/1 Running 0 34s
> quickstart-1 1/1 Running 0 34s
> wildfly-operator-7f555b86d5-jkctc 1/1 Running 0 99s
> # verify the app is responsive
> ROUTE=quickstart-route-wildfly-test.apps-crc.testing
> curl $ROUTE
> {"ip":"10.128.1.43"}
> # watch pods
> oc get pods -w &
> # verify route readiness
> ROUTE=quickstart-route-wildfly-test.apps-crc.testing
> # I've seen some weird bash optimization using `while true` in past which I'd like to avoid here...
> for i in {0..100000} ; do
> echo '----------------------------------------'
> date
> curl -sI $ROUTE | grep HTTP
> curl -s $ROUTE | head -n 1
> echo ''
> oc describe service/quickstart-loadbalancer | grep Endpoints
> sleep 0.5
> done
> ### ADMIN TERMINAL - scale the application
> oc patch wildflyserver quickstart -p '[{"op":"replace", "path":"/spec/replicas", "value":3}]' --type json
> {code}
> output:
> {noformat}
> ----------------------------------------
> Mon 14 Oct 2019 01:12:09 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> quickstart-2 0/1 Pending 0 0s
> quickstart-2 0/1 Pending 0 0s
> quickstart-2 0/1 Pending 0 0s
> quickstart-2 0/1 Pending 0 0s
> quickstart-2 0/1 ContainerCreating 0 0s
> quickstart-2 0/1 ContainerCreating 0 0s
> Error from server (NotFound): services "quickstart-loadbalancer" not found
> ----------------------------------------
> Mon 14 Oct 2019 01:12:09 PM CEST
> HTTP/1.0 503 Service Unavailable
> <html>
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:10 PM CEST
> HTTP/1.0 503 Service Unavailable
> <html>
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:11 PM CEST
> HTTP/1.0 503 Service Unavailable
> <html>
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:12 PM CEST
> HTTP/1.0 503 Service Unavailable
> <html>
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:13 PM CEST
> HTTP/1.0 503 Service Unavailable
> <html>
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:13 PM CEST
> HTTP/1.0 503 Service Unavailable
> <html>
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:14 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:15 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:16 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080
> quickstart-2quickstart-2 0/10/1 ContainerCreatingContainerCreating 00 8s8s
> ----------------------------------------
> Mon 14 Oct 2019 01:12:17 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080
> quickstart-2 1/1 Running 0 8s
> quickstart-2 1/1 Running 0 8s
> ----------------------------------------
> Mon 14 Oct 2019 01:12:17 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:18 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:19 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:20 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:24 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:24 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:25 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:26 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:27 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:28 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:28 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:29 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:30 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:31 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:32 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:32 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:33 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:34 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.44"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:35 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.43"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> ----------------------------------------
> Mon 14 Oct 2019 01:12:36 PM CEST
> HTTP/1.1 200 OK
> {"ip":"10.128.1.47"}
> Endpoints: 10.128.1.43:8080,10.128.1.44:8080,10.128.1.47:8080
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFCORE-4710) Wrong BufferPoolMXBean name used in lookup
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFCORE-4710?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-4710:
----------------------------------------
Assignee: Brian Stansberry (was: Kabir Khan)
> Wrong BufferPoolMXBean name used in lookup
> ------------------------------------------
>
> Key: WFCORE-4710
> URL: https://issues.jboss.org/browse/WFCORE-4710
> Project: WildFly Core
> Issue Type: Enhancement
> Components: JMX
> Affects Versions: 10.0.0.Final
> Reporter: Andrew Dinn
> Assignee: Brian Stansberry
> Priority: Major
>
> Class BufferPoolMXBeanResource transforms the name of retrieved MXBeans to handle embedded spaces and other special characters by calling method escapeMBeanName. Later on class BufferPoolMXBeanResourceAttributeHandler uses the name to identify the corresponding bean. Unfortunately, when BufferPoolMXBeanResourceAttributeHandler checks that the bean is registered it does not reverse the transformation by calling unescapeMBeanName.
> This causes a lookup failure when the new buffer pool non-volatiel memory MXBean is encountered on JDK14. Although Wildlfy appears to continue running the error message appears to cause failures in some of the Wildfly tests, notably those that check error stream output.
> See the referenced forum thread for full details.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFCORE-4710) Wrong BufferPoolMXBean name used in lookup
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFCORE-4710?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-4710:
------------------------------------------
This call is meant to unescape the name:
final ObjectName objectName = PlatformMBeanUtil.getObjectNameWithNameKey(PlatformMBeanConstants.BUFFER_POOL_MXBEAN_DOMAIN_TYPE, bpName);
But it's not working correctly. As you say, the isRegistered check fails, and I see that BufferPoolMXBeanAttributeHandler is the only call to that method, which makes it suspect.
I think the problem is unescapeMBeanValue itself, which is quoting the value if it alters it, but the original unescaped value need not be a quoted value. The result of unescapeMBeanValue isn't used anywhere else for anything that would break because of that flaw so it sat there lurking for eight years.
The error message is poor as well, as it uses the escaped name in the message, not the expected actual name of the BufferPoolMXBean.
> Wrong BufferPoolMXBean name used in lookup
> ------------------------------------------
>
> Key: WFCORE-4710
> URL: https://issues.jboss.org/browse/WFCORE-4710
> Project: WildFly Core
> Issue Type: Enhancement
> Components: JMX
> Affects Versions: 10.0.0.Final
> Reporter: Andrew Dinn
> Assignee: Kabir Khan
> Priority: Major
>
> Class BufferPoolMXBeanResource transforms the name of retrieved MXBeans to handle embedded spaces and other special characters by calling method escapeMBeanName. Later on class BufferPoolMXBeanResourceAttributeHandler uses the name to identify the corresponding bean. Unfortunately, when BufferPoolMXBeanResourceAttributeHandler checks that the bean is registered it does not reverse the transformation by calling unescapeMBeanName.
> This causes a lookup failure when the new buffer pool non-volatiel memory MXBean is encountered on JDK14. Although Wildlfy appears to continue running the error message appears to cause failures in some of the Wildfly tests, notably those that check error stream output.
> See the referenced forum thread for full details.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFCORE-4711) Upgrade XNIO to 3.7.7.Final
by Ilia Vassilev (Jira)
[ https://issues.jboss.org/browse/WFCORE-4711?page=com.atlassian.jira.plugi... ]
Ilia Vassilev moved JBEAP-17791 to WFCORE-4711:
-----------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-4711 (was: JBEAP-17791)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Build System
(was: Build System)
Affects Version/s: (was: 7.2.4.GA)
Fix Version/s: (was: 7.2.6.GA)
> Upgrade XNIO to 3.7.7.Final
> ---------------------------
>
> Key: WFCORE-4711
> URL: https://issues.jboss.org/browse/WFCORE-4711
> Project: WildFly Core
> Issue Type: Component Upgrade
> Components: Build System
> Reporter: Ilia Vassilev
> Assignee: Ilia Vassilev
> Priority: Major
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFLY-12614) Duplicated ConstraintViolation message
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-12614?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-12614:
-----------------------------------------
[~ron_sigal]
Re:
1) do you know how to force the creation of EJB proxies?
No, but I doubt that doable outside of WildFly. The ejb3 subsystem does this.
2) [~cfang] [~tomekadamski] Any suggestions for a way RESTEasy code could detect the presence of an EJB proxy?
> Duplicated ConstraintViolation message
> --------------------------------------
>
> Key: WFLY-12614
> URL: https://issues.jboss.org/browse/WFLY-12614
> Project: WildFly
> Issue Type: Bug
> Components: Bean Validation, REST
> Affects Versions: 17.0.1.Final, 18.0.0.Beta1
> Reporter: Robin Schimpf
> Assignee: Alessio Soldano
> Priority: Major
> Attachments: wildfly-bug.zip
>
>
> We currently are upgrading our application from Wildfly 13 to Wildfly 17.0.1 and are receiving duplicated constraint violations in the response of an invalid request.
> Interestingly Wildfly 13 also seems to be not behaving correctly on the third request but in another way. There is the violation exception returned in the response instead of the duplicated value Wildfly 17 is returning now.
> I also tested this on the currently available Wildfly 18 Beta 1 and the issue is also reproducible.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFLY-12666) JPA jipijapa use optional dependencies instead of modifying the system module
by Brad Maxwell (Jira)
[ https://issues.jboss.org/browse/WFLY-12666?page=com.atlassian.jira.plugin... ]
Brad Maxwell updated WFLY-12666:
--------------------------------
Attachment: WFLY-12666-overlay.zip
> JPA jipijapa use optional dependencies instead of modifying the system module
> -----------------------------------------------------------------------------
>
> Key: WFLY-12666
> URL: https://issues.jboss.org/browse/WFLY-12666
> Project: WildFly
> Issue Type: Enhancement
> Components: JPA / Hibernate
> Affects Versions: 18.0.0.Final
> Reporter: Brad Maxwell
> Assignee: Scott Marlow
> Priority: Major
> Attachments: WFLY-12666-overlay.zip
>
>
> As per [1] it requires modifying the modules under system/layers/base, these are system modules which users really should not modify. When applying patches it will complain because the module has been modified.
> It would be better if these modules depended on an optional module which would not exist unless the user configured this. So for example a user could create modules/org/eclipse/persistence/impl/main/module.xml
> modules/system/layers/base/org/eclipse/persistence/main/module.xml
> It looks like this almost works with just adding the optional dependency, except there is an exception where it looks like the classloader may not be set correctly for some reason when the module is split into 2.
> {code}
> <module name="org.eclipse.persistence" xmlns="urn:jboss:module:1.5">
> ...
> <module name="org.eclipse.persistence.impl" optional="true" services="import"/>
> {code}
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <module xmlns="urn:jboss:module:1.5" name="org.eclipse.persistence.impl">
> <resources>
> <!-- you want this jar to be loaded from the system module as it can be packaged potentially
> <resource-root path="jipijapa-eclipselink-7.3.0.Beta-redhat-00001.jar"/>
> -->
> <resource-root path="eclipselink.jar">
> <filter>
> <exclude path="javax/**"/>
> </filter>
> </resource-root>
> </resources>
> <dependencies>
> <module name="javax.api"/>
> <module name="javax.annotation.api"/>
> <module name="javax.enterprise.api"/>
> <module name="javax.persistence.api"/>
> <module name="javax.transaction.api"/>
> <module name="javax.validation.api"/>
> <module name="javax.xml.bind.api"/>
> <module name="org.antlr"/>
> <module name="org.dom4j"/>
> <module name="org.jboss.as.jpa.spi"/>
> <module name="org.jboss.logging"/>
> <module name="org.jboss.vfs"/>
> <module name="org.eclipse.persistence"/> <!-- to see jipijapa-eclipse-link if necessary -->
> </dependencies>
> </module>
> {code}
> {code}
> Caused by: java.lang.IllegalArgumentException: Object: com.jboss.examples.jpa.model.User@4fbcb157 is not a known Entity type.
> at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerNewObjectForPersist(UnitOfWorkImpl.java:4326)
> at org.eclipse.persistence.internal.jpa.EntityManagerImpl.persist(EntityManagerImpl.java:596)
> at org.jboss.as.jpa.container.AbstractEntityManager.persist(AbstractEntityManager.java:580)
> at com.jboss.examples.jpa.TestSingleton.test(TestSingleton.java:29)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:96)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:79)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doLifecycleInterception(Jsr299BindingsInterceptor.java:126)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:112)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:112)
> {code}
> [1] https://docs.jboss.org/author/display/WFLY10/JPA+Reference+Guide#JPARefer...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFLY-12669) Clustering: scattered cache errors
by Tommasso Borgato (Jira)
[ https://issues.jboss.org/browse/WFLY-12669?page=com.atlassian.jira.plugin... ]
Tommasso Borgato updated WFLY-12669:
------------------------------------
Description:
The issue is about scattered cache replication across cluster nodes;
WildFly is started in clustered mode using a scattered cache for replicating HTTP session data across cluster nodes; all 4 nodes in the cluster are initialized with the following `cli` script:
{noformat}
embed-server --server-config=standalone-ha.xml
/subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcp)
/subsystem=infinispan/cache-container=web/scattered-cache=testScattered:add()
/subsystem=infinispan/cache-container=web:write-attribute(name=default-cache, value=testScattered)
{noformat}
The test is run with version `wildfly-18.0.0.Final.zip`; the same tests run with version `wildfly-17.0.1.Final.zip` do not have any problem; hence this looks like a regression:
- OK [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-17.0.1.Final.zip](https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.re...
- ERROR [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-18.0.0.Final.zip](https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.re...
On the server we deploy, as usual, `clusterbench` (see attachment clusterbench-ee8.ear).
As usual, we test that the serial value stored in the scattered cache is incremented at every call: we observed 97617 inconsistencies meaning e.g. 3 was expected but 2 was received;
was:
The issue is about scattered cache replication across cluster nodes;
WildFly is started in clustered mode using a scattered cache for replicating HTTP session data across cluster nodes; all 4 nodes in the cluster are initialized with the following `cli` script:
{noformat}
embed-server --server-config=standalone-ha.xml
/subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcp)
/subsystem=infinispan/cache-container=web/scattered-cache=testScattered:add()
/subsystem=infinispan/cache-container=web:write-attribute(name=default-cache, value=testScattered)
{noformat}
The test is run with version `wildfly-18.0.0.Final.zip`; the same tests run with version `wildfly-17.0.1.Final.zip` do not have any problem; hence this looks like a regression:
- OK [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-17.0.1.Final.zip](https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.re...
- ERROR [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-18.0.0.Final.zip](https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.re...
On the server we deploy, as usual, `clusterbench` (see attachment clusterbench-ee8.ear).
As usual, we test that the serial value stored in the scattered cache is incremented at every call: we observer 97617 inconsistencies meaning e.g. 3 was expected but 2 was received;
> Clustering: scattered cache errors
> ----------------------------------
>
> Key: WFLY-12669
> URL: https://issues.jboss.org/browse/WFLY-12669
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 18.0.0.Final
> Reporter: Tommasso Borgato
> Assignee: Paul Ferraro
> Priority: Critical
> Attachments: clusterbench-ee8.ear
>
>
> The issue is about scattered cache replication across cluster nodes;
> WildFly is started in clustered mode using a scattered cache for replicating HTTP session data across cluster nodes; all 4 nodes in the cluster are initialized with the following `cli` script:
> {noformat}
> embed-server --server-config=standalone-ha.xml
> /subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcp)
> /subsystem=infinispan/cache-container=web/scattered-cache=testScattered:add()
> /subsystem=infinispan/cache-container=web:write-attribute(name=default-cache, value=testScattered)
> {noformat}
> The test is run with version `wildfly-18.0.0.Final.zip`; the same tests run with version `wildfly-17.0.1.Final.zip` do not have any problem; hence this looks like a regression:
> - OK [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-17.0.1.Final.zip](https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.re...
> - ERROR [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-18.0.0.Final.zip](https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.re...
> On the server we deploy, as usual, `clusterbench` (see attachment clusterbench-ee8.ear).
> As usual, we test that the serial value stored in the scattered cache is incremented at every call: we observed 97617 inconsistencies meaning e.g. 3 was expected but 2 was received;
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months