[JBoss JIRA] (JGRP-2416) Native image: test IPv6 addresses
by Bela Ban (Jira)
Bela Ban created JGRP-2416:
------------------------------
Summary: Native image: test IPv6 addresses
Key: JGRP-2416
URL: https://issues.jboss.org/browse/JGRP-2416
Project: JGroups
Issue Type: Task
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 4.1.9
Currently, we're using IPv4 because of flag {{-J-Djava.net.preferIPv4Stack=true}} in the generation of the native image with GraalVM.
Remove this flag and test IPv6 addresses with UDP, TCP and TCP_NIO2.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (DROOLS-4805) Memory leak in STREAM mode (# PointInTimeTriggers growing)
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-4805?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-4805:
--------------------------------
Sprint: 2019 Week 47-49 (from Nov 18)
> Memory leak in STREAM mode (# PointInTimeTriggers growing)
> ----------------------------------------------------------
>
> Key: DROOLS-4805
> URL: https://issues.jboss.org/browse/DROOLS-4805
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.29.0.Final
> Reporter: Jesse White
> Assignee: Mario Fusco
> Priority: Major
> Attachments: image-2019-11-25-10-31-07-281.png
>
>
> When running our engine in STREAM mode, we notice a number of Drools internal object references increasing time even though the fact count stays relatively constant.
> jmap -histo <pid> shows:
> {noformat}
> num #instances #bytes class name
> ----------------------------------------------
> 1: 17478466 1258449552 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask
> 2: 17475174 699006960 org.drools.core.time.impl.JDKTimerService$JDKJobHandle
> 3: 17762331 568394592 java.util.concurrent.ConcurrentHashMap$Node
> 4: 17475174 559205568 org.drools.core.rule.SlidingTimeWindow$BehaviorJobContext
> 5: 17475174 559205568 org.drools.core.time.impl.DefaultTimerJobInstance
> 6: 8596776 551411680 [C
> 7: 18898675 453568200 java.lang.Long
> 8: 17475174 419404176 org.drools.core.time.SelfRemovalJobContext
> 9: 17475174 279602784 org.drools.core.time.SelfRemovalJob
> 10: 17475174 279602784 org.drools.core.time.impl.PointInTimeTrigger
> 11: 9263698 222328752 java.lang.String
> 12: 4584671 146709472 java.util.HashMap$Node
> 13: 246658 138804176 [B
> {noformat}
> These number continue to increase over time until the system OOMs.
> Graph for # of facts in the session looks like:
> !image-2019-11-25-10-31-07-281.png|thumbnail!
> The engine is fairly busy - we're constantly adding and removing facts.
> Our rules are available here:
> https://github.com/OpenNMS/opennms/blob/opennms-25.0.0-1/opennms-base-ass...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (JGRP-2415) Fluent setters
by Bela Ban (Jira)
Bela Ban created JGRP-2415:
------------------------------
Summary: Fluent setters
Key: JGRP-2415
URL: https://issues.jboss.org/browse/JGRP-2415
Project: JGroups
Issue Type: Task
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 5.0
Make all setters of protocols/other classes fluent, e.g. instead of returning {{void}}, make a setter return the class so that setter calls can be chained.
This breaks API compatibility, so it can only be done in 5.0.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (JGRP-2414) Probe: list operations available for a protocol
by Bela Ban (Jira)
Bela Ban created JGRP-2414:
------------------------------
Summary: Probe: list operations available for a protocol
Key: JGRP-2414
URL: https://issues.jboss.org/browse/JGRP-2414
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 4.1.9
List the operations available to be invoked via probe in a given protocol, e.g.
{{probe.sh ops=NAKACK2}} would list all operations in NAKACK2
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (JGRP-2413) Probe: get rid of 'jmx' and 'op'
by Bela Ban (Jira)
Bela Ban created JGRP-2413:
------------------------------
Summary: Probe: get rid of 'jmx' and 'op'
Key: JGRP-2413
URL: https://issues.jboss.org/browse/JGRP-2413
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 4.1.9
Instead of {{probe.sh jmx=NAKACK2.level}} -> {{probe.sh NAKACK2.level}} and
{{probe.sh op=UNICAST3.dumpRoutingTable}} -> {{UNICAST3.dumpRoutingTable}}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (JGRP-2412) GMS: reduce likelyhood of merges on concurrent new member startup
by Bela Ban (Jira)
Bela Ban created JGRP-2412:
------------------------------
Summary: GMS: reduce likelyhood of merges on concurrent new member startup
Key: JGRP-2412
URL: https://issues.jboss.org/browse/JGRP-2412
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 4.1.9
When multiple new members are started concurrently, and no coord is present yet, different clients get different discovery results, and this may lead to merging.
If we have no coord, we could run the discovery protocol multiple time, *with the current members list being cached*, and then might end up with a more similar list of new members.
This could be governed by an additional attribute in {{Discovery}} ({{num_discovery_runs}}?)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (DROOLS-4805) Memory leak in STREAM mode (# PointInTimeTriggers growing)
by Jesse White (Jira)
Jesse White created DROOLS-4805:
-----------------------------------
Summary: Memory leak in STREAM mode (# PointInTimeTriggers growing)
Key: DROOLS-4805
URL: https://issues.jboss.org/browse/DROOLS-4805
Project: Drools
Issue Type: Bug
Affects Versions: 7.29.0.Final
Reporter: Jesse White
Assignee: Mario Fusco
Attachments: image-2019-11-25-10-31-07-281.png
When running our engine in STREAM mode, we notice a number of Drools internal object references increasing time even though the fact count stays relatively constant.
jmap -histo <pid> shows:
{noformat}
num #instances #bytes class name
----------------------------------------------
1: 17478466 1258449552 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask
2: 17475174 699006960 org.drools.core.time.impl.JDKTimerService$JDKJobHandle
3: 17762331 568394592 java.util.concurrent.ConcurrentHashMap$Node
4: 17475174 559205568 org.drools.core.rule.SlidingTimeWindow$BehaviorJobContext
5: 17475174 559205568 org.drools.core.time.impl.DefaultTimerJobInstance
6: 8596776 551411680 [C
7: 18898675 453568200 java.lang.Long
8: 17475174 419404176 org.drools.core.time.SelfRemovalJobContext
9: 17475174 279602784 org.drools.core.time.SelfRemovalJob
10: 17475174 279602784 org.drools.core.time.impl.PointInTimeTrigger
11: 9263698 222328752 java.lang.String
12: 4584671 146709472 java.util.HashMap$Node
13: 246658 138804176 [B
{noformat}
These number continue to increase over time until the system OOMs.
Graph for # of facts in the session looks like:
!image-2019-11-25-10-31-07-281.png|thumbnail!
The engine is fairly busy - we're constantly adding and removing facts.
Our rules are available here:
https://github.com/OpenNMS/opennms/blob/opennms-25.0.0-1/opennms-base-ass...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[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:
------------------------------------
[~mstefank] that's correct. Due to that issue, health checks were only able to read config from en vars and system properties.
> 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, 5 months
[JBoss JIRA] (WFCORE-2147) Impossible to use environment variables or system properties in permissions.xml
by Yeray Borges (Jira)
[ https://issues.jboss.org/browse/WFCORE-2147?page=com.atlassian.jira.plugi... ]
Yeray Borges commented on WFCORE-2147:
--------------------------------------
Hello [~a13397]
Yes, sure, WildFly code is opensource, and you can build and patch any version by yourself. Keep in mind the changes proposed on this pull request have not been approved yet so that they could change. Sadly there are other priorities above this issue that prevents this one continue moving on, so the pull request is in the queue, pending for review.
Anyway, if you want to patch a previous server version, you can do it. The changes proposed to fix this issue are split into two projects: [wildfly|https://github.com/wildfly/wildfly] and [wildfly-core|https://github.com/wildfly/wildfly-core].
Backporting the changes could be easy, but the code changes from one release to another so, maybe you could find conflicts that you will need to resolve by yourself manually, in general terms, you should understand a bit the changes proposed and how the issue is fixed.
What you would need to do is to pick up from GitHub the tag of the Wildfly release you want to patch. You will need to inspect the pom.xml to see which wildfly-core version is used in that WildFly release. Once you have this information, get the wildfly-core tag for that version and apply the changes incorporated on this [PR|https://github.com/wildfly/wildfly-core/pull/4002] in the wildfly-core project and build it locally on your computer. You will end up with a patched wildfly-core version on your local maven repository.
Once you have patched wildfly-core project, you will need to apply the changes of this [PR|https://github.com/wildfly/wildfly/pull/12768] on the WildFly project you checked out before and build it. Then you will have a WildFly server patched. If you build the server using -Drelease option, you will find under $WFLY_SOURCE_HOME/dist/target/ a zip file which is the version built by you manually.
> Impossible to use environment variables or system properties in permissions.xml
> -------------------------------------------------------------------------------
>
> Key: WFCORE-2147
> URL: https://issues.jboss.org/browse/WFCORE-2147
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Reporter: Adrian Boangiu
> Assignee: Yeray Borges
> Priority: Major
>
> Without this feature it is impossible to migrate "variable" Java file permissions such as:
> {noformat}
> permission java.io.FilePermission "${java.io.tmpdir}","read";
> permission java.io.FilePermission "${jboss.home.dir}${/}bin${/}javamelody${/}-","read,write,delete";
> permission java.io.FilePermission "${app.home.dir}${/}log${/}-","read,write,delete";
> {noformat}
> that were defined in Java policy file in previous verions of JBoss.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFLY-12811) Can not inject MP Config property to a HealthCheck bean
by Martin Stefanko (Jira)
[ https://issues.jboss.org/browse/WFLY-12811?page=com.atlassian.jira.plugin... ]
Martin Stefanko commented on WFLY-12811:
----------------------------------------
[~jmesnil] I think I ran into the same issue. It doesn't work with {{microprofile-config.properties}} but it works with system properties and environment variables.
> 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, 5 months