[JBoss JIRA] (WFWIP-251) Operator error logs on scale down
by Petr Kremensky (Jira)
[ https://issues.jboss.org/browse/WFWIP-251?page=com.atlassian.jira.plugin.... ]
Petr Kremensky commented on WFWIP-251:
--------------------------------------
The following events could be found in wildflyserver resource description after the scale down:
{code}
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning WildFlyServerScaledown 2m14s (x6 over 3m41s) wildflyserver-controller Transaction recovery slowed down the scaledown.
Warning WildFlyServerScaledown 2m14s (x5 over 2m55s) wildflyserver-controller Errors during transaction recovery scaledown processing. Consult operator log.
{code}
> Operator error logs on scale down
> ---------------------------------
>
> Key: WFWIP-251
> URL: https://issues.jboss.org/browse/WFWIP-251
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Petr Kremensky
> Assignee: Ondrej Chaloupka
> Priority: Critical
> Labels: operator
> Attachments: operator-logs.txt
>
>
> Error messages can be found in operator logs after user performs a scale down task.
> *reproduce*
> * deploy operator {noformat}./build/run-openshift.sh{noformat}
> * deploy quickstart project from operator repository {noformat}oc apply -f deploy/crds/quickstart-cr.yaml{noformat}
> * wait for both replicas to be ready {noformat}oc get pods -w
> NAME READY STATUS RESTARTS AGE
> quickstart-0 1/1 Running 0 32s
> quickstart-1 1/1 Running 0 32s
> wildfly-operator-5bcb545b46-2bjs8 1/1 Running 0 102s{noformat}
> * scale down to 1 {noformat}oc patch wildflyserver quickstart -p '[{"op":"replace", "path":"/spec/replicas", "value":1}]' --type json{noformat}
> * see the [^operator-logs.txt]
> *actual*
> Error messages in operator log
> {noformat}
> {"level":"error","ts":1571213256.675551,"logger":"wildlfyserver_resources","msg":"Failed to update resource","WildFlyServer.Namespace":"wildfly-test","WildFlyServer.Name":"quickstart","Resource.Name":"quickstart","Resource.Type":"*v1.StatefulSet","error":"Operation cannot be fulfilled on statefulsets.apps \"quickstart\": the object has been modified; please apply your changes to the latest version and try again","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/pkg/mod/github.com/go-l..."}
> {"level":"error","ts":1571213256.6756332,"logger":"wildflyserver_controller","msg":"Failed to update StatefulSet.","StatefulSet.Namespace":"wildfly-test","StatefulSet.Name":"quickstart","error":"Operation cannot be fulfilled on statefulsets.apps \"quickstart\": the object has been modified; please apply your changes to the latest version and try again","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/pkg/mod/github.com/go-l..."}
> {"level":"error","ts":1571213256.675672,"logger":"kubebuilder.controller","msg":"Reconciler error","controller":"wildflyserver-controller","request":"wildfly-test/quickstart","error":"Operation cannot be fulfilled on statefulsets.apps \"quickstart\": the object has been modified; please apply your changes to the latest version and try again","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/pkg/mod/github.com/go-l..."}
> {noformat}
> *expected*
> No error messages in operator log.
> Operator image build from [0a221ea|https://github.com/wildfly/wildfly-operator/commit/0a221eac5eb462...]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFLY-12629) MicroProfile capability names are mangled "org.wildlfy..."
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-12629?page=com.atlassian.jira.plugin... ]
Radoslav Husar updated WFLY-12629:
----------------------------------
Description:
Namely:
{code}
org.wildlfy.microprofile.config
org.wildlfy.microprofile.health.reporter
org.wildlfy.extension.microprofile.metrics.wildfly-collector
{code}
Lets fix these up before we properly support this since WF 19.
was:
Namely:
org.wildlfy.microprofile.config
org.wildlfy.microprofile.health.reporter
org.wildlfy.extension.microprofile.metrics.wildfly-collector
Lets fix these up before we properly support this since WF 19.
> MicroProfile capability names are mangled "org.wildlfy..."
> ----------------------------------------------------------
>
> Key: WFLY-12629
> URL: https://issues.jboss.org/browse/WFLY-12629
> Project: WildFly
> Issue Type: Bug
> Components: MP Config, MP Health, MP Metrics
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Major
> Fix For: 19.0.0.Beta1
>
>
> Namely:
> {code}
> org.wildlfy.microprofile.config
> org.wildlfy.microprofile.health.reporter
> org.wildlfy.extension.microprofile.metrics.wildfly-collector
> {code}
> Lets fix these up before we properly support this since WF 19.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFLY-12680) Ability to configure default global stateful timeout for Stateful Session Beans (SFSB)
by Cheng Fang (Jira)
[ https://issues.jboss.org/browse/WFLY-12680?page=com.atlassian.jira.plugin... ]
Cheng Fang moved EAP7-1361 to WFLY-12680:
-----------------------------------------
Project: WildFly (was: EAP 7 Planning Pilot)
Key: WFLY-12680 (was: EAP7-1361)
Issue Type: Feature Request (was: Requirement)
Workflow: GIT Pull Request workflow (was: EAP Agile Workflow 2.0)
Component/s: EJB
(was: EJB)
Fix Version/s: 19.0.0.Beta1
(was: 7.4.0.CD19)
EAP PT Pre-Checked (PC): (was: TODO)
Target Release: (was: 7.4.0.GA)
EAP PT Community Docs (CD): (was: TODO)
EAP PT Product Docs (PD): (was: New)
EAP PT Test Dev (TD): (was: TODO)
EAP PT Docs Analysis (DA): (was: TODO)
EAP PT Test Plan (TP): (was: TODO)
EAP PT Analysis Document (AD): (was: TODO)
> Ability to configure default global stateful timeout for Stateful Session Beans (SFSB)
> --------------------------------------------------------------------------------------
>
> Key: WFLY-12680
> URL: https://issues.jboss.org/browse/WFLY-12680
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Reporter: Cheng Fang
> Assignee: Cheng Fang
> Priority: Major
> Labels: EAP-CD19, Previous_RFE
> Fix For: 19.0.0.Beta1
>
>
> SFSB expiration can be configured by using the {{@StatefulTimeout}} annotation in the SFSB java source code or by specifying {{<stateful-timeout>}} in the {{ejb-jar.xml}} file. However, it can be only set on a per-bean basis.
> There is no default stateful timeout and we do not have a way to configure the default stateful timeout globally. So, it is troublesome for users who have many stateful session beans and want to set the same stateful-timeout value for every bean.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFLY-12669) Clustering: scattered cache sampling 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 [wildfly-18.0.0.Final.zip|https://download.jboss.org/wildfly/18.0.0.Final...];
The same tests run with version [wildfly-17.0.1.Final.zip|https://download.jboss.org/wildfly/17.0.1.Final...] 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.red...]
- 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.red...]
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.red...]
- 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.red...]
Using MOD_CLUSTER as load balancer, we have a *1.85%* 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.red...]
- 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.red...]
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 [wildfly-18.0.0.Final.zip|https://download.jboss.org/wildfly/18.0.0.Final...]; the same tests run with version [wildfly-17.0.1.Final.zip|https://download.jboss.org/wildfly/17.0.1.Final...] 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.red...]
- 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.red...]
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.red...]
- 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.red...]
Using MOD_CLUSTER as load balancer, we have a *1.85%* 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.red...]
- 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.red...]
On the server we deploy, as usual, {{clusterbench}} (see attachment clusterbench-ee8.ear).
> Clustering: scattered cache sampling 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: Blocker
> 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 [wildfly-18.0.0.Final.zip|https://download.jboss.org/wildfly/18.0.0.Final...];
> The same tests run with version [wildfly-17.0.1.Final.zip|https://download.jboss.org/wildfly/17.0.1.Final...] 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.red...]
> - 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.red...]
> 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.red...]
> - 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.red...]
> Using MOD_CLUSTER as load balancer, we have a *1.85%* 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.red...]
> - 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.red...]
> 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] (WFLY-12655) Exception with web.xml url-pattern
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFLY-12655?page=com.atlassian.jira.plugin... ]
Darran Lofthouse commented on WFLY-12655:
-----------------------------------------
[~flavia.rainone] Would you like me to take this? It looks like this is caused by the upgrade to the Jakarta EE JACC API - either we have a bug in how these paths are passed in and the old implementation was too lenient or there is a bug in the Jakarta EE implementation.
> Exception with web.xml url-pattern
> ----------------------------------
>
> Key: WFLY-12655
> URL: https://issues.jboss.org/browse/WFLY-12655
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 18.0.0.Final
> Reporter: Frank Heldt
> Assignee: Flavia Rainone
> Priority: Major
>
> Defining and securing 2 folders in a war with similar names given this Exception on deployment:
> 12:38:37,994 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.unit."java-web-project.war".jboss.security.jacc: org.jboss.msc.service.StartException in service jboss.deployment.unit."java-web-project.war".jboss.security.jacc: WFLYSEC0012: Unable to start the JaccService service
> at org.jboss.as.security@18.0.0.Final//org.jboss.as.security.service.JaccService.start(JaccService.java:107)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.IllegalArgumentException: Invalid prefix pattern in URLPatternList
> at javax.security.jacc.api@2.0.0.Final//javax.security.jacc.URLPatternSpec.setURLPatternArray(URLPatternSpec.java:308)
> at javax.security.jacc.api(a)2.0.0.Final//javax.security.jacc.URLPatternSpec.<init>(URLPatternSpec.java:79)
> at javax.security.jacc.api(a)2.0.0.Final//javax.security.jacc.WebResourcePermission.<init>(WebResourcePermission.java:160)
> at org.wildfly.extension.undertow@18.0.0.Final//org.wildfly.extension.undertow.security.jacc.WarJACCService.createPermissions(WarJACCService.java:303)
> at org.wildfly.extension.undertow@18.0.0.Final//org.wildfly.extension.undertow.security.jacc.WarJACCService.createPermissions(WarJACCService.java:64)
> at org.jboss.as.security@18.0.0.Final//org.jboss.as.security.service.JaccService.start(JaccService.java:86)
> ... 8 more
> This is the corresponding part of the web.xml:
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>Area</web-resource-name>
> <url-pattern>/area/*</url-pattern>
> </web-resource-collection>
> <auth-constraint>
> <role-name>role1</role-name>
> <role-name>role2</role-name>
> </auth-constraint>
> <user-data-constraint>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
> </security-constraint>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>Area 51</web-resource-name>
> <url-pattern>/area51/*</url-pattern>
> </web-resource-collection>
> <auth-constraint>
> <role-name>role1</role-name>
> </auth-constraint>
> <user-data-constraint>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
> </security-constraint>
> Looks like this only happens when the url-pattern starts with the same characters (eg /area/* and /area51/*).
> The same war under WildFly 17.0.1 works as expected.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months