May 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2477) Reintroduce support for configuring a JChannel via URL

by Thomas Darimont (Jira)

[ https://issues.redhat.com/browse/JGRP-2477?page=com.atlassian.jira.plugin... ] Thomas Darimont updated JGRP-2477: ---------------------------------- Git Pull Request: https://github.com/belaban/JGroups/pull/494 (was: https://github.com/belaban/JGroups/pull/491) > Reintroduce support for configuring a JChannel via URL > ------------------------------------------------------ > > Key: JGRP-2477 > URL: https://issues.redhat.com/browse/JGRP-2477 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 4.2.3, 5.0.0.Beta1 > Reporter: Thomas Darimont > Assignee: Bela Ban > Priority: Minor > > Infinispan 9.4.x (9.4.19) uses a URL to load the JGroups configuration from the infinispan configuration. > When an external jgroups stack configuration file is used: > See: "Using an external JGroups file" in https://infinispan.org/docs/9.4.x/user_guide/user_guide.html#using_an_ext... > When creating the JGroups stack, infinispan uses the constructor in org.jgroups.JChannel#JChannel(...) which takes a URL as parameter. > See: https://github.com/infinispan/infinispan/blob/9.4.x/core/src/main/java/or... > However this constructor is only present in versions up-to including 4.0.22 https://github.com/belaban/JGroups/blob/4.0.22/src/org/jgroups/JChannel.j... > and was removed in later versions. > Because of this users of infinispan 9.4.x, who use the "Using an external JGroups file" configuration approach cannot upgrade to new JGroups versions, like 4.2.3. > In order to ease upgrading to newer JGroups versions with Infinispan 9.4.x. it would be very kind if the constructor with the URL parameter > could be added back. > I created a pull request to add the constructor {org.jgroups.JChannel#JChannel(java.net.URL)} to master, which can also be cherry-picked for the 4.x branch. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2477) Reintroduce support for configuring a JChannel via URL

by Thomas Darimont (Jira)

[ https://issues.redhat.com/browse/JGRP-2477?page=com.atlassian.jira.plugin... ] Thomas Darimont commented on JGRP-2477: --------------------------------------- I sent a new PR - this should apply cleanly against 4.x. https://github.com/belaban/JGroups/pull/494 Cheers, Thomas > Reintroduce support for configuring a JChannel via URL > ------------------------------------------------------ > > Key: JGRP-2477 > URL: https://issues.redhat.com/browse/JGRP-2477 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 4.2.3, 5.0.0.Beta1 > Reporter: Thomas Darimont > Assignee: Bela Ban > Priority: Minor > > Infinispan 9.4.x (9.4.19) uses a URL to load the JGroups configuration from the infinispan configuration. > When an external jgroups stack configuration file is used: > See: "Using an external JGroups file" in https://infinispan.org/docs/9.4.x/user_guide/user_guide.html#using_an_ext... > When creating the JGroups stack, infinispan uses the constructor in org.jgroups.JChannel#JChannel(...) which takes a URL as parameter. > See: https://github.com/infinispan/infinispan/blob/9.4.x/core/src/main/java/or... > However this constructor is only present in versions up-to including 4.0.22 https://github.com/belaban/JGroups/blob/4.0.22/src/org/jgroups/JChannel.j... > and was removed in later versions. > Because of this users of infinispan 9.4.x, who use the "Using an external JGroups file" configuration approach cannot upgrade to new JGroups versions, like 4.2.3. > In order to ease upgrading to newer JGroups versions with Infinispan 9.4.x. it would be very kind if the constructor with the URL parameter > could be added back. > I created a pull request to add the constructor {org.jgroups.JChannel#JChannel(java.net.URL)} to master, which can also be cherry-picked for the 4.x branch. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5010) DMN DT Analysis consolidate FIRST policy messages

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-5010?page=com.atlassian.jira.plug... ] Matteo Mortari updated DROOLS-5010: ----------------------------------- Sprint: 2020 Week 19-21 (from May 4) (was: 2020 Week 22-24 (from May 25)) > DMN DT Analysis consolidate FIRST policy messages > ------------------------------------------------- > > Key: DROOLS-5010 > URL: https://issues.redhat.com/browse/DROOLS-5010 > Project: Drools > Issue Type: Enhancement > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > > evaluate consolidation of to merge messages about FIRST being non-best-practice and violating 1NF -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2477) Reintroduce support for configuring a JChannel via URL

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2477?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-2477: -------------------------------- The constructor was removed because I wanted to trim the fat from JGroups and an application can execute {{new JChannel (new FileInputStream(url))}} (or similar) easily. Your PR doesn't apply cleanly on 4.x, can you submit a PR for 4.x only? Thanks for the reproducer! Cheers, > Reintroduce support for configuring a JChannel via URL > ------------------------------------------------------ > > Key: JGRP-2477 > URL: https://issues.redhat.com/browse/JGRP-2477 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 4.2.3, 5.0.0.Beta1 > Reporter: Thomas Darimont > Assignee: Bela Ban > Priority: Minor > > Infinispan 9.4.x (9.4.19) uses a URL to load the JGroups configuration from the infinispan configuration. > When an external jgroups stack configuration file is used: > See: "Using an external JGroups file" in https://infinispan.org/docs/9.4.x/user_guide/user_guide.html#using_an_ext... > When creating the JGroups stack, infinispan uses the constructor in org.jgroups.JChannel#JChannel(...) which takes a URL as parameter. > See: https://github.com/infinispan/infinispan/blob/9.4.x/core/src/main/java/or... > However this constructor is only present in versions up-to including 4.0.22 https://github.com/belaban/JGroups/blob/4.0.22/src/org/jgroups/JChannel.j... > and was removed in later versions. > Because of this users of infinispan 9.4.x, who use the "Using an external JGroups file" configuration approach cannot upgrade to new JGroups versions, like 4.2.3. > In order to ease upgrading to newer JGroups versions with Infinispan 9.4.x. it would be very kind if the constructor with the URL parameter > could be added back. > I created a pull request to add the constructor {org.jgroups.JChannel#JChannel(java.net.URL)} to master, which can also be cherry-picked for the 4.x branch. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2477) Reintroduce support for configuring a JChannel via URL

by Thomas Darimont (Jira)

[ https://issues.redhat.com/browse/JGRP-2477?page=com.atlassian.jira.plugin... ] Thomas Darimont commented on JGRP-2477: --------------------------------------- Hi Bela, thanks for the quick response! Yes I'm sure, here is a reproducer: https://github.com/thomasdarimont/JGRP-2477-Reproducer-jgroupxml-via-url May I ask why the ctor was removed in 5.x? I did not try whether 5.x is compatible with Infinispan 9.4.x but I can give it a try. > Reintroduce support for configuring a JChannel via URL > ------------------------------------------------------ > > Key: JGRP-2477 > URL: https://issues.redhat.com/browse/JGRP-2477 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 4.2.3, 5.0.0.Beta1 > Reporter: Thomas Darimont > Assignee: Bela Ban > Priority: Minor > > Infinispan 9.4.x (9.4.19) uses a URL to load the JGroups configuration from the infinispan configuration. > When an external jgroups stack configuration file is used: > See: "Using an external JGroups file" in https://infinispan.org/docs/9.4.x/user_guide/user_guide.html#using_an_ext... > When creating the JGroups stack, infinispan uses the constructor in org.jgroups.JChannel#JChannel(...) which takes a URL as parameter. > See: https://github.com/infinispan/infinispan/blob/9.4.x/core/src/main/java/or... > However this constructor is only present in versions up-to including 4.0.22 https://github.com/belaban/JGroups/blob/4.0.22/src/org/jgroups/JChannel.j... > and was removed in later versions. > Because of this users of infinispan 9.4.x, who use the "Using an external JGroups file" configuration approach cannot upgrade to new JGroups versions, like 4.2.3. > In order to ease upgrading to newer JGroups versions with Infinispan 9.4.x. it would be very kind if the constructor with the URL parameter > could be added back. > I created a pull request to add the constructor {org.jgroups.JChannel#JChannel(java.net.URL)} to master, which can also be cherry-picked for the 4.x branch. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2477) Reintroduce support for configuring a JChannel via URL

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2477?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-2477: -------------------------------- Hi Thomas are you sure that a regular file (e.g. "jgroups.xml") is not found on the classpath, does it need to be a URL? If so, then I'll accept a PR for the 4.x branch but not for 5, as this ctor was removed for a reason. I guess you won't be able to use JGroups 5.x in Infinispan 9.x anyway. > Reintroduce support for configuring a JChannel via URL > ------------------------------------------------------ > > Key: JGRP-2477 > URL: https://issues.redhat.com/browse/JGRP-2477 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 4.2.3, 5.0.0.Beta1 > Reporter: Thomas Darimont > Assignee: Bela Ban > Priority: Minor > > Infinispan 9.4.x (9.4.19) uses a URL to load the JGroups configuration from the infinispan configuration. > When an external jgroups stack configuration file is used: > See: "Using an external JGroups file" in https://infinispan.org/docs/9.4.x/user_guide/user_guide.html#using_an_ext... > When creating the JGroups stack, infinispan uses the constructor in org.jgroups.JChannel#JChannel(...) which takes a URL as parameter. > See: https://github.com/infinispan/infinispan/blob/9.4.x/core/src/main/java/or... > However this constructor is only present in versions up-to including 4.0.22 https://github.com/belaban/JGroups/blob/4.0.22/src/org/jgroups/JChannel.j... > and was removed in later versions. > Because of this users of infinispan 9.4.x, who use the "Using an external JGroups file" configuration approach cannot upgrade to new JGroups versions, like 4.2.3. > In order to ease upgrading to newer JGroups versions with Infinispan 9.4.x. it would be very kind if the constructor with the URL parameter > could be added back. > I created a pull request to add the constructor {org.jgroups.JChannel#JChannel(java.net.URL)} to master, which can also be cherry-picked for the 4.x branch. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13444) Observing High CPU in EPollArrayWrapper.epollCtl default I/O thread

by Srinivas ev (Jira)

[ https://issues.redhat.com/browse/WFLY-13444?page=com.atlassian.jira.plugi... ] Srinivas ev commented on WFLY-13444: ------------------------------------ Hi [~flavia.rainone], any update on this JIRA. Can you please have a look, as this is blocking one of our delivery. > Observing High CPU in EPollArrayWrapper.epollCtl default I/O thread > ------------------------------------------------------------------- > > Key: WFLY-13444 > URL: https://issues.redhat.com/browse/WFLY-13444 > Project: WildFly > Issue Type: Bug > Components: Remoting > Affects Versions: 10.1.0.Final > Reporter: Srinivas ev > Assignee: Flavia Rainone > Priority: Major > Attachments: IO thread memory.PNG, IO thread.PNG, Thread consuming high CPU.PNG, ThreadDump1set.zip, ThreadDump2set.zip, default IO thread 73.PNG, default io consuming snapshot.PNG, default io consuming.PNG, stack trace from snapshot.PNG, stack trace in thread dump.PNG, threaddump-1589514505334.tdump, top command output.PNG > > > Facing high CPU by one of the default I/O thread In Wildfly 10.1.0 Final. Looks none of our application component thread is consuming. > Can somebody check what is triggering this issue? I attached the thread stack to this Jira. This is blocking our releases. When the CPU cores are high in number, multiple default I/O threads will kick in consuming the CPU in 90~100% range continuously. > Wildfly 10.1.0 Final > Java - > openjdk version "1.8.0_232" > OpenJDK Runtime Environment (build 1.8.0_232-b09) > OpenJDK 64-Bit Server VM (build 25.232-b09, mixed mode > --------------------------------------------------------------------------------------------------- > at java.lang.Throwable.fillInStackTrace(Native Method) > at java.lang.Throwable.fillInStackTrace(Throwable.java:784) > at java.lang.Throwable.<init>(Throwable.java:251) > at java.lang.Exception.<init>(Exception.java:54) > at java.io.IOException.<init>(IOException.java:47) > at java.nio.channels.ClosedChannelException.<init>(ClosedChannelException.java:52) > at org.xnio.ssl.JsseStreamConduit.write(JsseStreamConduit.java:1022) > at org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150) > at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:385) > at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:372) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65) > at org.xnio.ssl.JsseStreamConduit.run(JsseStreamConduit.java:393) > at org.xnio.ssl.JsseStreamConduit.readReady(JsseStreamConduit.java:547) > at org.xnio.ssl.JsseStreamConduit$2.readReady(JsseStreamConduit.java:319) > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) > ------------------------------------------------------------------------------------------- > at sun.nio.ch.EPollArrayWrapper.epollCtl(Native Method) > at sun.nio.ch.EPollArrayWrapper.updateRegistrations(EPollArrayWrapper.java:299) > at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:268) > at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93) > at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86) > at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) > at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:515) > ----------------------------------------------------------------------------------- -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5329) Review externalizing lambda failure case

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5329?page=com.atlassian.jira.plug... ] Toshiya Kobayashi updated DROOLS-5329: -------------------------------------- Sprint: 2020 Week 19-21 (from May 4) > Review externalizing lambda failure case > ---------------------------------------- > > Key: DROOLS-5329 > URL: https://issues.redhat.com/browse/DROOLS-5329 > Project: Drools > Issue Type: Task > Components: executable model > Affects Versions: 7.37.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > > In CompilerTest#testStringValueOf, there is a case where MaterializedLambdaPredicate is not created. > {code:java} > public static org.drools.model.Rule rule_R() { > final org.drools.model.Variable<java.lang.Integer> var_GENERATED_$pattern_Integer$1$ = D.declarationOf(java.lang.Integer.class, > DomainClassesMetadata81A66AD685F7689036AAA5128956C14B.java_lang_Integer_Metadata_INSTANCE, > "GENERATED_$pattern_Integer$1$"); > final org.drools.model.Variable<Integer> var_$i = D.declarationOf(Integer.class, "$i"); > final org.drools.model.Variable<org.drools.modelcompiler.domain.Person> var_GENERATED_$pattern_Person$1$ = D.declarationOf(org.drools.modelcompiler.domain.Person.class, > DomainClassesMetadata81A66AD685F7689036AAA5128956C14B.org_drools_modelcompiler_domain_Person_Metadata_INSTANCE, > "GENERATED_$pattern_Person$1$"); > org.drools.model.Rule rule = D.rule("R").build(D.pattern(var_GENERATED_$pattern_Integer$1$).bind(var_$i, (java.lang.Integer _this) -> _this.intValue()), > D.pattern(var_GENERATED_$pattern_Person$1$).expr("476633DA7C4638FC84A32859E0C843E6", > var_$i, > (_this, $i) -> org.drools.modelcompiler.util.EvaluationUtil.areNullSafeEquals(_this.getName(), > (String.valueOf($i))), > D.reactOn("name")), > D.on(var_$i).execute(defaultpkg.P1D.LambdaConsequence1D5F4C5CA006007B1D3974ED5A5A05B6.INSTANCE)); > return rule; > } > {code} > See > {code:java} > expr("476633DA7C4638FC84A32859E0C843E6", > var_$i, > (_this, $i) -> org.drools.modelcompiler.util.EvaluationUtil.areNullSafeEquals(_this.getName(), > (String.valueOf($i))) > {code} > It throws DoNotConvertLambdaException in ExecModelLambdaPostProcessor. > {code:java} > private void extractLambdaFromMethodCall(MethodCallExpr methodCallExpr, Supplier<MaterializedLambda> lambdaExtractor) { > methodCallExpr.getArguments().forEach(a -> { > if (a.isLambdaExpr()) { > LambdaExpr lambdaExpr = a.asLambdaExpr(); > try { > CreatedClass aClass = lambdaExtractor.get().create(lambdaExpr.toString(), imports, staticImports); > lambdaClasses.put(aClass.getClassNameWithPackage(), aClass); > ClassOrInterfaceType type = StaticJavaParser.parseClassOrInterfaceType(aClass.getClassNameWithPackage()); > a.replace(lambdaInstance(type)); > } catch(DoNotConvertLambdaException e) { > logger.debug("Cannot externalize lambdas {}", e.getMessage()); > } > } > }); > } > {code} > Review if it's something can be fixed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5328) Externalize lambda for binding variable

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5328?page=com.atlassian.jira.plug... ] Toshiya Kobayashi updated DROOLS-5328: -------------------------------------- Sprint: 2020 Week 19-21 (from May 4) > Externalize lambda for binding variable > --------------------------------------- > > Key: DROOLS-5328 > URL: https://issues.redhat.com/browse/DROOLS-5328 > Project: Drools > Issue Type: Task > Components: executable model > Affects Versions: 7.37.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > > When "drools.externaliseCanonicalModelLambda" is enabled, Predicate, Extractor and Consequence are externalized. But still lambda for binding variable exists: > e.g. CompilerTest#testStringValueOf) > {code:java} > public static org.drools.model.Rule rule_R() { > final org.drools.model.Variable<java.lang.Integer> var_GENERATED_$pattern_Integer$1$ = D.declarationOf(java.lang.Integer.class, > DomainClassesMetadata81A66AD685F7689036AAA5128956C14B.java_lang_Integer_Metadata_INSTANCE, > "GENERATED_$pattern_Integer$1$"); > final org.drools.model.Variable<Integer> var_$i = D.declarationOf(Integer.class, "$i"); > final org.drools.model.Variable<org.drools.modelcompiler.domain.Person> var_GENERATED_$pattern_Person$1$ = D.declarationOf(org.drools.modelcompiler.domain.Person.class, > DomainClassesMetadata81A66AD685F7689036AAA5128956C14B.org_drools_modelcompiler_domain_Person_Metadata_INSTANCE, > "GENERATED_$pattern_Person$1$"); > org.drools.model.Rule rule = D.rule("R").build(D.pattern(var_GENERATED_$pattern_Integer$1$).bind(var_$i, (java.lang.Integer _this) -> _this.intValue()), > D.pattern(var_GENERATED_$pattern_Person$1$).expr("476633DA7C4638FC84A32859E0C843E6", > var_$i, > (_this, $i) -> org.drools.modelcompiler.util.EvaluationUtil.areNullSafeEquals(_this.getName(), > (String.valueOf($i))), > D.reactOn("name")), > D.on(var_$i).execute(defaultpkg.P1D.LambdaConsequence1D5F4C5CA006007B1D3974ED5A5A05B6.INSTANCE)); > return rule; > } > {code} > See > {code:java} > bind(var_$i, (java.lang.Integer _this) -> _this.intValue()) > {code} > Function1$Impl is instantiated by PatternDSL$PatternDefImpl.bind() > Note: The above example shows another lambda > {code:java} > expr("476633DA7C4638FC84A32859E0C843E6", > var_$i, > (_this, $i) -> org.drools.modelcompiler.util.EvaluationUtil.areNullSafeEquals(_this.getName(), > (String.valueOf($i))) > {code} > This will be addressed by another JIRA. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5342) Default value of "drools.lambda.introspector.cache.size" for externalized lambda

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5342?page=com.atlassian.jira.plug... ] Toshiya Kobayashi reassigned DROOLS-5342: ----------------------------------------- Assignee: Toshiya Kobayashi (was: Luca Molteni) > Default value of "drools.lambda.introspector.cache.size" for externalized lambda > -------------------------------------------------------------------------------- > > Key: DROOLS-5342 > URL: https://issues.redhat.com/browse/DROOLS-5342 > Project: Drools > Issue Type: Task > Components: executable model > Affects Versions: 7.37.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > > Regarding the cache size default value of LambdaIntrospector.methodFingerprintsMap, > If "drools.externaliseCanonicalModelLambda" option is not enabled, the cache is frequently used so it will not likely retain old classloaders. So the default value '32' would be fine. > If "drools.externaliseCanonicalModelLambda" option is enabled, the cache is used in rare occasions: > A) Lambda for binding variable (DROOLS-5328) > B) Lambda which ExecModelLambdaPostProcessor failed to externalize (DROOLS-5329) > So one build may use only a few entries in a cache Map. Then, the cache eventually may retain several old classloaders after multiple builds. Generally, the classloader leak issue is prioritized over build time performance benefit so '0' is the good default value when externaliseCanonicalModelLambda is enabled. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2020