[JBoss JIRA] (WFLY-12952) MP Health returns UP when checks are expected but not installed yet.
by Ivan Straka (Jira)
[ https://issues.redhat.com/browse/WFLY-12952?page=com.atlassian.jira.plugi... ]
Ivan Straka updated WFLY-12952:
-------------------------------
Description:
MicroProfile Health specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
* A producer MUST support custom, application level health check procedures
* A producer SHOULD support reasonable out-of-the-box procedures
* A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
* A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
_Let me note that on OpenShift starting the served should mean starting the service._
Hence I expect negative overall status till the probe is ready and is able to provide response.
However WildFly with default setting responses with status UP:
{code:bash}
while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.466 {"status":"UP","checks":[]}
...
17:18:01.121 {"status":"UP","checks":[]}
17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
{code}
This violates (4) bullet in the specification.
WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
Which would mean the scenario would behave according to the specification. Yet the default state violates it.
If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
{noformat}
17:22:41.719
{"status":"DOWN","checks":[]}
{noformat}
And that would violate (3) in the specification.
TCK tests do not cover the scenario well.
Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
If there is no deployment, the _UP_ it is.
Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
* OpenShift starts the service wait some time and start asking for health status
* WildFly responses _UP_ yet application helathcheck is not installed yet
* With health status _UP_ OpenShift consider a pod ready
* In this point application is installed, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
was:
MicroProfile Health specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
* A producer MUST support custom, application level health check procedures
* A producer SHOULD support reasonable out-of-the-box procedures
* A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
* A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
_Let me note that on OpenShift starting the served should mean starting the service._
Hence I expect negative overall status till the probe is ready and is able to provide response.
However WildFly with default setting responses with status UP:
{code:bash}
while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.466 {"status":"UP","checks":[]}
...
17:18:01.121 {"status":"UP","checks":[]}
17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
{code}
This violates (4) bullet in the specification.
WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
Which would mean the scenario would behave according to the specification. Yet the default state violates it.
If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
{noformat}
17:22:41.719
{"status":"DOWN","checks":[]}
{noformat}
And that would violate (3) in the specification.
TCK tests do not cover the scenario well.
Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
If there is no deployment, the _UP_ it is.
Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
* OpenShift starts the service wait some time and start asking for health status
* WildFly responses _UP_ yet application helathcheck is not installed yet
* With health status _UP_ OpenShift consider a pod ready
* In this point application is ready, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
> MP Health returns UP when checks are expected but not installed yet.
> --------------------------------------------------------------------
>
> Key: WFLY-12952
> URL: https://issues.redhat.com/browse/WFLY-12952
> Project: WildFly
> Issue Type: Bug
> Components: MP Health
> Affects Versions: 18.0.0.Final
> Reporter: Ivan Straka
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> MicroProfile Health specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
> * A producer MUST support custom, application level health check procedures
> * A producer SHOULD support reasonable out-of-the-box procedures
> * A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
> * A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
> When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
> _Let me note that on OpenShift starting the served should mean starting the service._
> Hence I expect negative overall status till the probe is ready and is able to provide response.
> However WildFly with default setting responses with status UP:
> {code:bash}
> while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
> 17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
> 17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
> 17:17:56.466 {"status":"UP","checks":[]}
> ...
> 17:18:01.121 {"status":"UP","checks":[]}
> 17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
> {code}
> This violates (4) bullet in the specification.
> WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
> Which would mean the scenario would behave according to the specification. Yet the default state violates it.
> If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
> {noformat}
> 17:22:41.719
> {"status":"DOWN","checks":[]}
> {noformat}
> And that would violate (3) in the specification.
> TCK tests do not cover the scenario well.
> Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
> If there is no deployment, the _UP_ it is.
> Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
> * OpenShift starts the service wait some time and start asking for health status
> * WildFly responses _UP_ yet application helathcheck is not installed yet
> * With health status _UP_ OpenShift consider a pod ready
> * In this point application is installed, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12952) MP Health returns UP when checks are expected but not installed yet.
by Ivan Straka (Jira)
[ https://issues.redhat.com/browse/WFLY-12952?page=com.atlassian.jira.plugi... ]
Ivan Straka updated WFLY-12952:
-------------------------------
Description:
MicroProfile Health specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
* A producer MUST support custom, application level health check procedures
* A producer SHOULD support reasonable out-of-the-box procedures
* A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
* A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
_Let me note that on OpenShift starting the served should mean starting the service._
Hence I expect negative overall status till the probe is ready and is able to provide response.
However WildFly with default setting responses with status UP:
{code:bash}
while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.466 {"status":"UP","checks":[]}
...
17:18:01.121 {"status":"UP","checks":[]}
17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
{code}
This violates (4) bullet in the specification.
WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
Which would mean the scenario would behave according to the specification. Yet the default state violates it.
If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
{noformat}
17:22:41.719
{"status":"DOWN","checks":[]}
{noformat}
And that would violate (3) in the specification.
TCK tests do not cover the scenario well.
Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
If there is no deployment, the _UP_ it is.
Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
* OpenShift starts the service wait some time and start asking for health status
* WildFly responses _UP_ yet application helathcheck is not installed yet
* With health status _UP_ OpenShift consider a pod ready
* In this point application is ready, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
was:
MicroProfile Health specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
* A producer MUST support custom, application level health check procedures
* A producer SHOULD support reasonable out-of-the-box procedures
* A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
* A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
_Let me note that on OpenShift starting the served should mean starting the service._
Hence I expect negative overall status till the probe is ready and is able to provide response.
However WildFly with default setting responses with status UP:
{code:bash}
while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.466 {"status":"UP","checks":[]}
...
17:18:01.121 {"status":"UP","checks":[]}
17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
{code}
This violates (4) bullet in the specification.
WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
Which would mean the scenario would behave according to the specification. Yet the default state violates it.
If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
{noformat}
17:22:41.719
{"status":"DOWN","checks":[]}
{noformat}
And that would violate (3) in the specification.
TCK tests do not cover the scenario well.
Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
If there is no deployment, the _UP_ it is.
Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
* OpenShift starts the service wait some time and start asking for health status
* WildFly responses _UP_ yet application helathcheck is not installed yet
* With health status _UP_ OpenShift consider a pod ready
* In this point application is ready, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
> MP Health returns UP when checks are expected but not installed yet.
> --------------------------------------------------------------------
>
> Key: WFLY-12952
> URL: https://issues.redhat.com/browse/WFLY-12952
> Project: WildFly
> Issue Type: Bug
> Components: MP Health
> Affects Versions: 18.0.0.Final
> Reporter: Ivan Straka
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> MicroProfile Health specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
> * A producer MUST support custom, application level health check procedures
> * A producer SHOULD support reasonable out-of-the-box procedures
> * A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
> * A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
> When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
> _Let me note that on OpenShift starting the served should mean starting the service._
> Hence I expect negative overall status till the probe is ready and is able to provide response.
> However WildFly with default setting responses with status UP:
> {code:bash}
> while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
> 17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
> 17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
> 17:17:56.466 {"status":"UP","checks":[]}
> ...
> 17:18:01.121 {"status":"UP","checks":[]}
> 17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
> {code}
> This violates (4) bullet in the specification.
> WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
> Which would mean the scenario would behave according to the specification. Yet the default state violates it.
> If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
> {noformat}
> 17:22:41.719
> {"status":"DOWN","checks":[]}
> {noformat}
> And that would violate (3) in the specification.
> TCK tests do not cover the scenario well.
> Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
> If there is no deployment, the _UP_ it is.
> Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
> * OpenShift starts the service wait some time and start asking for health status
> * WildFly responses _UP_ yet application helathcheck is not installed yet
> * With health status _UP_ OpenShift consider a pod ready
> * In this point application is ready, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12952) MP Health returns UP when checks are expected but not installed yet.
by Ivan Straka (Jira)
[ https://issues.redhat.com/browse/WFLY-12952?page=com.atlassian.jira.plugi... ]
Ivan Straka updated WFLY-12952:
-------------------------------
Description:
MicroProfile Health specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
* A producer MUST support custom, application level health check procedures
* A producer SHOULD support reasonable out-of-the-box procedures
* A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
* A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
_Let me note that on OpenShift starting the served should mean starting the service._
Hence I expect negative overall status till the probe is ready and is able to provide response.
However WildFly with default setting responses with status UP:
{code:bash}
while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.466 {"status":"UP","checks":[]}
...
17:18:01.121 {"status":"UP","checks":[]}
17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
{code}
This violates (4) bullet in the specification.
WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
Which would mean the scenario would behave according to the specification. Yet the default state violates it.
If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
{noformat}
17:22:41.719
{"status":"DOWN","checks":[]}
{noformat}
And that would violate (3) in the specification.
TCK tests do not cover the scenario well.
Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
If there is no deployment, the _UP_ it is.
Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
* OpenShift starts the service wait some time and start asking for health status
* WildFly responses _UP_ yet application helathcheck is not installed yet
* With health status _UP_ OpenShift shall proceeds
* In this point application is ready, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
was:
MicroProfile Health specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
* A producer MUST support custom, application level health check procedures
* A producer SHOULD support reasonable out-of-the-box procedures
* A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
* A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
_Let me note that on OpenShift starting the served should mean starting the service._
Hence I expect negative overall status till the probe is ready and is able to provide response.
However WildFly with default setting responses with status UP:
{code:bash}
while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.466 {"status":"UP","checks":[]}
...
17:18:01.121 {"status":"UP","checks":[]}
17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
{code}
This violates (4) bullet in the specification.
WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
Which would mean the scenario would behave according to the specification. Yet the default state violates it.
If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
{noformat}
17:22:41.719
{"status":"DOWN","checks":[]}
{noformat}
And that would violate (3) in the specification.
TCK tests do not cover the scenario well.
Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
If there is no deployment, the _UP_ it is.
> MP Health returns UP when checks are expected but not installed yet.
> --------------------------------------------------------------------
>
> Key: WFLY-12952
> URL: https://issues.redhat.com/browse/WFLY-12952
> Project: WildFly
> Issue Type: Bug
> Components: MP Health
> Affects Versions: 18.0.0.Final
> Reporter: Ivan Straka
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> MicroProfile Health specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
> * A producer MUST support custom, application level health check procedures
> * A producer SHOULD support reasonable out-of-the-box procedures
> * A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
> * A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
> When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
> _Let me note that on OpenShift starting the served should mean starting the service._
> Hence I expect negative overall status till the probe is ready and is able to provide response.
> However WildFly with default setting responses with status UP:
> {code:bash}
> while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
> 17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
> 17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
> 17:17:56.466 {"status":"UP","checks":[]}
> ...
> 17:18:01.121 {"status":"UP","checks":[]}
> 17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
> {code}
> This violates (4) bullet in the specification.
> WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
> Which would mean the scenario would behave according to the specification. Yet the default state violates it.
> If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
> {noformat}
> 17:22:41.719
> {"status":"DOWN","checks":[]}
> {noformat}
> And that would violate (3) in the specification.
> TCK tests do not cover the scenario well.
> Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
> If there is no deployment, the _UP_ it is.
> Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
> * OpenShift starts the service wait some time and start asking for health status
> * WildFly responses _UP_ yet application helathcheck is not installed yet
> * With health status _UP_ OpenShift shall proceeds
> * In this point application is ready, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12952) MP Health returns UP when checks are expected but not installed yet.
by Ivan Straka (Jira)
[ https://issues.redhat.com/browse/WFLY-12952?page=com.atlassian.jira.plugi... ]
Ivan Straka updated WFLY-12952:
-------------------------------
Description:
MicroProfile Health specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
* A producer MUST support custom, application level health check procedures
* A producer SHOULD support reasonable out-of-the-box procedures
* A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
* A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
_Let me note that on OpenShift starting the served should mean starting the service._
Hence I expect negative overall status till the probe is ready and is able to provide response.
However WildFly with default setting responses with status UP:
{code:bash}
while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.466 {"status":"UP","checks":[]}
...
17:18:01.121 {"status":"UP","checks":[]}
17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
{code}
This violates (4) bullet in the specification.
WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
Which would mean the scenario would behave according to the specification. Yet the default state violates it.
If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
{noformat}
17:22:41.719
{"status":"DOWN","checks":[]}
{noformat}
And that would violate (3) in the specification.
TCK tests do not cover the scenario well.
Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
If there is no deployment, the _UP_ it is.
Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
* OpenShift starts the service wait some time and start asking for health status
* WildFly responses _UP_ yet application helathcheck is not installed yet
* With health status _UP_ OpenShift consider a pod ready
* In this point application is ready, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
was:
MicroProfile Health specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
* A producer MUST support custom, application level health check procedures
* A producer SHOULD support reasonable out-of-the-box procedures
* A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
* A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
_Let me note that on OpenShift starting the served should mean starting the service._
Hence I expect negative overall status till the probe is ready and is able to provide response.
However WildFly with default setting responses with status UP:
{code:bash}
while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.466 {"status":"UP","checks":[]}
...
17:18:01.121 {"status":"UP","checks":[]}
17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
{code}
This violates (4) bullet in the specification.
WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
Which would mean the scenario would behave according to the specification. Yet the default state violates it.
If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
{noformat}
17:22:41.719
{"status":"DOWN","checks":[]}
{noformat}
And that would violate (3) in the specification.
TCK tests do not cover the scenario well.
Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
If there is no deployment, the _UP_ it is.
Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
* OpenShift starts the service wait some time and start asking for health status
* WildFly responses _UP_ yet application helathcheck is not installed yet
* With health status _UP_ OpenShift shall proceeds
* In this point application is ready, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
> MP Health returns UP when checks are expected but not installed yet.
> --------------------------------------------------------------------
>
> Key: WFLY-12952
> URL: https://issues.redhat.com/browse/WFLY-12952
> Project: WildFly
> Issue Type: Bug
> Components: MP Health
> Affects Versions: 18.0.0.Final
> Reporter: Ivan Straka
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> MicroProfile Health specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
> * A producer MUST support custom, application level health check procedures
> * A producer SHOULD support reasonable out-of-the-box procedures
> * A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
> * A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
> When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
> _Let me note that on OpenShift starting the served should mean starting the service._
> Hence I expect negative overall status till the probe is ready and is able to provide response.
> However WildFly with default setting responses with status UP:
> {code:bash}
> while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
> 17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
> 17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
> 17:17:56.466 {"status":"UP","checks":[]}
> ...
> 17:18:01.121 {"status":"UP","checks":[]}
> 17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
> {code}
> This violates (4) bullet in the specification.
> WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
> Which would mean the scenario would behave according to the specification. Yet the default state violates it.
> If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
> {noformat}
> 17:22:41.719
> {"status":"DOWN","checks":[]}
> {noformat}
> And that would violate (3) in the specification.
> TCK tests do not cover the scenario well.
> Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
> If there is no deployment, the _UP_ it is.
> Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
> * OpenShift starts the service wait some time and start asking for health status
> * WildFly responses _UP_ yet application helathcheck is not installed yet
> * With health status _UP_ OpenShift consider a pod ready
> * In this point application is ready, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12952) MP Health returns UP when checks are expected but not installed yet.
by Ivan Straka (Jira)
[ https://issues.redhat.com/browse/WFLY-12952?page=com.atlassian.jira.plugi... ]
Ivan Straka updated WFLY-12952:
-------------------------------
Description:
MicroProfile Health specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
* A producer MUST support custom, application level health check procedures
* A producer SHOULD support reasonable out-of-the-box procedures
* A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
* A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
_Let me note that on OpenShift starting the served should mean starting the service._
Hence I expect negative overall status till the probe is ready and is able to provide response.
However WildFly with default setting responses with status UP:
{code:bash}
while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.466 {"status":"UP","checks":[]}
...
17:18:01.121 {"status":"UP","checks":[]}
17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
{code}
This violates (4) bullet in the specification.
WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
Which would mean the scenario would behave according to the specification. Yet the default state violates it.
If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
{noformat}
17:22:41.719
{"status":"DOWN","checks":[]}
{noformat}
And that would violate (3) in the specification.
TCK tests do not cover the scenario well.
Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
If there is no deployment, the _UP_ it is.
was:
MicroProfile Health specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/... says:
* A producer MUST support custom, application level health check procedures
* A producer SHOULD support reasonable out-of-the-box procedures
* A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
* A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
_Let me note that on OpenShift starting the served should mean starting the service._
Hence I expect negative overall status till the probe is ready and is able to provide response.
However WildFly with default setting responses with status UP:
{code:bash}
while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.466 {"status":"UP","checks":[]}
...
17:18:01.121 {"status":"UP","checks":[]}
17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
{code}
This violates (4) bullet in the specification.
WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
Which would mean the scenario would behave according to the specification. Yet the default state violates it.
If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
{noformat}
17:22:41.719
{"status":"DOWN","checks":[]}
{noformat}
And that would violate (3) in the specification.
TCK tests do not cover the scenario well.
Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
If there is no deployment, the _UP_ it is.
> MP Health returns UP when checks are expected but not installed yet.
> --------------------------------------------------------------------
>
> Key: WFLY-12952
> URL: https://issues.redhat.com/browse/WFLY-12952
> Project: WildFly
> Issue Type: Bug
> Components: MP Health
> Affects Versions: 18.0.0.Final
> Reporter: Ivan Straka
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> MicroProfile Health specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
> * A producer MUST support custom, application level health check procedures
> * A producer SHOULD support reasonable out-of-the-box procedures
> * A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
> * A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
> When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
> _Let me note that on OpenShift starting the served should mean starting the service._
> Hence I expect negative overall status till the probe is ready and is able to provide response.
> However WildFly with default setting responses with status UP:
> {code:bash}
> while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
> 17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
> 17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
> 17:17:56.466 {"status":"UP","checks":[]}
> ...
> 17:18:01.121 {"status":"UP","checks":[]}
> 17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
> {code}
> This violates (4) bullet in the specification.
> WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
> Which would mean the scenario would behave according to the specification. Yet the default state violates it.
> If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
> {noformat}
> 17:22:41.719
> {"status":"DOWN","checks":[]}
> {noformat}
> And that would violate (3) in the specification.
> TCK tests do not cover the scenario well.
> Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
> If there is no deployment, the _UP_ it is.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12952) MP Health returns UP when checks are expected but not installed yet.
by Ivan Straka (Jira)
Ivan Straka created WFLY-12952:
----------------------------------
Summary: MP Health returns UP when checks are expected but not installed yet.
Key: WFLY-12952
URL: https://issues.redhat.com/browse/WFLY-12952
Project: WildFly
Issue Type: Bug
Components: MP Health
Affects Versions: 18.0.0.Final
Reporter: Ivan Straka
Assignee: Jeff Mesnil
MicroProfile Health specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/... says:
* A producer MUST support custom, application level health check procedures
* A producer SHOULD support reasonable out-of-the-box procedures
* A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
* A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
_Let me note that on OpenShift starting the served should mean starting the service._
Hence I expect negative overall status till the probe is ready and is able to provide response.
However WildFly with default setting responses with status UP:
{code:bash}
while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.466 {"status":"UP","checks":[]}
...
17:18:01.121 {"status":"UP","checks":[]}
17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
{code}
This violates (4) bullet in the specification.
WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
Which would mean the scenario would behave according to the specification. Yet the default state violates it.
If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
{noformat}
17:22:41.719
{"status":"DOWN","checks":[]}
{noformat}
And that would violate (3) in the specification.
TCK tests do not cover the scenario well.
Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
If there is no deployment, the _UP_ it is.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4698) Adding "expression" type handling for Collection type propereties
by Yeser Amer (Jira)
[ https://issues.redhat.com/browse/DROOLS-4698?page=com.atlassian.jira.plug... ]
Yeser Amer commented on DROOLS-4698:
------------------------------------
Comment 1: Issue present in master and not related to this PR. Can you please open a new ticket?
Comment 2: (not tested in master) in my opinion same of comment 1
Comment 3: 1. Inside the expression I see "Free Rooms", which is not a valid expression
3. you need to compare the FEEL list with the value definied in GIVEN in this way --->" ? = [{Capacity : 1, Price : 1500}, {Capacity : 1, Price : 1200}] "
"?" represents the actualValue.
Comment 4: I changed part of the code during code review, then it seems no more present. BUT if you try to open a duplicated ExpressionCollection cell, an exception is thrown. I need to fix that. I'll notify you when is fixed.
Thank you!
> Adding "expression" type handling for Collection type propereties
> -----------------------------------------------------------------
>
> Key: DROOLS-4698
> URL: https://issues.redhat.com/browse/DROOLS-4698
> Project: Drools
> Issue Type: Feature Request
> Components: Scenario Simulation and Testing
> Reporter: Yeser Amer
> Assignee: Yeser Amer
> Priority: Major
> Labels: UX, UXTeam, drools-tools
> Attachments: Screenshot from 2020-01-08 14-14-05.png, Screenshot from 2020-01-08 14-20-30.png, Screenshot from 2020-01-08 14-36-33.png, Screenshot from 2020-01-08 14-36-52.png, test urgent.scesim, urgent.dmn
>
>
> Support is about both drools/java collections and dmn collections.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4698) Adding "expression" type handling for Collection type propereties
by Yeser Amer (Jira)
[ https://issues.redhat.com/browse/DROOLS-4698?page=com.atlassian.jira.plug... ]
Yeser Amer edited comment on DROOLS-4698 at 1/9/20 11:26 AM:
-------------------------------------------------------------
[~jomarko]
Comment 1: Issue present in master and not related to this PR. Can you please open a new ticket?
Comment 2: (not tested in master) in my opinion same of comment 1
Comment 3: 1. Inside the expression I see "Free Rooms", which is not a valid expression
3. you need to compare the FEEL list with the value definied in GIVEN in this way --->" ? = [{Capacity : 1, Price : 1500}, {Capacity : 1, Price : 1200}] "
"?" represents the actualValue.
Comment 4: I changed part of the code during code review, then it seems no more present. BUT if you try to open a duplicated ExpressionCollection cell, an exception is thrown. I need to fix that. I'll notify you when is fixed.
Thank you!
was (Author: yamer):
Comment 1: Issue present in master and not related to this PR. Can you please open a new ticket?
Comment 2: (not tested in master) in my opinion same of comment 1
Comment 3: 1. Inside the expression I see "Free Rooms", which is not a valid expression
3. you need to compare the FEEL list with the value definied in GIVEN in this way --->" ? = [{Capacity : 1, Price : 1500}, {Capacity : 1, Price : 1200}] "
"?" represents the actualValue.
Comment 4: I changed part of the code during code review, then it seems no more present. BUT if you try to open a duplicated ExpressionCollection cell, an exception is thrown. I need to fix that. I'll notify you when is fixed.
Thank you!
> Adding "expression" type handling for Collection type propereties
> -----------------------------------------------------------------
>
> Key: DROOLS-4698
> URL: https://issues.redhat.com/browse/DROOLS-4698
> Project: Drools
> Issue Type: Feature Request
> Components: Scenario Simulation and Testing
> Reporter: Yeser Amer
> Assignee: Yeser Amer
> Priority: Major
> Labels: UX, UXTeam, drools-tools
> Attachments: Screenshot from 2020-01-08 14-14-05.png, Screenshot from 2020-01-08 14-20-30.png, Screenshot from 2020-01-08 14-36-33.png, Screenshot from 2020-01-08 14-36-52.png, test urgent.scesim, urgent.dmn
>
>
> Support is about both drools/java collections and dmn collections.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFWIP-288) JWT signed by 1024 bit long key is rejected
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFWIP-288?page=com.atlassian.jira.plugin... ]
Darran Lofthouse commented on WFWIP-288:
----------------------------------------
I have created https://issues.redhat.com/browse/WFLY-12951 to track that we need to follow this up.
> JWT signed by 1024 bit long key is rejected
> -------------------------------------------
>
> Key: WFWIP-288
> URL: https://issues.redhat.com/browse/WFWIP-288
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP JWT
> Reporter: Jan Kasik
> Assignee: Darran Lofthouse
> Priority: Major
>
> According to MP-JWT 1.1 specification, 1024 and 2048 bit key sizes must be supported. Though when there is JWT signed by 1024 bit long key presented to the server, it is rejected and client receives "Unauthorized" (code 401) message.
> See chapter 9.2. Supported Public Key Formats:
> {quote}
> Support for RSA Public Keys of 1024 or 2048 bits in length is required. Other key sizes are allowed, but should be considered vendor-specific.
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12951) JWT signed by 1024 bit long key is rejected
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFLY-12951?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFLY-12951:
-----------------------------------------
As discussed within WFWIP-288 there is an ambiguity in the spec where MP JWT requires a specific signature algorithm and subsequently specifies using a key size too small for that algorithm. This WFLY issue is to track so we can follow up on the next iteration of spec development.
> JWT signed by 1024 bit long key is rejected
> -------------------------------------------
>
> Key: WFLY-12951
> URL: https://issues.redhat.com/browse/WFLY-12951
> Project: WildFly
> Issue Type: Bug
> Components: MP JWT
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
>
> According to MP-JWT 1.1 specification, 1024 and 2048 bit key sizes must be supported. Though when there is JWT signed by 1024 bit long key presented to the server, it is rejected and client receives "Unauthorized" (code 401) message.
> See chapter 9.2. Supported Public Key Formats:
> {quote}
> Support for RSA Public Keys of 1024 or 2048 bits in length is required. Other key sizes are allowed, but should be considered vendor-specific.
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months