[JBoss JIRA] (WFLY-12811) Can not inject MP Config property to a HealthCheck bean
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-12811?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-12811:
-----------------------------------------
Tangent: Can the workaround and all comments be edited to s/:reload/reload/g ?
CLI users should use the high level command not the low level operation.
> 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] (WFLY-12814) PreDestroy method not called by stateful beans with timeout 0
by Cheng Fang (Jira)
[ https://issues.jboss.org/browse/WFLY-12814?page=com.atlassian.jira.plugin... ]
Cheng Fang commented on WFLY-12814:
-----------------------------------
stateful-timeout value 0 means immediate timeout and so its usage is not common. So by not using the direct remove should slightly simplif the logic and should not have material perf impact.
> PreDestroy method not called by stateful beans with timeout 0
> --------------------------------------------------------------
>
> Key: WFLY-12814
> URL: https://issues.jboss.org/browse/WFLY-12814
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 18.0.0.Final
> Reporter: Cheng Fang
> Assignee: Cheng Fang
> Priority: Major
> Fix For: 19.0.0.Beta1
>
>
> When a stateful bean is configured to have timeout value 0, its preDestroy method is not called when removing it. The expected behavior is the bean should timeout and be eligible for removal immediately (since the stateful timeout is 0), and its preDestroy method is called before the bean is removed.
> The problem seems to be in {{org.jboss.as.ejb3.cache.simple.SimpleCache}}, which removes the bean with 0 timeout value directly, instead of submitting it to {{org.wildfly.clustering.ee.cache.scheduler.LocalScheduler}} for removal. The direct removal does not have all the proper setup for the preDestroy method to be invoked.
> {code:java}
> @Stateful
> @StatefulTimeout(value = 0, unit = TimeUnit.SECONDS)
> //when changed @StatefulTimeout to 1, it works as expected.
> //@StatefulTimeout(value = 1, unit = TimeUnit.SECONDS)
> public class StatefulHello {
> public void hello() {
> }
> @PreDestroy
> private void preDestroy() {
> System.out.printf("## preDestroy in StatefulHello%n");
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months
[JBoss JIRA] (DROOLS-4795) [DMN Designer] User is unable to save model when structure is removed
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-4795?page=com.atlassian.jira.plugi... ]
Jozef Marko reassigned DROOLS-4795:
-----------------------------------
Assignee: Daniel José dos Santos (was: karreiro)
> [DMN Designer] User is unable to save model when structure is removed
> ---------------------------------------------------------------------
>
> Key: DROOLS-4795
> URL: https://issues.jboss.org/browse/DROOLS-4795
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.31.0.Final
> Reporter: Jozef Marko
> Assignee: Daniel José dos Santos
> Priority: Major
> Labels: drools-tools
> Attachments: edit-and-remove.webm
>
>
> There is scenario causing user is not able to save the DMN file anymore. If is editing some structure field, but he decides in the middle of editing to rmeove whole structure, the save button of the designer remains disabled.
> We should either fix this scenario or drop the *disable save button* feature.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months
[JBoss JIRA] (DROOLS-4795) [DMN Designer] User is unable to save model when structure is removed
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-4795?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-4795:
--------------------------------
Sprint: 2019 Week 47-49 (from Nov 18)
> [DMN Designer] User is unable to save model when structure is removed
> ---------------------------------------------------------------------
>
> Key: DROOLS-4795
> URL: https://issues.jboss.org/browse/DROOLS-4795
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.31.0.Final
> Reporter: Jozef Marko
> Assignee: Daniel José dos Santos
> Priority: Major
> Labels: drools-tools
> Attachments: edit-and-remove.webm
>
>
> There is scenario causing user is not able to save the DMN file anymore. If is editing some structure field, but he decides in the middle of editing to rmeove whole structure, the save button of the designer remains disabled.
> We should either fix this scenario or drop the *disable save button* feature.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months
[JBoss JIRA] (JGRP-2411) JGraSS: JGroups as a Service
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2411?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2411:
---------------------------
Description:
Provide a separate server implementation of Channel (_server service_) which runs as a separate process, plus a client stub ({{RemoteChannel}}, implementing {{Channel}}) which communicates with the service.
The communication is across pipes/sockets/shared memory (TBD) and assumes servers and clients are on the same host. Most method calls of {{Channel}} need to be supported.
h3. Advantages
h4. Fast replacement
The server process could be replaced on the fly with a different server process, e.g. using a different configuration.
If compiled down to a native image (using GraalVM), this would take only a few milliseconds.
This could move the config permutations (UDP/TCP/NIO/PING/TCPPING/KUBE_PING/DNS_PING etc) from Infinispan into the separate server process.
h4. Rolling upgrades
We could have a Channel implementation, which communicates with multiple remote JGroups servers, sending messages to both and receiving messages from both servers.
One server could be running 3.6. Later, a 4.x server could be added and when all members have a dual-channel, the 3.6 channels could be shut down, effectively performing a rolling upgrade of JGroups from a version to a different version.
h3. Disadvantages
This would be much slower, because of the serialization overhead. Perhaps shared memory could be used on the same host to avoid that...
was:
Provide a separate server implementation of Channel (_server service_) which runs as a separate process, plus a client stub ({{RemoteChannel}}, implementing {{Channel}}) which communicates with the service.
The communication is across pipes/sockets/shared memory (TBD) and assumes servers and clients are on the same host. Most method calls of {{Channel}} need to be supported.
h3. Advantages
h4. Fast replacement
The server process could be replaced on the fly with a different server process, e.g. using a different configuration.
If compiled down to a native image (using GraalVM), this would take only a few milliseconds.
h4. Rolling upgrades
We could have a Channel implementation, which communicates with multiple remote JGroups servers, sending messages to both and receiving messages from both servers.
One server could be running 3.6. Later, a 4.x server could be added and when all members have a dual-channel, the 3.6 channels could be shut down, effectively performing a rolling upgrade.
h3. Disadvantages
This would be much slower, because of the serialization overhead. Perhaps shared memory could be used on the same host to avoid that...
> JGraSS: JGroups as a Service
> ----------------------------
>
> Key: JGRP-2411
> URL: https://issues.jboss.org/browse/JGRP-2411
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.9
>
>
> Provide a separate server implementation of Channel (_server service_) which runs as a separate process, plus a client stub ({{RemoteChannel}}, implementing {{Channel}}) which communicates with the service.
> The communication is across pipes/sockets/shared memory (TBD) and assumes servers and clients are on the same host. Most method calls of {{Channel}} need to be supported.
> h3. Advantages
> h4. Fast replacement
> The server process could be replaced on the fly with a different server process, e.g. using a different configuration.
> If compiled down to a native image (using GraalVM), this would take only a few milliseconds.
> This could move the config permutations (UDP/TCP/NIO/PING/TCPPING/KUBE_PING/DNS_PING etc) from Infinispan into the separate server process.
> h4. Rolling upgrades
> We could have a Channel implementation, which communicates with multiple remote JGroups servers, sending messages to both and receiving messages from both servers.
> One server could be running 3.6. Later, a 4.x server could be added and when all members have a dual-channel, the 3.6 channels could be shut down, effectively performing a rolling upgrade of JGroups from a version to a different version.
> h3. Disadvantages
> This would be much slower, because of the serialization overhead. Perhaps shared memory could be used on the same host to avoid that...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months
[JBoss JIRA] (JGRP-2411) JGraSS: JGroups as a Service
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2411?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2411:
---------------------------
Description:
Provide a separate server implementation of Channel (_server service_) which runs as a separate process, plus a client stub ({{RemoteChannel}}, implementing {{Channel}}) which communicates with the service.
The communication is across pipes/sockets/shared memory (TBD) and assumes servers and clients are on the same host. Most method calls of {{Channel}} need to be supported.
h3. Advantages
h4. Fast replacement
The server process could be replaced on the fly with a different server process, e.g. using a different configuration.
If compiled down to a native image (using GraalVM), this would take only a few milliseconds.
h4. Rolling upgrades
We could have a Channel implementation, which communicates with multiple remote JGroups servers, sending messages to both and receiving messages from both servers.
One server could be running 3.6. Later, a 4.x server could be added and when all members have a dual-channel, the 3.6 channels could be shut down, effectively performing a rolling upgrade.
h3. Disadvantages
This would be much slower, because of the serialization overhead. Perhaps shared memory could be used on the same host to avoid that...
was:
Provide a separate server implementation of Channel (_server service_) which runs as a separate process, plus a client stub ({{RemoteChannel}}, implementing {{Channel}}) which communicates with the service.
The communication is across pipes/sockets/shared memory (TBD) and assumes servers and clients are on the same host. Most method calls of {{Channel}} need to be supported.
h3. Advantages
h4. Fast replacement
The server process could be replaced on the fly with a different server process, e.g. using a different configuration.
If compiled down to a native image (using GraalVM), this would take only a few milliseconds.
h4. Rolling upgrades
We could have a Channel implementation, which communicates with multiple remote JGroups servers, sending messages to both and receiving messages from both servers.
One server could be running 3.6. Later, a 4.x server could be added and when all members have a dual-channel, the 3.6 channels could be shut down, effectively performing a rolling upgrade.
> JGraSS: JGroups as a Service
> ----------------------------
>
> Key: JGRP-2411
> URL: https://issues.jboss.org/browse/JGRP-2411
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.9
>
>
> Provide a separate server implementation of Channel (_server service_) which runs as a separate process, plus a client stub ({{RemoteChannel}}, implementing {{Channel}}) which communicates with the service.
> The communication is across pipes/sockets/shared memory (TBD) and assumes servers and clients are on the same host. Most method calls of {{Channel}} need to be supported.
> h3. Advantages
> h4. Fast replacement
> The server process could be replaced on the fly with a different server process, e.g. using a different configuration.
> If compiled down to a native image (using GraalVM), this would take only a few milliseconds.
> h4. Rolling upgrades
> We could have a Channel implementation, which communicates with multiple remote JGroups servers, sending messages to both and receiving messages from both servers.
> One server could be running 3.6. Later, a 4.x server could be added and when all members have a dual-channel, the 3.6 channels could be shut down, effectively performing a rolling upgrade.
> h3. Disadvantages
> This would be much slower, because of the serialization overhead. Perhaps shared memory could be used on the same host to avoid that...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months
[JBoss JIRA] (JGRP-2411) JGraSS: JGroups as a Service
by Bela Ban (Jira)
Bela Ban created JGRP-2411:
------------------------------
Summary: JGraSS: JGroups as a Service
Key: JGRP-2411
URL: https://issues.jboss.org/browse/JGRP-2411
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 4.1.9
Provide a separate server implementation of Channel (_server service_) which runs as a separate process, plus a client stub ({{RemoteChannel}}, implementing {{Channel}}) which communicates with the service.
The communication is across pipes/sockets/shared memory (TBD) and assumes servers and clients are on the same host. Most method calls of {{Channel}} need to be supported.
h3. Advantages
h4. Fast replacement
The server process could be replaced on the fly with a different server process, e.g. using a different configuration.
If compiled down to a native image (using GraalVM), this would take only a few milliseconds.
h4. Rolling upgrades
We could have a Channel implementation, which communicates with multiple remote JGroups servers, sending messages to both and receiving messages from both servers.
One server could be running 3.6. Later, a 4.x server could be added and when all members have a dual-channel, the 3.6 channels could be shut down, effectively performing a rolling upgrade.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months
[JBoss JIRA] (JGRP-2405) Re-activate Channel
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2405?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2405:
---------------------------
Description: The {{Channel}} interface has been deprecated. However, to implement JGraSS, we need it. Remove the @Deprecated tag and make JChannel implement Channel. (was: The {{Channel}} interface has been deprecated. However, to implement GraSS, we need it. Remove the @Deprecated tag and make JChannel implement Channel.)
> Re-activate Channel
> -------------------
>
> Key: JGRP-2405
> URL: https://issues.jboss.org/browse/JGRP-2405
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.1.9
>
>
> The {{Channel}} interface has been deprecated. However, to implement JGraSS, we need it. Remove the @Deprecated tag and make JChannel implement Channel.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months