[JBoss JIRA] (WFWIP-306) Health check response contains default readiness data
by Fabio Burzigotti (Jira)
[ https://issues.redhat.com/browse/WFWIP-306?page=com.atlassian.jira.plugin... ]
Fabio Burzigotti updated WFWIP-306:
-----------------------------------
Description:
Starting from Wildfly 19 Beta 2 and with current feature branch for MP Health upgrade to 2.2 [1], some tests started to fail, reporting unexpected content in JSON response.
When no readiness health check procedures are defined for a given deployment - the returned JSON payload contains a "default" health check readiness object, conventionally named as "ready-deployment." + <archive-name>
This change is not documented in the Analysis document: https://github.com/wildfly/wildfly-proposals/pull/284
# Arquillian deployment with a single HealthCheck implementation with _liveness_ health check procedure.
1. feature branch [1]
{code}
//health
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
},
{
"name": "ready-deployment.HealthTest.war",
"status": "UP"
}
]
}
//live
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
}
]
}
//ready
{
"status": "UP",
"checks": [
{
"name": "ready-deployment.HealthTest.war",
"status": "UP"
}
]
}
{code}
2. here are the results for the same calls against Wildfly 19 Beta 1:
{code}
//health
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
}
]
}
//live
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
}
]
}
//ready
{
"status": "UP",
"checks": []
}
{code}
[1]
https://github.com/jmesnil/wildfly
was:
Starting from Wildfly 19 Beta 2 and with current feature branch for MP Health upgrade to 2.2 [1], some tests started to fail, reporting unexpected content in JSON response.
When no readiness health check procedures are defined for a given deployment - the returned JSON payload contains a "default" health check readiness object, conventionally named as "ready-deployment." + <archive-name>
This change is not documented in the Analysis document: https://github.com/wildfly/wildfly-proposals/pull/284
# Arquillian deployment with a single HealthCheck implementation with _liveness_ health check procedure.
1. feature branch [1]
{code}
//health
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
},
{
"name": "ready-deployment.HealthTest.war",
"status": "UP"
}
]
}
//live
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
}
]
}
//ready
{
"status": "UP",
"checks": [
{
"name": "ready-deployment.HealthTest.war",
"status": "UP"
}
]
}
{code}
2. here are the results for the same calls against Wildfly 19 Beta 1:
{code}
//health
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
}
]
}
//live
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
}
]
}
//ready
{
"status": "UP",
"checks": []
}
{code}
[1]
https://github.com/jmesnil/wildfly/commits/WFLY-13048_upgrade_microprofil...
> Health check response contains default readiness data
> -----------------------------------------------------
>
> Key: WFWIP-306
> URL: https://issues.redhat.com/browse/WFWIP-306
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Health
> Reporter: Fabio Burzigotti
> Assignee: Jeff Mesnil
> Priority: Critical
>
> Starting from Wildfly 19 Beta 2 and with current feature branch for MP Health upgrade to 2.2 [1], some tests started to fail, reporting unexpected content in JSON response.
> When no readiness health check procedures are defined for a given deployment - the returned JSON payload contains a "default" health check readiness object, conventionally named as "ready-deployment." + <archive-name>
> This change is not documented in the Analysis document: https://github.com/wildfly/wildfly-proposals/pull/284
> # Arquillian deployment with a single HealthCheck implementation with _liveness_ health check procedure.
> 1. feature branch [1]
> {code}
> //health
> {
> "status": "UP",
> "checks": [
> {
> "name": "live",
> "status": "UP",
> "data": {
> "key": "value"
> }
> },
> {
> "name": "ready-deployment.HealthTest.war",
> "status": "UP"
> }
> ]
> }
> //live
> {
> "status": "UP",
> "checks": [
> {
> "name": "live",
> "status": "UP",
> "data": {
> "key": "value"
> }
> }
> ]
> }
> //ready
> {
> "status": "UP",
> "checks": [
> {
> "name": "ready-deployment.HealthTest.war",
> "status": "UP"
> }
> ]
> }
> {code}
> 2. here are the results for the same calls against Wildfly 19 Beta 1:
> {code}
> //health
> {
> "status": "UP",
> "checks": [
> {
> "name": "live",
> "status": "UP",
> "data": {
> "key": "value"
> }
> }
> ]
> }
> //live
> {
> "status": "UP",
> "checks": [
> {
> "name": "live",
> "status": "UP",
> "data": {
> "key": "value"
> }
> }
> ]
> }
> //ready
> {
> "status": "UP",
> "checks": []
> }
> {code}
> [1]
> https://github.com/jmesnil/wildfly
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFWIP-306) Health check response contains default readiness data
by Fabio Burzigotti (Jira)
[ https://issues.redhat.com/browse/WFWIP-306?page=com.atlassian.jira.plugin... ]
Fabio Burzigotti updated WFWIP-306:
-----------------------------------
Description:
Starting from Wildfly 19 Beta 2 and with current feature branch for MP Health upgrade to 2.2 [1], some tests started to fail, reporting unexpected content in JSON response.
When no readiness health check procedures are defined for a given deployment - the returned JSON payload contains a "default" health check readiness object, conventionally named as "ready-deployment." + <archive-name>
This change is not documented in the Analysis document: https://github.com/wildfly/wildfly-proposals/pull/284
# Arquillian deployment with a single HealthCheck implementation with _liveness_ health check procedure.
1. feature branch [1]
{code}
//health
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
},
{
"name": "ready-deployment.HealthTest.war",
"status": "UP"
}
]
}
//live
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
}
]
}
//ready
{
"status": "UP",
"checks": [
{
"name": "ready-deployment.HealthTest.war",
"status": "UP"
}
]
}
{code}
2. here are the results for the same calls against Wildfly 19 Beta 1:
{code}
//health
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
}
]
}
//live
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
}
]
}
//ready
{
"status": "UP",
"checks": []
}
{code}
[1]
https://github.com/jmesnil/wildfly/commits/WFLY-13048_upgrade_microprofil...
was:
Starting from Wildfly 19 Beta 2 and with current feature branch for MP Health upgrade to 2.2 [1], some tests started to fail, reporting unexpected content in JSON response.
When no readiness health check procedures are defined for a given deployment - the returned JSON payload contains a "default" health check readiness object, conventionally named as "ready-deployment." + <archive-name>
This change is not documented in the Analysis document: https://github.com/wildfly/wildfly-proposals/pull/284
# Arquillian deployment with a single HealthCheck implementation with _liveness_ health check procedure.
1. feature branch [1]
{code}
//health
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
},
{
"name": "ready-deployment.HealthTest.war",
"status": "UP"
}
]
}
//live
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
}
]
}
//ready
{
"status": "UP",
"checks": [
{
"name": "ready-deployment.HealthTest.war",
"status": "UP"
}
]
}
```
2. here's the result for the same call against Wildfly 19 Beta 1:
```
//health
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
}
]
}
//live
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
}
]
}
//ready
{
"status": "UP",
"checks": []
}
{code}
[1]
https://github.com/jmesnil/wildfly/commits/WFLY-13048_upgrade_microprofil...
> Health check response contains default readiness data
> -----------------------------------------------------
>
> Key: WFWIP-306
> URL: https://issues.redhat.com/browse/WFWIP-306
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Health
> Reporter: Fabio Burzigotti
> Assignee: Jeff Mesnil
> Priority: Critical
>
> Starting from Wildfly 19 Beta 2 and with current feature branch for MP Health upgrade to 2.2 [1], some tests started to fail, reporting unexpected content in JSON response.
> When no readiness health check procedures are defined for a given deployment - the returned JSON payload contains a "default" health check readiness object, conventionally named as "ready-deployment." + <archive-name>
> This change is not documented in the Analysis document: https://github.com/wildfly/wildfly-proposals/pull/284
> # Arquillian deployment with a single HealthCheck implementation with _liveness_ health check procedure.
> 1. feature branch [1]
> {code}
> //health
> {
> "status": "UP",
> "checks": [
> {
> "name": "live",
> "status": "UP",
> "data": {
> "key": "value"
> }
> },
> {
> "name": "ready-deployment.HealthTest.war",
> "status": "UP"
> }
> ]
> }
> //live
> {
> "status": "UP",
> "checks": [
> {
> "name": "live",
> "status": "UP",
> "data": {
> "key": "value"
> }
> }
> ]
> }
> //ready
> {
> "status": "UP",
> "checks": [
> {
> "name": "ready-deployment.HealthTest.war",
> "status": "UP"
> }
> ]
> }
> {code}
> 2. here are the results for the same calls against Wildfly 19 Beta 1:
> {code}
> //health
> {
> "status": "UP",
> "checks": [
> {
> "name": "live",
> "status": "UP",
> "data": {
> "key": "value"
> }
> }
> ]
> }
> //live
> {
> "status": "UP",
> "checks": [
> {
> "name": "live",
> "status": "UP",
> "data": {
> "key": "value"
> }
> }
> ]
> }
> //ready
> {
> "status": "UP",
> "checks": []
> }
> {code}
> [1]
> https://github.com/jmesnil/wildfly/commits/WFLY-13048_upgrade_microprofil...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFWIP-306) Health check response contains default readiness data
by Fabio Burzigotti (Jira)
[ https://issues.redhat.com/browse/WFWIP-306?page=com.atlassian.jira.plugin... ]
Fabio Burzigotti updated WFWIP-306:
-----------------------------------
Description:
Starting from Wildfly 19 Beta 2 and with current feature branch for MP Health upgrade to 2.2 [1], some tests started to fail, reporting unexpected content in JSON response.
When no readiness health check procedures are defined for a given deployment - the returned JSON payload contains a "default" health check readiness object, conventionally named as "ready-deployment." + <archive-name>
This change is not documented in the Analysis document: https://github.com/wildfly/wildfly-proposals/pull/284
# Arquillian deployment with a single HealthCheck implementation with _liveness_ health check procedure.
1. feature branch [1]
{code}
//health
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
},
{
"name": "ready-deployment.HealthTest.war",
"status": "UP"
}
]
}
//live
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
}
]
}
//ready
{
"status": "UP",
"checks": [
{
"name": "ready-deployment.HealthTest.war",
"status": "UP"
}
]
}
```
2. here's the result for the same call against Wildfly 19 Beta 1:
```
//health
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
}
]
}
//live
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
}
]
}
//ready
{
"status": "UP",
"checks": []
}
{code}
[1]
https://github.com/jmesnil/wildfly/commits/WFLY-13048_upgrade_microprofil...
was:
Starting from Wildfly 19 Beta 2 and with current feature branch for MP Health upgrade to 2.2 [1], some tests started to fail, reporting unexpected content in JSON response.
When no readiness health check procedures are defined for a given deployment - the returned JSON payload contains a "default" health check readiness object, conventionally named as "ready-deployment." + <archive-name>
This change is not documented in the Analysis document: https://github.com/wildfly/wildfly-proposals/pull/284
# Arquillian deployment with a single HealthCheck implementation with _liveness_ health check procedure.
1. feature branch [1]
```
//health
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
},
{
"name": "ready-deployment.HealthTest.war",
"status": "UP"
}
]
}
//live
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
}
]
}
//ready
{
"status": "UP",
"checks": [
{
"name": "ready-deployment.HealthTest.war",
"status": "UP"
}
]
}
```
2. here's the result for the same call against Wildfly 19 Beta 1:
```
//health
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
}
]
}
//live
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
}
]
}
//ready
{
"status": "UP",
"checks": []
}
```
[1]
https://github.com/jmesnil/wildfly/commits/WFLY-13048_upgrade_microprofil...
> Health check response contains default readiness data
> -----------------------------------------------------
>
> Key: WFWIP-306
> URL: https://issues.redhat.com/browse/WFWIP-306
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Health
> Reporter: Fabio Burzigotti
> Assignee: Jeff Mesnil
> Priority: Critical
>
> Starting from Wildfly 19 Beta 2 and with current feature branch for MP Health upgrade to 2.2 [1], some tests started to fail, reporting unexpected content in JSON response.
> When no readiness health check procedures are defined for a given deployment - the returned JSON payload contains a "default" health check readiness object, conventionally named as "ready-deployment." + <archive-name>
> This change is not documented in the Analysis document: https://github.com/wildfly/wildfly-proposals/pull/284
> # Arquillian deployment with a single HealthCheck implementation with _liveness_ health check procedure.
> 1. feature branch [1]
> {code}
> //health
> {
> "status": "UP",
> "checks": [
> {
> "name": "live",
> "status": "UP",
> "data": {
> "key": "value"
> }
> },
> {
> "name": "ready-deployment.HealthTest.war",
> "status": "UP"
> }
> ]
> }
> //live
> {
> "status": "UP",
> "checks": [
> {
> "name": "live",
> "status": "UP",
> "data": {
> "key": "value"
> }
> }
> ]
> }
> //ready
> {
> "status": "UP",
> "checks": [
> {
> "name": "ready-deployment.HealthTest.war",
> "status": "UP"
> }
> ]
> }
> ```
> 2. here's the result for the same call against Wildfly 19 Beta 1:
> ```
> //health
> {
> "status": "UP",
> "checks": [
> {
> "name": "live",
> "status": "UP",
> "data": {
> "key": "value"
> }
> }
> ]
> }
> //live
> {
> "status": "UP",
> "checks": [
> {
> "name": "live",
> "status": "UP",
> "data": {
> "key": "value"
> }
> }
> ]
> }
> //ready
> {
> "status": "UP",
> "checks": []
> }
> {code}
> [1]
> https://github.com/jmesnil/wildfly/commits/WFLY-13048_upgrade_microprofil...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFWIP-306) Health check response contains default readiness data
by Fabio Burzigotti (Jira)
[ https://issues.redhat.com/browse/WFWIP-306?page=com.atlassian.jira.plugin... ]
Fabio Burzigotti updated WFWIP-306:
-----------------------------------
Description:
Starting from Wildfly 19 Beta 2 and with current feature branch for MP Health upgrade to 2.2 [1], some tests started to fail, reporting unexpected content in JSON response.
When no readiness health check procedures are defined for a given deployment - the returned JSON payload contains a "default" health check readiness object, conventionally named as "ready-deployment." + <archive-name>
This change is not documented in the Analysis document: https://github.com/wildfly/wildfly-proposals/pull/284
# Arquillian deployment with a single HealthCheck implementation with _liveness_ health check procedure.
1. feature branch [1]
```
//health
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
},
{
"name": "ready-deployment.HealthTest.war",
"status": "UP"
}
]
}
//live
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
}
]
}
//ready
{
"status": "UP",
"checks": [
{
"name": "ready-deployment.HealthTest.war",
"status": "UP"
}
]
}
```
2. here's the result for the same call against Wildfly 19 Beta 1:
```
//health
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
}
]
}
//live
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
}
]
}
//ready
{
"status": "UP",
"checks": []
}
```
[1]
https://github.com/jmesnil/wildfly/commits/WFLY-13048_upgrade_microprofil...
was:
Starting from Beta 2 and with current feature branch for MP Health upgrade to 2.2 [1], some tests started to fail, reporting unexpected content in JSON response.
When no readiness health check procedures are defined for a given deployment - the returned JSON payload contains a "default" health check readiness object, conventionally named as "ready-deployment." + <archive-name>
This change is not documented in the Analysis document: https://github.com/wildfly/wildfly-proposals/pull/284
# Arquillian deployment with a single HealthCheck implementation with _liveness_ health check procedure.
1. feature branch [1]
```
//health
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
},
{
"name": "ready-deployment.HealthTest.war",
"status": "UP"
}
]
}
//live
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
}
]
}
//ready
{
"status": "UP",
"checks": [
{
"name": "ready-deployment.HealthTest.war",
"status": "UP"
}
]
}
```
2. here's the result for the same call against Wildfly 19 Beta 1:
```
//health
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
}
]
}
//live
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
}
]
}
//ready
{
"status": "UP",
"checks": []
}
```
[1]
https://github.com/jmesnil/wildfly/commits/WFLY-13048_upgrade_microprofil...
> Health check response contains default readiness data
> -----------------------------------------------------
>
> Key: WFWIP-306
> URL: https://issues.redhat.com/browse/WFWIP-306
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Health
> Reporter: Fabio Burzigotti
> Assignee: Jeff Mesnil
> Priority: Critical
>
> Starting from Wildfly 19 Beta 2 and with current feature branch for MP Health upgrade to 2.2 [1], some tests started to fail, reporting unexpected content in JSON response.
> When no readiness health check procedures are defined for a given deployment - the returned JSON payload contains a "default" health check readiness object, conventionally named as "ready-deployment." + <archive-name>
> This change is not documented in the Analysis document: https://github.com/wildfly/wildfly-proposals/pull/284
> # Arquillian deployment with a single HealthCheck implementation with _liveness_ health check procedure.
> 1. feature branch [1]
> ```
> //health
> {
> "status": "UP",
> "checks": [
> {
> "name": "live",
> "status": "UP",
> "data": {
> "key": "value"
> }
> },
> {
> "name": "ready-deployment.HealthTest.war",
> "status": "UP"
> }
> ]
> }
> //live
> {
> "status": "UP",
> "checks": [
> {
> "name": "live",
> "status": "UP",
> "data": {
> "key": "value"
> }
> }
> ]
> }
> //ready
> {
> "status": "UP",
> "checks": [
> {
> "name": "ready-deployment.HealthTest.war",
> "status": "UP"
> }
> ]
> }
> ```
> 2. here's the result for the same call against Wildfly 19 Beta 1:
> ```
> //health
> {
> "status": "UP",
> "checks": [
> {
> "name": "live",
> "status": "UP",
> "data": {
> "key": "value"
> }
> }
> ]
> }
> //live
> {
> "status": "UP",
> "checks": [
> {
> "name": "live",
> "status": "UP",
> "data": {
> "key": "value"
> }
> }
> ]
> }
> //ready
> {
> "status": "UP",
> "checks": []
> }
> ```
> [1]
> https://github.com/jmesnil/wildfly/commits/WFLY-13048_upgrade_microprofil...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFWIP-306) Health check response contains default readiness data
by Fabio Burzigotti (Jira)
Fabio Burzigotti created WFWIP-306:
--------------------------------------
Summary: Health check response contains default readiness data
Key: WFWIP-306
URL: https://issues.redhat.com/browse/WFWIP-306
Project: WildFly WIP
Issue Type: Bug
Components: MP Health
Reporter: Fabio Burzigotti
Assignee: Jeff Mesnil
Starting from Beta 2 and with current feature branch for MP Health upgrade to 2.2 [1], some tests started to fail, reporting unexpected content in JSON response.
When no readiness health check procedures are defined for a given deployment - the returned JSON payload contains a "default" health check readiness object, conventionally named as "ready-deployment." + <archive-name>
This change is not documented in the Analysis document: https://github.com/wildfly/wildfly-proposals/pull/284
# Arquillian deployment with a single HealthCheck implementation with _liveness_ health check procedure.
1. feature branch [1]
```
//health
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
},
{
"name": "ready-deployment.HealthTest.war",
"status": "UP"
}
]
}
//live
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
}
]
}
//ready
{
"status": "UP",
"checks": [
{
"name": "ready-deployment.HealthTest.war",
"status": "UP"
}
]
}
```
2. here's the result for the same call against Wildfly 19 Beta 1:
```
//health
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
}
]
}
//live
{
"status": "UP",
"checks": [
{
"name": "live",
"status": "UP",
"data": {
"key": "value"
}
}
]
}
//ready
{
"status": "UP",
"checks": []
}
```
[1]
https://github.com/jmesnil/wildfly/commits/WFLY-13048_upgrade_microprofil...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13136) Can't create a Pooled Connection Factory using Jgroups
by Emmanuel Hugonnet (Jira)
[ https://issues.redhat.com/browse/WFLY-13136?page=com.atlassian.jira.plugi... ]
Emmanuel Hugonnet updated WFLY-13136:
-------------------------------------
Summary: Can't create a Pooled Connection Factory using Jgroups (was: Can't create a Polled Connection Factory using Jgroups)
> Can't create a Pooled Connection Factory using Jgroups
> -------------------------------------------------------
>
> Key: WFLY-13136
> URL: https://issues.redhat.com/browse/WFLY-13136
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 19.0.0.Beta2
> Reporter: Emmanuel Hugonnet
> Assignee: Emmanuel Hugonnet
> Priority: Critical
>
> When trying to configure a pooled connection factory with a JGroup Discovery Group it fails withg the exception:
> {noformat}
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.messaging-activemq.bindings.discovery.dg-group1"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.messaging-activemq.jms.pooled-connection-factory.activemq-ra is missing [jboss.messaging-activemq.bindings.discovery.dg-group1]"]
> },
> "rolled-back" => true
> }
> {noformat}
> Reproducer:
> - start in full-ha
> {code:java}
> /subsystem=messaging-activemq/discovery-group=dg-group1:add(initial-wait-timeout=30000, jgroups-channel=ee, jgroups-cluster=artemis-cluster)
> /subsystem=messaging-activemq/pooled-connection-factory=activemq-ra:add(transaction=xa, entries=[java:/JmsXA, java:jboss/DefaultJMSConnectionFactory],discovery-group=dg-group1)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5081) DMN avoid NPE if failing FEEL parsing
by Matteo Mortari (Jira)
Matteo Mortari created DROOLS-5081:
--------------------------------------
Summary: DMN avoid NPE if failing FEEL parsing
Key: DROOLS-5081
URL: https://issues.redhat.com/browse/DROOLS-5081
Project: Drools
Issue Type: Bug
Components: dmn engine
Reporter: Matteo Mortari
Assignee: Matteo Mortari
Avoid NPE if FEEL expression fails parsing due to heuristics checks:
{code:java}
java.lang.NullPointerException
at org.kie.dmn.feel.codegen.feel11.ProcessedExpression.<init>(ProcessedExpression.java:44)
at org.kie.dmn.feel.lang.impl.FEELImpl.compile(FEELImpl.java:111)
at org.kie.dmn.core.compiler.DMNFEELHelper.compileFeelExpression(DMNFEELHelper.java:137)
at org.kie.dmn.core.compiler.DMNEvaluatorCompiler.compileDecisionTable(DMNEvaluatorCompiler.java:717)
at org.kie.dmn.core.compiler.DMNEvaluatorCompiler.compileExpression(DMNEvaluatorCompiler.java:159)
at org.kie.dmn.core.compiler.DecisionCompiler.compileEvaluator(DecisionCompiler.java:74)
at org.kie.dmn.core.compiler.DMNCompilerImpl.processDrgElements(DMNCompilerImpl.java:418)
at org.kie.dmn.core.compiler.DMNCompilerImpl.compile(DMNCompilerImpl.java:226)
at org.kie.dmn.validation.DMNValidatorImpl$ValidatorBuilderImpl.validateDefinitions(DMNValidatorImpl.java:329)
at org.kie.dmn.validation.DMNValidatorImpl$ValidatorBuilderImpl.theseModels(DMNValidatorImpl.java:297)
{code}
Also improve error message, alignment to Decision Table input clause message reporting.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (LOGMGR-263) Logger Lookup is much slower as with JDK 8
by James Perkins (Jira)
[ https://issues.redhat.com/browse/LOGMGR-263?page=com.atlassian.jira.plugi... ]
James Perkins commented on LOGMGR-263:
--------------------------------------
I've created WFCORE-4860 to do something about this in WildFly itself assuming no per-deployment logging is being used.
> Logger Lookup is much slower as with JDK 8
> ------------------------------------------
>
> Key: LOGMGR-263
> URL: https://issues.redhat.com/browse/LOGMGR-263
> Project: JBoss Log Manager
> Issue Type: Bug
> Environment: WildFly 17, OpenJDK 11
> Reporter: Andreas Liebscher
> Priority: Major
> Attachments: ClassInEar.java, LogContextCacher.java, getlogger-stack.txt, grafik1570016303722 (1).png, grafik1570016303722.png, grafik1570016791285.png, responsetimes.png
>
>
> During upgrading a Java EE application from WildFly 13 with JDK 8 to WildFly 17 with JDK 11 we had a serious performance issue. We identified the usage of the logging framework SLF4J with the pattern `Logger log = LoggerFactory.getLogger(XXX.class)` was the reason when a lot of calls to `getLogger` occur in parallel. As workaround we added `static` to some code hotspots to get back the performance we were used to. Also WildFly 13 with JDK 8 got a performance improvement with the added `static` keyword.
> Please check the VisualVM output as prove of JDKSpecific got slower:
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFCORE-4860) Performance degradation with the LogContextSelector on Java 11
by James Perkins (Jira)
James Perkins created WFCORE-4860:
-------------------------------------
Summary: Performance degradation with the LogContextSelector on Java 11
Key: WFCORE-4860
URL: https://issues.redhat.com/browse/WFCORE-4860
Project: WildFly Core
Issue Type: Bug
Components: Logging
Reporter: James Perkins
Assignee: James Perkins
As described in LOGMGR-263 there is a performance impact on Java 11 when using the {{ClassLoaderLogContextSelector}}. In WildFly for users that do not use per-deployment logging we could get around this by not using that log context selector. This would not fix the performance impact for users using Java 11 and per-deployment logging however.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (LOGMGR-263) Logger Lookup is much slower as with JDK 8
by James Perkins (Jira)
[ https://issues.redhat.com/browse/LOGMGR-263?page=com.atlassian.jira.plugi... ]
James Perkins commented on LOGMGR-263:
--------------------------------------
Thank you for the analysis [~papegaaij]. That is an interesting workaround for sure. I'll have to look at some workarounds for this or possibly a way to disable the class walker and use the old approach.
The main reason for requiring this is looking for class loaders on the call stack that have a specific log context configuration. A class loader could be registered for a deployment if there is a {{logging-profile}} being used or the deployment contains a logging configuration. One approach might be in WildFly itself to not walk the stack if no logging profiles are defined or no deployments contain logging configuration files.
> Logger Lookup is much slower as with JDK 8
> ------------------------------------------
>
> Key: LOGMGR-263
> URL: https://issues.redhat.com/browse/LOGMGR-263
> Project: JBoss Log Manager
> Issue Type: Bug
> Environment: WildFly 17, OpenJDK 11
> Reporter: Andreas Liebscher
> Priority: Major
> Attachments: ClassInEar.java, LogContextCacher.java, getlogger-stack.txt, grafik1570016303722 (1).png, grafik1570016303722.png, grafik1570016791285.png, responsetimes.png
>
>
> During upgrading a Java EE application from WildFly 13 with JDK 8 to WildFly 17 with JDK 11 we had a serious performance issue. We identified the usage of the logging framework SLF4J with the pattern `Logger log = LoggerFactory.getLogger(XXX.class)` was the reason when a lot of calls to `getLogger` occur in parallel. As workaround we added `static` to some code hotspots to get back the performance we were used to. Also WildFly 13 with JDK 8 got a performance improvement with the added `static` keyword.
> Please check the VisualVM output as prove of JDKSpecific got slower:
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months