[JBoss JIRA] (WFLY-12811) Can not inject MP Config property to a HealthCheck bean
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFLY-12811?page=com.atlassian.jira.plugin... ]
Jeff Mesnil commented on WFLY-12811:
------------------------------------
I built your reproducer and it works as expected:
{code}
$ ./bin/standalone.sh -c standalone-full.xml -Ddummy_live=true
...
$ curl http://:8080/mp-1.0/dummy
true
$ curl http://:9990/health
{"status":"UP","checks":[{"name":"dummy","status":"UP"}]}
$ ./bin/standalone.sh -c standalone-full.xml -Ddummy_live=false
...
$ curl http://:8080/mp-1.0/dummy
false
$ curl http://:9990/health
{"status":"DOWN","checks":[{"name":"dummy","status":"DOWN"}]}
> Can not inject MP Config property to a HealthCheck bean
> -------------------------------------------------------
>
> Key: WFLY-12811
> URL: https://issues.jboss.org/browse/WFLY-12811
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, MP Health
> Affects Versions: 18.0.1.Final
> Reporter: Ivan Straka
> Assignee: Jeff Mesnil
> Priority: Critical
> Attachments: mp-1.0.war
>
>
> I am playing a bit with MP specs (getting multiple specs to work together). I have been trying to return Health status based on injected config property (MP Config). However it looks like the property is not properly injected to the bean.
> {code:java}
> @Liveness
> @ApplicationScoped
> public class CDIBasedLivenessHealthCheck implements HealthCheck {
> @Inject
> @ConfigProperty(name = "dummy_live")
> private Provider<Boolean> live;
> @Override
> public HealthCheckResponse call() {
> return HealthCheckResponse.named("dummy")
> .state(live.get())
> .build();
> }
> }
> {code}
> I am get following error:
> {code:java}
> 15:41:04,616 ERROR [org.wildfly.extension.microprofile.health.smallrye] (management I/O-2) Error processing Health Checks: java.lang.NullPointerException
> at health.CDIBasedLivenessHealthCheck.call(CDIBasedLivenessHealthCheck.java:26)
> at health.CDIBasedLivenessHealthCheck$Proxy$_$$_WeldClientProxy.call(Unknown Source)
> at org.wildfly.extension.microprofile.health.HealthReporter.jsonObject(HealthReporter.java:120)
> at org.wildfly.extension.microprofile.health.HealthReporter.fillCheck(HealthReporter.java:107)
> at org.wildfly.extension.microprofile.health.HealthReporter.processChecks(HealthReporter.java:96)
> at org.wildfly.extension.microprofile.health.HealthReporter.getHealth(HealthReporter.java:79)
> at org.wildfly.extension.microprofile.health.HealthReporter.getHealth(HealthReporter.java:60)
> at org.wildfly.extension.microprofile.health.HealthContextService$HealthCheckHandler.handleRequest(HealthContextService.java:100)
> at org.jboss.as.domain.http.server.security.RealmReadinessHandler.handleRequest(RealmReadinessHandler.java:51)
> at org.jboss.as.domain.http.server.security.ServerErrorReadinessHandler.handleRequest(ServerErrorReadinessHandler.java:35)
> at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:91)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:211)
> at io.undertow.server.handlers.cache.CacheHandler.handleRequest(CacheHandler.java:92)
> at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:78)
> at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49)
> at org.jboss.as.domain.http.server.ManagementHttpRequestHandler.handleRequest(ManagementHttpRequestHandler.java:57)
> at org.jboss.as.domain.http.server.cors.CorsHttpHandler.handleRequest(CorsHttpHandler.java:75)
> at org.jboss.as.domain.http.server.ManagementHttpServer$UpgradeFixHandler.handleRequest(ManagementHttpServer.java:672)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:376)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:255)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:162)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:100)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:57)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.QueuedNioTcpServer2.acceptTask(QueuedNioTcpServer2.java:178)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:479)
> {code}
> I believe there is a bug in MP Health integration rather than in weld. After checks are registered here in [CDIExtension|https://github.com/wildfly/wildfly/blob/master/microprofile/...] I am able to call _check.call()_ and I get _UP_ as a result. However during HTTP call here in [HealthReporter|https://github.com/wildfly/wildfly/blob/master/microprofil...] I get NPE.
> I can inject a dummy bean. However if the dummy bean injects a config property, NPE is thrown.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months
[JBoss JIRA] (WFWIP-276) Boot time of application built via S2I is much longer than in before-Galleon times
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFWIP-276?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil reassigned WFWIP-276:
---------------------------------
Assignee: Jean Francois Denise (was: Jeff Mesnil)
> Boot time of application built via S2I is much longer than in before-Galleon times
> ----------------------------------------------------------------------------------
>
> Key: WFWIP-276
> URL: https://issues.jboss.org/browse/WFWIP-276
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Jan Blizňák
> Assignee: Jean Francois Denise
> Priority: Critical
> Attachments: test-app.zip
>
>
> As a consequence of Galleon RFEs EAP7-891 and mainly EAP7-1216 there is big difference in pod with EAP application start up time which requires S2I configuration.
> This is an overview of quick comparison of average boot times of the application pods of the attached test app (we are not interested in build/deploy pod times etc):
> ||17.0-6||pod time||EAP boot||config time
> |#1 | 8283|6128|2155
> |#2 | 9446|7548|1898
> |#3 | 8767|6871| 1896
> |#4 | 8568|6272| 2296
> |#5 | 8000 |6362|1638
> ||average ||8613ms||6636ms||1977ms
> ||18.0-7||pod time||EAP boot||config time
> |#1 |13769|5716|8053
> |#2 |13362|5952|7410
> |#3 |14261|6093|8168
> |#4 |14322|6135|8187
> |#5 |13921|6326|7595
> ||average||13927ms||6044ms||7883ms
> pod time = time from the pod start until EAP is fully booted (log contains {{started in ..}})
> EAP boot = time of boot EAP itself == {{started in ..}}
> config time = the difference of previou timess = anything before EAP boot begins
> Again we are talking here about the time needed for prepared application image to full start. We can clearly see the EAP boot times are comparable between 17 and 18 images but the configs times are almost 4 times longer with CD18 images.
> This is very unfortunate as in my point of view the pod boot time is the most critical time for our users - they would typically prepare the app images only once in a time but their application can scale up and down many times during its uptime.
> The cause of this that when S2I is needed with image 18.0+ the part of the configuration that was previously done during S2I build just once is now processed on *each* pod start.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months
[JBoss JIRA] (WFWIP-276) Boot time of application built via S2I is much longer than in before-Galleon times
by Jan Blizňák (Jira)
[ https://issues.jboss.org/browse/WFWIP-276?page=com.atlassian.jira.plugin.... ]
Jan Blizňák updated WFWIP-276:
------------------------------
Attachment: test-app.zip
> Boot time of application built via S2I is much longer than in before-Galleon times
> ----------------------------------------------------------------------------------
>
> Key: WFWIP-276
> URL: https://issues.jboss.org/browse/WFWIP-276
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Jan Blizňák
> Assignee: Jean Francois Denise
> Priority: Critical
> Attachments: test-app.zip
>
>
> As a consequence of Galleon RFEs EAP7-891 and mainly EAP7-1216 there is big difference in pod with EAP application start up time which requires S2I configuration.
> This is an overview of quick comparison of average boot times of the application pods of the attached test app (we are not interested in build/deploy pod times etc):
> ||17.0-6||pod time||EAP boot||config time
> |#1 | 8283|6128|2155
> |#2 | 9446|7548|1898
> |#3 | 8767|6871| 1896
> |#4 | 8568|6272| 2296
> |#5 | 8000 |6362|1638
> ||average ||8613ms||6636ms||1977ms
> ||18.0-7||pod time||EAP boot||config time
> |#1 |13769|5716|8053
> |#2 |13362|5952|7410
> |#3 |14261|6093|8168
> |#4 |14322|6135|8187
> |#5 |13921|6326|7595
> ||average||13927ms||6044ms||7883ms
> pod time = time from the pod start until EAP is fully booted (log contains {{started in ..}})
> EAP boot = time of boot EAP itself == {{started in ..}}
> config time = the difference of previou timess = anything before EAP boot begins
> Again we are talking here about the time needed for prepared application image to full start. We can clearly see the EAP boot times are comparable between 17 and 18 images but the configs times are almost 4 times longer with CD18 images.
> This is very unfortunate as in my point of view the pod boot time is the most critical time for our users - they would typically prepare the app images only once in a time but their application can scale up and down many times during its uptime.
> The cause of this that when S2I is needed with image 18.0+ the part of the configuration that was previously done during S2I build just once is now processed on *each* pod start.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months
[JBoss JIRA] (WFWIP-276) Boot time of application built via S2I is much longer than in before-Galleon times
by Jan Blizňák (Jira)
[ https://issues.jboss.org/browse/WFWIP-276?page=com.atlassian.jira.plugin.... ]
Jan Blizňák updated WFWIP-276:
------------------------------
Description:
As a consequence of Galleon RFEs EAP7-891 and mainly EAP7-1216 there is big difference in pod with EAP application start up time which requires S2I configuration.
This is an overview of quick comparison of average boot times of the application pods of the attached test app (we are not interested in build/deploy pod times etc):
||17.0-6||pod time||EAP boot||config time
|#1 | 8283|6128|2155
|#2 | 9446|7548|1898
|#3 | 8767|6871| 1896
|#4 | 8568|6272| 2296
|#5 | 8000 |6362|1638
||average ||8613ms||6636ms||1977ms
||18.0-7||pod time||EAP boot||config time
|#1 |13769|5716|8053
|#2 |13362|5952|7410
|#3 |14261|6093|8168
|#4 |14322|6135|8187
|#5 |13921|6326|7595
||average||13927ms||6044ms||7883ms
pod time = time from the pod start until EAP is fully booted (log contains {{started in ..}})
EAP boot = time of boot EAP itself == {{started in ..}}
config time = the difference of previou timess = anything before EAP boot begins
Again we are talking here about the time needed for prepared application image to full start. We can clearly see the EAP boot times are comparable between 17 and 18 images but the configs times are almost 4 times longer with CD18 images.
This is very unfortunate as in my point of view the pod boot time is the most critical time for our users - they would typically prepare the app images only once in a time but their application can scale up and down many times during its uptime.
The cause of this that when S2I is needed with image 18.0+ the part of the configuration that was previously done during S2I build just once is now processed on *each* pod start.
was:
As a consequence of Galleon RFEs EAP7-891 and mainly EAP7-1216 there is big difference in pod with EAP application start up time which requires S2I configuration.
This is an overview of quick comparison of average boot times of the application pods of the attached test app (we are not interested in build/deploy pod times etc):
||17.0-6||pod time||EAP boot||config time
|#1 | 8283|6128|2155
|#2 | 9446|7548|1898
|#3 | 8767|6871| 1896
|#4 | 8568|6272| 2296
|#5 | 8000 |6362|1638
||average ||8613||6636||1977
||18.0-7||pod time||EAP boot||config time
|#1 |13769|5716|8053
|#2 |13362|5952|7410
|#3 |14261|6093|8168
|#4 |14322|6135|8187
|#5 |13921|6326|7595
||average||13927||6044||7883
pod time = time from the pod start until EAP is fully booted (log contains {{started in ..}})
EAP boot = time of boot EAP itself == {{started in ..}}
config time = the difference of previou timess = anything before EAP boot begins
Again we are talking here about the time needed for prepared application image to full start. We can clearly see the EAP boot times are comparable between 17 and 18 images but the configs times are almost 4 times longer with CD18 images.
This is very unfortunate as in my point of view the pod boot time is the most critical time for our users - they would typically prepare the app images only once in a time but their application can scale up and down many times during its uptime.
The cause of this that when S2I is needed with image 18.0+ the part of the configuration that was previously done during S2I build just once is now processed on *each* pod start.
> Boot time of application built via S2I is much longer than in before-Galleon times
> ----------------------------------------------------------------------------------
>
> Key: WFWIP-276
> URL: https://issues.jboss.org/browse/WFWIP-276
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Jan Blizňák
> Assignee: Jeff Mesnil
> Priority: Critical
>
> As a consequence of Galleon RFEs EAP7-891 and mainly EAP7-1216 there is big difference in pod with EAP application start up time which requires S2I configuration.
> This is an overview of quick comparison of average boot times of the application pods of the attached test app (we are not interested in build/deploy pod times etc):
> ||17.0-6||pod time||EAP boot||config time
> |#1 | 8283|6128|2155
> |#2 | 9446|7548|1898
> |#3 | 8767|6871| 1896
> |#4 | 8568|6272| 2296
> |#5 | 8000 |6362|1638
> ||average ||8613ms||6636ms||1977ms
> ||18.0-7||pod time||EAP boot||config time
> |#1 |13769|5716|8053
> |#2 |13362|5952|7410
> |#3 |14261|6093|8168
> |#4 |14322|6135|8187
> |#5 |13921|6326|7595
> ||average||13927ms||6044ms||7883ms
> pod time = time from the pod start until EAP is fully booted (log contains {{started in ..}})
> EAP boot = time of boot EAP itself == {{started in ..}}
> config time = the difference of previou timess = anything before EAP boot begins
> Again we are talking here about the time needed for prepared application image to full start. We can clearly see the EAP boot times are comparable between 17 and 18 images but the configs times are almost 4 times longer with CD18 images.
> This is very unfortunate as in my point of view the pod boot time is the most critical time for our users - they would typically prepare the app images only once in a time but their application can scale up and down many times during its uptime.
> The cause of this that when S2I is needed with image 18.0+ the part of the configuration that was previously done during S2I build just once is now processed on *each* pod start.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months
[JBoss JIRA] (WFWIP-276) Boot time of application built via S2I is much longer than in before-Galleon times
by Jan Blizňák (Jira)
Jan Blizňák created WFWIP-276:
---------------------------------
Summary: Boot time of application built via S2I is much longer than in before-Galleon times
Key: WFWIP-276
URL: https://issues.jboss.org/browse/WFWIP-276
Project: WildFly WIP
Issue Type: Bug
Components: OpenShift
Reporter: Jan Blizňák
Assignee: Jeff Mesnil
As a consequence of Galleon RFEs EAP7-891 and mainly EAP7-1216 there is big difference in pod with EAP application start up time which requires S2I configuration.
This is an overview of quick comparison of average boot times of the application pods of the attached test app (we are not interested in build/deploy pod times etc):
||17.0-6||pod time||EAP boot||config time
|#1 | 8283|6128|2155
|#2 | 9446|7548|1898
|#3 | 8767|6871| 1896
|#4 | 8568|6272| 2296
|#5 | 8000 |6362|1638
||average ||8613||6636||1977
||18.0-7||pod time||EAP boot||config time
|#1 |13769|5716|8053
|#2 |13362|5952|7410
|#3 |14261|6093|8168
|#4 |14322|6135|8187
|#5 |13921|6326|7595
||average||13927||6044||7883
pod time = time from the pod start until EAP is fully booted (log contains {{started in ..}})
EAP boot = time of boot EAP itself == {{started in ..}}
config time = the difference of previou timess = anything before EAP boot begins
Again we are talking here about the time needed for prepared application image to full start. We can clearly see the EAP boot times are comparable between 17 and 18 images but the configs times are almost 4 times longer with CD18 images.
This is very unfortunate as in my point of view the pod boot time is the most critical time for our users - they would typically prepare the app images only once in a time but their application can scale up and down many times during its uptime.
The cause of this that when S2I is needed with image 18.0+ the part of the configuration that was previously done during S2I build just once is now processed on *each* pod start.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months
[JBoss JIRA] (WFLY-12820) Simplify CoarseSessionAttributes mutation tracking
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-12820?page=com.atlassian.jira.plugin... ]
Paul Ferraro updated WFLY-12820:
--------------------------------
Description: CoarseSessionAttributes currently uses a ConcurrentHashMap<String, Boolean> for fine-grained tracking of the dirty state of the session. Now that we only mutate the session on close(), this can be simplified with a simple dirty flag.
> Simplify CoarseSessionAttributes mutation tracking
> --------------------------------------------------
>
> Key: WFLY-12820
> URL: https://issues.jboss.org/browse/WFLY-12820
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 18.0.1.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
>
> CoarseSessionAttributes currently uses a ConcurrentHashMap<String, Boolean> for fine-grained tracking of the dirty state of the session. Now that we only mutate the session on close(), this can be simplified with a simple dirty flag.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months