[JBoss JIRA] (JGRP-2155) Weight loss program
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2155?page=com.atlassian.jira.plugin... ]
Bela Ban closed JGRP-2155.
--------------------------
Resolution: Out of Date
> Weight loss program
> -------------------
>
> Key: JGRP-2155
> URL: https://issues.redhat.com/browse/JGRP-2155
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Yves Cuillerdier
> Assignee: Bela Ban
> Priority: Major
>
> JGroups jar is quite large and it is sometime desirable to shrink it some way.
> Currently the jar contains unnecessary class (demo, test and perf) and it is not possible to keep the only needed protocols using tools like Proguard (it's like having a server with all ports open).
> My suggestions are:
> h2. Move JGroups' side class
> Demo: Move the {{demo}} package to a maven module.
> Test and perf: Move the test package to the maven test source and generate test-source jars.
> Note that the {{MPerf$MPerfHeader}} must be removed from the {{jg-magic-map.xml}} file.
> h2.
> h2. Make JGroups Proguard compatible
> A classical way to shrink and optimize project is to use the *{{Proguard }}*tools.
> This tool cannot be used for JGroups mainly because of the two configuration files {{jg-magic-map.xml}} and {{jg-protocol-ids.xml}}.
> These two files contain all class files for all possible protocols, even those that are not required by the selected configuration for the project (for example, using {{fast.xml}} does not require {{ENCRYPT}}, {{TUNNEL}} and many more.)
> The problem is that Proguard could not understand these two files and removes all class because there is no entry points.
> One way to solve this may be to create Annotation (for example {{@MagicMap}} and {{@ProtocolIds}}) and remove the two files. These annotations could be searched by the initialization process in the class maintained by the Proguard tools. This should not affect the loading time as all relevant class are in the same package {{org.jgroups.protocols}}.
> This is not enough because some fields are initialized by reflection using hard coded name (for example "{{bind_add}}"). For such fields we need an Annotation like {{@KeepField}} to tell Proguard not to optimize, remove or rename the fields. For example:
> -keepclassmembers class * { @jgroups.annotations.KeepField <fields>; }
> This Annotation may also be used for class where instance are created by reflection (like {{GMS.GmsHeader}}).
> Last we need to specify the entry points for the project configuration else Proguard will still remove all. The xml configuration files (like {{fast.xml}}) should be kept to provide the protocols configuration.
> This is a matter of the Proguard configuration file. For example in a project using{{ fast.xml}}, we should have:
> -keep public class org.jgroups.protocols.UDP.** { *; }
> -keep public class org.jgroups.protocols.PING.** { *; }
> -keep public class org.jgroups.protocols.MERGE3.** { *; }
> -keep public class org.jgroups.protocols.FD_SOCK.** { *; }
> -keep public class org.jgroups.protocols.FD_ALL.** { *; }
> -keep public class org.jgroups.protocols.VERIFY_SUSPECT.** { *; }
> -keep public class org.jgroups.protocols.BARRIER.** { *; }
> -keep public class org.jgroups.protocols.pbcast.NAKACK2.** { *; }
> ... etc
> My 2 cents.
> Yves
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (JGRP-2040) Seeing a OOM in JGroup 3.4
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2040?page=com.atlassian.jira.plugin... ]
Bela Ban closed JGRP-2040.
--------------------------
Resolution: Out of Date
This issue was fixed in a later version (forgot the Jira though...)
> Seeing a OOM in JGroup 3.4
> --------------------------
>
> Key: JGRP-2040
> URL: https://issues.redhat.com/browse/JGRP-2040
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4
> Environment: Linux Operating System
> Reporter: Kshitiz Saxena
> Assignee: Bela Ban
> Priority: Major
>
> We are seeing an OOM in our application where thread dump points to JGroup.
> We see the below in thread dumps,
> 3XEHSTTYPE 07:33:24:346241000 GMT j9vm.294 - >setCurrentException index=11 constructorIndex=0 detailMessage=0000000000F61678
> 3XEHSTTYPE 07:33:24:346183000 GMT j9mm.126 - at 0000000050F8CD60 java/lang/Thread.run()V, jit 00007FCF323EA580, pc 00007FCF489E0A36
> 3XEHSTTYPE 07:33:24:346179000 GMT j9mm.126 - at 0000000053644748 *org/jgroups/blocks/TCPConnectionMap$TCPConnection$Receiver.run()*V, jit 0000000000000000, pc 00007FCF3354D334
> 3XEHSTTYPE 07:33:24:346175000 GMT j9mm.101 - J9AllocateIndexableObject() returning NULL! *1650814064 bytes* requested for object of class 0000000050F79700 from memory space 'Generational' id=00007FCF440427C0
> In the thread dump we also see
> WARNING : OutOfMemoryError possibly caused by 1650814064 bytes requested for object of class 0000000050F79700 from memory space 'Generational' id=00007FCF440427C0
> Java Heap Information
> -Xmx (Maximum Java heap size) : 1280m
> -Xms (Initial Java heap size) : 640m
> -Xss (Maximum stack size for Java threads) : 256k
> Total Java heap size: 1.25 GB
> Used Java heap size: 174.27 MB
> Free Java heap size: 1.08 GB
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (JGRP-2095) FILE_PING rewrites files too often
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2095?page=com.atlassian.jira.plugin... ]
Bela Ban closed JGRP-2095.
--------------------------
Resolution: Out of Date
Dropped the ball on this one :(.
> FILE_PING rewrites files too often
> ----------------------------------
>
> Key: JGRP-2095
> URL: https://issues.redhat.com/browse/JGRP-2095
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Reporter: Dennis Reed
> Assignee: Bela Ban
> Priority: Major
>
> FILE_PING.fetchClusterMembers writes its own data to file on every call.
> If there is an issue finding a cluster member's address, fetchClusterMembers can be called very frequently by TP's GET_PHYSICAL_ADDRESS calls.
> This can cause problems because while that file is being (unnecessarily) overwritten, any readers will see an empty or corrupt file. If it's bad enough JGRP-1448 is not sufficient to handle it, and readers will end up thinking the file is stale and delete it (even while it's still in progress of being written). That missing file can then cascade the problem, with other nodes not being able to find this member's address, and triggering the same problem again.
> There is already a scheduled task to rewrite the file occasionally, so rewriting it on every fetchClusterMembers call is not needed.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (JGRP-2500) Throttle "no route to" log messages
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2500?page=com.atlassian.jira.plugin... ]
Bela Ban resolved JGRP-2500.
----------------------------
Resolution: Done
> Throttle "no route to" log messages
> -----------------------------------
>
> Key: JGRP-2500
> URL: https://issues.redhat.com/browse/JGRP-2500
> Project: JGroups
> Issue Type: Bug
> Reporter: Diego Lovison
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.2.6, 5.0.4
>
>
> When doing some put in a cache that has a backup site, if the backup site is not available, a lot of messages will be printed in logs. I think that we can count and print every 100 or 1000
> Current state:
> {noformat}
> [1;31m21:42:38,542 ERROR (jgroups-146,edg-perf05-62972) [org.jgroups.protocols.relay.RELAY2] edg-perf05-62972: no route to site01: dropping message[m
> [1;31m21:42:38,542 ERROR (irac-sender-thread-edg-perf05-62972) [org.jgroups.protocols.relay.RELAY2] edg-perf05-62972: no route to site01: dropping message[m
> {noformat}
> Desired state: dropping X messages
> {noformat}
> [1;31m21:42:38,542 ERROR (irac-sender-thread-edg-perf05-62972) [org.jgroups.protocols.relay.RELAY2] edg-perf05-62972: no route to site01: dropping X messages[m
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (JGRP-2500) Throttle "no route to" log messages
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2500?page=com.atlassian.jira.plugin... ]
Bela Ban edited comment on JGRP-2500 at 9/2/20 5:37 AM:
--------------------------------------------------------
OK, using SuppressLog. The errors now looks like
{noformat}
JGRP000290: sfc1:sfc: no route to site lon: dropping message (15 identical messages for site lon in the last 5062 ms) {noformat}
The interval can be set via {{suppress_time_no_route_errors}}.
was (Author: belaban):
OK, using SuppressLog. The errors now looks like
{noformat}
JGRP000290: sfc1:sfc: no route to site lon: dropping message (15 identical messages for site lon in the last 5062 ms) {noformat}
> Throttle "no route to" log messages
> -----------------------------------
>
> Key: JGRP-2500
> URL: https://issues.redhat.com/browse/JGRP-2500
> Project: JGroups
> Issue Type: Bug
> Reporter: Diego Lovison
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.2.6, 5.0.4
>
>
> When doing some put in a cache that has a backup site, if the backup site is not available, a lot of messages will be printed in logs. I think that we can count and print every 100 or 1000
> Current state:
> {noformat}
> [1;31m21:42:38,542 ERROR (jgroups-146,edg-perf05-62972) [org.jgroups.protocols.relay.RELAY2] edg-perf05-62972: no route to site01: dropping message[m
> [1;31m21:42:38,542 ERROR (irac-sender-thread-edg-perf05-62972) [org.jgroups.protocols.relay.RELAY2] edg-perf05-62972: no route to site01: dropping message[m
> {noformat}
> Desired state: dropping X messages
> {noformat}
> [1;31m21:42:38,542 ERROR (irac-sender-thread-edg-perf05-62972) [org.jgroups.protocols.relay.RELAY2] edg-perf05-62972: no route to site01: dropping X messages[m
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (JGRP-2500) Throttle "no route to" log messages
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2500?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2500:
--------------------------------
OK, using SuppressLog. The errors now looks like
{noformat}
JGRP000290: sfc1:sfc: no route to site lon: dropping message (15 identical messages for site lon in the last 5062 ms) {noformat}
> Throttle "no route to" log messages
> -----------------------------------
>
> Key: JGRP-2500
> URL: https://issues.redhat.com/browse/JGRP-2500
> Project: JGroups
> Issue Type: Bug
> Reporter: Diego Lovison
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.2.6, 5.0.4
>
>
> When doing some put in a cache that has a backup site, if the backup site is not available, a lot of messages will be printed in logs. I think that we can count and print every 100 or 1000
> Current state:
> {noformat}
> [1;31m21:42:38,542 ERROR (jgroups-146,edg-perf05-62972) [org.jgroups.protocols.relay.RELAY2] edg-perf05-62972: no route to site01: dropping message[m
> [1;31m21:42:38,542 ERROR (irac-sender-thread-edg-perf05-62972) [org.jgroups.protocols.relay.RELAY2] edg-perf05-62972: no route to site01: dropping message[m
> {noformat}
> Desired state: dropping X messages
> {noformat}
> [1;31m21:42:38,542 ERROR (irac-sender-thread-edg-perf05-62972) [org.jgroups.protocols.relay.RELAY2] edg-perf05-62972: no route to site01: dropping X messages[m
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (DROOLS-5609) Cannot use as parameter of a function the result of another function receiving a parameter of its own
by Luca Molteni (Jira)
[ https://issues.redhat.com/browse/DROOLS-5609?page=com.atlassian.jira.plug... ]
Luca Molteni updated DROOLS-5609:
---------------------------------
Sprint: 2020 Week 34-36 (from Aug 17)
> Cannot use as parameter of a function the result of another function receiving a parameter of its own
> -----------------------------------------------------------------------------------------------------
>
> Key: DROOLS-5609
> URL: https://issues.redhat.com/browse/DROOLS-5609
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.42.0.Final
> Reporter: Ciprian Chiru
> Assignee: Luca Molteni
> Priority: Major
>
> Given the following rule:
>
> {code:java}
> import java.util.*;
> global java.util.Set controlSet;
> global org.example.drools.service.DummyService dummyService;
> rule "will execute per each Measurement having ID color"
> no-loop
> when
> Measurement( id == "color", $colorVal : val )
> String() from dummyService.dummy(dummyService.dummy($colorVal))
> then
> controlSet.add($colorVal);
> end{code}
>
> The compilation fails with:
> {code:java}
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile (default-compile-1) on project rules: Compilation failure
> [ERROR] .../target/generated-sources/drools-model-compiler/main/java/rules/Rules38bbab4141b64289855d5e28d5f95ca6RuleMethods0.java:[24,111] no suitable method found for from(org.drools.model.Global<org.example.drools.service.DummyService>,org.drools.model.Global<org.example.drools.service.DummyService>,org.drools.model.Variable<java.lang.String>,rules.P4C.LambdaExtractor4CA52645EC5319D0363A23796D4739AE)
> [ERROR] method org.drools.model.DSL.<T>from(T) is not applicable
> [ERROR] (cannot infer type-variable(s) T
> [ERROR] (actual and formal argument lists differ in length))
> [ERROR] method org.drools.model.DSL.<T>from(org.drools.model.Variable<T>) is not applicable
> [ERROR] (cannot infer type-variable(s) T
> [ERROR] (actual and formal argument lists differ in length))
> [ERROR] method org.drools.model.DSL.<T>from(org.drools.model.functions.Function0<T>) is not applicable
> [ERROR] (cannot infer type-variable(s) T
> [ERROR] (actual and formal argument lists differ in length))
> [ERROR] method org.drools.model.DSL.<T>from(org.drools.model.Variable<T>,org.drools.model.functions.Function1<T,?>) is not applicable
> [ERROR] (cannot infer type-variable(s) T
> [ERROR] (actual and formal argument lists differ in length))
> [ERROR] method org.drools.model.DSL.<A,B>from(org.drools.model.Variable<A>,org.drools.model.Variable<B>,org.drools.model.functions.Function2<A,B,?>) is not applicable
> [ERROR] (cannot infer type-variable(s) A,B
> [ERROR] (actual and formal argument lists differ in length))
> [ERROR] method org.drools.model.DSL.<A,B,C>from(org.drools.model.Variable<A>,org.drools.model.Variable<B>,org.drools.model.Variable<C>,org.drools.model.functions.Function3<A,B,C,?>) is not applicable
> [ERROR] (cannot infer type-variable(s) A,B,C
> [ERROR] (argument mismatch; rules.P4C.LambdaExtractor4CA52645EC5319D0363A23796D4739AE cannot be converted to org.drools.model.functions.Function3<A,B,C,?>))
> [ERROR] method org.drools.model.DSL.<A,B,C,D>from(org.drools.model.Variable<A>,org.drools.model.Variable<B>,org.drools.model.Variable<C>,org.drools.model.Variable<D>,org.drools.model.functions.Function4<A,B,C,D,?>) is not applicable
> [ERROR] (cannot infer type-variable(s) A,B,C,D
> [ERROR] (actual and formal argument lists differ in length)){code}
> This error can be reproduced with version _7.43.0-SNAPSHOT_
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (DROOLS-5608) Cannot use method chaining as source for facts
by Luca Molteni (Jira)
[ https://issues.redhat.com/browse/DROOLS-5608?page=com.atlassian.jira.plug... ]
Luca Molteni updated DROOLS-5608:
---------------------------------
Sprint: 2020 Week 34-36 (from Aug 17)
> Cannot use method chaining as source for facts
> ----------------------------------------------
>
> Key: DROOLS-5608
> URL: https://issues.redhat.com/browse/DROOLS-5608
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.42.0.Final
> Reporter: Ciprian Chiru
> Assignee: Luca Molteni
> Priority: Major
>
> Given the sample rule below:
> {code:java}
> import java.util.*;
> global java.util.Set controlSet;
> rule "will execute per each Measurement having ID color"
> no-loop
> when
> Measurement( id == "color", $colorVal : val )
> String() from Optional.of($colorVal).orElse("blah")
> then
> controlSet.add($colorVal);
> end{code}
>
> Compiling the resulting model fails with:
> {code:java}
> .../target/generated-sources/drools-model-compiler/main/java/rules/Rules79f20b1c9ba841128eaf4b2dbb336819RuleMethods0.java:[24,129] cannot find symbol
> [ERROR] symbol: variable $colorVal
> [ERROR] location: class rules.Rules79f20b1c9ba841128eaf4b2dbb336819RuleMethods0{code}
> Can be reproduced with _7.43.0-SNAPSHOT_
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months