[Red Hat JIRA] (JGRP-2521) FD_SOCK2
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2521?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2521:
---------------------------
Description:
FD_SOCK is quite old and hasn't been given a lot of maintenance love over the last two decades (2001!).
The code is quite complicated/brittle and could use some simplification.
The major enhancement is to use a fixed port, so we can scrap the code which maintains the cache of IP addresses:ports and UUIDs. This requires a poor man's state transfer of this cache to new members, plus update messages whenever a new member starts.
Using a fixed port allows us to reuse the UUID/IP-address cache, which already exists in the transport. When a view change is received, a member simply determines the peer to which to connect to by grabbing the peer's IP address from the transport cache, and connecting to it at {{port}}. We probably need a port range.
was:
FD_SOCK is quite old and hasn't been given a lot of maintenance love over the last two decades (2001!).
The code is quite complicated/brittle and could use some simplification.
The major enhancement is to use a fixed port, so we can scrap the code which maintains the cache between IP addresses:ports and UUIDs. This requires a poor man's state transfer of this cache to new members, plus update messages whenever a new member starts.
Using a fixed port allows us to reuse the UUID/IP-Address cache, which already exists in the transport. When a view change is received, a member simply determines the peer to which to connect to by grabbing the peer's IP address from the transport cache, and connecting to it at {{port}}. We probably need a port range.
> FD_SOCK2
> --------
>
> Key: JGRP-2521
> URL: https://issues.redhat.com/browse/JGRP-2521
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.2
>
>
> FD_SOCK is quite old and hasn't been given a lot of maintenance love over the last two decades (2001!).
> The code is quite complicated/brittle and could use some simplification.
> The major enhancement is to use a fixed port, so we can scrap the code which maintains the cache of IP addresses:ports and UUIDs. This requires a poor man's state transfer of this cache to new members, plus update messages whenever a new member starts.
> Using a fixed port allows us to reuse the UUID/IP-address cache, which already exists in the transport. When a view change is received, a member simply determines the peer to which to connect to by grabbing the peer's IP address from the transport cache, and connecting to it at {{port}}. We probably need a port range.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (JGRP-2521) FD_SOCK2
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2521?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2521:
---------------------------
Description:
FD_SOCK is quite old and hasn't been given a lot of maintenance love over the last two decades (2001!).
The code is quite complicated/brittle and could use some simplification.
The major enhancement is to use a fixed port, so we can scrap the code which maintains the cache between IP addresses:ports and UUIDs. This requires a poor man's state transfer of this cache to new members, plus update messages whenever a new member starts.
Using a fixed port allows us to reuse the UUID/IP-Address cache, which already exists in the transport. When a view change is received, a member simply determines the peer to which to connect to by grabbing the peer's IP address from the transport cache, and connecting to it at {{port}}. We probably need a port range.
was:
FD_SOCK is quite old and hasn't been given a lot of maintenance love over the last decade (or two!).
The code is quite complicated/brittle and could use some simplification.
The major enhancement is to use a fixed port, so we can scrap the code which maintains the cache between IP addresses:ports and UUIDs. This requires a poor man's state transfer of this cache to new members, plus update messages whenever a new member starts.
Using a fixed port allows us to reuse the UUID/IP-Address cache, which already exists in the transport. When a view change is received, a member simply determines the peer to which to connect to by grabbing the peer's IP address from the transport cache, and connecting to it at {{port}}. We probably need a port range.
> FD_SOCK2
> --------
>
> Key: JGRP-2521
> URL: https://issues.redhat.com/browse/JGRP-2521
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.2
>
>
> FD_SOCK is quite old and hasn't been given a lot of maintenance love over the last two decades (2001!).
> The code is quite complicated/brittle and could use some simplification.
> The major enhancement is to use a fixed port, so we can scrap the code which maintains the cache between IP addresses:ports and UUIDs. This requires a poor man's state transfer of this cache to new members, plus update messages whenever a new member starts.
> Using a fixed port allows us to reuse the UUID/IP-Address cache, which already exists in the transport. When a view change is received, a member simply determines the peer to which to connect to by grabbing the peer's IP address from the transport cache, and connecting to it at {{port}}. We probably need a port range.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (JGRP-2521) FD_SOCK2
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2521?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2521:
---------------------------
Summary: FD_SOCK2 (was: FD_SOCK2: enhancements over FD_SOCK)
> FD_SOCK2
> --------
>
> Key: JGRP-2521
> URL: https://issues.redhat.com/browse/JGRP-2521
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.2
>
>
> FD_SOCK is quite old and hasn't been given a lot of maintenance love over the last decade (or two!).
> The code is quite complicated/brittle and could use some simplification.
> The major enhancement is to use a fixed port, so we can scrap the code which maintains the cache between IP addresses:ports and UUIDs. This requires a poor man's state transfer of this cache to new members, plus update messages whenever a new member starts.
> Using a fixed port allows us to reuse the UUID/IP-Address cache, which already exists in the transport. When a view change is received, a member simply determines the peer to which to connect to by grabbing the peer's IP address from the transport cache, and connecting to it at {{port}}. We probably need a port range.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (WFLY-14199) OnOffOpenTracingTestCase leaves the server in a bad state
by Emmanuel Hugonnet (Jira)
[ https://issues.redhat.com/browse/WFLY-14199?page=com.atlassian.jira.plugi... ]
Emmanuel Hugonnet edited comment on WFLY-14199 at 12/10/20 3:05 AM:
--------------------------------------------------------------------
[~ron_sigal] Hello, you need to run the tests in the 'proper' order :
{code:java}
@RunWith(Suite.class)
@SuiteClasses({
org.wildfly.test.integration.microprofile.opentracing.OnOffOpenTracingTestCase.class,
org.wildfly.test.integration.microprofile.opentracing.SimpleRestClientTestCase.class
})
public class WFLY14199TestSuite {}
{code}
look at my branch [https://github.com/wildfly/wildfly/pull/13774|https://github.com/wildfly/...]
The tests have been moved to testsuite/integration/microprofile
was (Author: ehugonnet):
[~ron_sigal] Hello,
{code:java}
@RunWith(Suite.class)
@SuiteClasses({
org.wildfly.test.integration.microprofile.opentracing.OnOffOpenTracingTestCase.class,
org.wildfly.test.integration.microprofile.opentracing.SimpleRestClientTestCase.class
})
public class WFLY14199TestSuite {}
{code}
look at my branch [https://github.com/wildfly/wildfly/pull/13774|https://github.com/wildfly/...]
The tests have been moved to testsuite/integration/microprofile
> OnOffOpenTracingTestCase leaves the server in a bad state
> ---------------------------------------------------------
>
> Key: WFLY-14199
> URL: https://issues.redhat.com/browse/WFLY-14199
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing, Test Suite
> Affects Versions: 22.0.0.Alpha1
> Reporter: Emmanuel Hugonnet
> Assignee: Emmanuel Hugonnet
> Priority: Major
>
> {color:#333333}OnOffOpenTracingTestCase{color} will leave the server in such a state that SimpleRestClientTestCase will fail. Removing and adding the opentracing subsystem to check that it doesn't work once removed shoudl be reevaluated.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (JGRP-2521) FD_SOCK2: enhancements over FD_SOCK
by Bela Ban (Jira)
Bela Ban created JGRP-2521:
------------------------------
Summary: FD_SOCK2: enhancements over FD_SOCK
Key: JGRP-2521
URL: https://issues.redhat.com/browse/JGRP-2521
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 5.2
FD_SOCK is quite old and hasn't been given a lot of maintenance love over the last decade (or two!).
The code is quite complicated/brittle and could use some simplification.
The major enhancement is to use a fixed port, so we can scrap the code which maintains the cache between IP addresses:ports and UUIDs. This requires a poor man's state transfer of this cache to new members, plus update messages whenever a new member starts.
Using a fixed port allows us to reuse the UUID/IP-Address cache, which already exists in the transport. When a view change is received, a member simply determines the peer to which to connect to by grabbing the peer's IP address from the transport cache, and connecting to it at {{port}}. We probably need a port range.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (WFLY-14199) OnOffOpenTracingTestCase leaves the server in a bad state
by Emmanuel Hugonnet (Jira)
[ https://issues.redhat.com/browse/WFLY-14199?page=com.atlassian.jira.plugi... ]
Emmanuel Hugonnet commented on WFLY-14199:
------------------------------------------
[~ron_sigal] Hello,
{code:java}
@RunWith(Suite.class)
@SuiteClasses({
org.wildfly.test.integration.microprofile.opentracing.OnOffOpenTracingTestCase.class,
org.wildfly.test.integration.microprofile.opentracing.SimpleRestClientTestCase.class
})
public class WFLY14199TestSuite {}
{code}
look at my branch [https://github.com/wildfly/wildfly/pull/13774|https://github.com/wildfly/...]
The tests have been moved to testsuite/integration/microprofile
> OnOffOpenTracingTestCase leaves the server in a bad state
> ---------------------------------------------------------
>
> Key: WFLY-14199
> URL: https://issues.redhat.com/browse/WFLY-14199
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing, Test Suite
> Affects Versions: 22.0.0.Alpha1
> Reporter: Emmanuel Hugonnet
> Assignee: Emmanuel Hugonnet
> Priority: Major
>
> {color:#333333}OnOffOpenTracingTestCase{color} will leave the server in such a state that SimpleRestClientTestCase will fail. Removing and adding the opentracing subsystem to check that it doesn't work once removed shoudl be reevaluated.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (DROOLS-5889) Assignment to BigDecimal type property causes compilation errors in executable model.
by Luca Molteni (Jira)
[ https://issues.redhat.com/browse/DROOLS-5889?page=com.atlassian.jira.plug... ]
Luca Molteni updated DROOLS-5889:
---------------------------------
Sprint: 2020 Week 49-51 (from Nov 30)
> Assignment to BigDecimal type property causes compilation errors in executable model.
> -------------------------------------------------------------------------------------
>
> Key: DROOLS-5889
> URL: https://issues.redhat.com/browse/DROOLS-5889
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Reporter: Luca Molteni
> Assignee: Luca Molteni
> Priority: Major
> Labels: support
>
> Compiling a rule like (*1) which is described in MVEL dialect and contains an assignment statement to BigDecimal type property with executable rule models enabled, compilation errors like (*2) occur.
> (*1)
> {noformat}
> package com.example.reproducer
> import com.example.reproducer.Bus
> dialect "mvel"
> rule "bus3a"
> when
> $bus : Bus()
> then
> modify($bus) {
> weight = 13000
> }
> System.out.println("***** " + $bus + ", weight = " + $bus.weight);
> end
> {noformat}
> $bus.weight is a BigDecimal type property.
> (*2)
> {noformat}
> [ERROR] /test/reproducer_02801729_3a/target/generated-sources/drools-model-compiler/main/java/com/example/reproducer/P23/LambdaConsequence23B3ED62B695E9AEA44284D670FC4A7C.java:[20,13] weight has private access in com.example.reproducer.Bus
> [ERROR] /test/reproducer_02801729_3a/target/generated-sources/drools-model-compiler/main/java/com/example/reproducer/P23/LambdaConsequence23B3ED62B695E9AEA44284D670FC4A7C.java:[20,23] incompatible types: int cannot be converted to java.math.BigDecimal
> {noformat}
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (DROOLS-5889) Assignment to BigDecimal type property causes compilation errors in executable model.
by Luca Molteni (Jira)
[ https://issues.redhat.com/browse/DROOLS-5889?page=com.atlassian.jira.plug... ]
Luca Molteni moved RHDM-1526 to DROOLS-5889:
--------------------------------------------
Project: Drools (was: Red Hat Decision Manager)
Key: DROOLS-5889 (was: RHDM-1526)
Workflow: GIT Pull Request workflow (was: CDW with docs v1)
Docs QE Status: NEW
Component/s: executable model
(was: BRE)
Environment: (was: RHDM 7.9.0.)
Affects Version/s: (was: 7.9.0.GA)
QE Status: NEW
> Assignment to BigDecimal type property causes compilation errors in executable model.
> -------------------------------------------------------------------------------------
>
> Key: DROOLS-5889
> URL: https://issues.redhat.com/browse/DROOLS-5889
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Reporter: Luca Molteni
> Assignee: Luca Molteni
> Priority: Major
> Labels: support
>
> Compiling a rule like (*1) which is described in MVEL dialect and contains an assignment statement to BigDecimal type property with executable rule models enabled, compilation errors like (*2) occur.
> (*1)
> {noformat}
> package com.example.reproducer
> import com.example.reproducer.Bus
> dialect "mvel"
> rule "bus3a"
> when
> $bus : Bus()
> then
> modify($bus) {
> weight = 13000
> }
> System.out.println("***** " + $bus + ", weight = " + $bus.weight);
> end
> {noformat}
> $bus.weight is a BigDecimal type property.
> (*2)
> {noformat}
> [ERROR] /test/reproducer_02801729_3a/target/generated-sources/drools-model-compiler/main/java/com/example/reproducer/P23/LambdaConsequence23B3ED62B695E9AEA44284D670FC4A7C.java:[20,13] weight has private access in com.example.reproducer.Bus
> [ERROR] /test/reproducer_02801729_3a/target/generated-sources/drools-model-compiler/main/java/com/example/reproducer/P23/LambdaConsequence23B3ED62B695E9AEA44284D670FC4A7C.java:[20,23] incompatible types: int cannot be converted to java.math.BigDecimal
> {noformat}
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (WFLY-14199) OnOffOpenTracingTestCase leaves the server in a bad state
by Ronald Sigal (Jira)
[ https://issues.redhat.com/browse/WFLY-14199?page=com.atlassian.jira.plugi... ]
Ronald Sigal commented on WFLY-14199:
-------------------------------------
Hey [~ehugonnet]
Alessio asked me to look at this issue. I just ran the basic integration testsuite and both tests passed. I've got WildFly at commit
{code:java}
[rsigal@localhost basic]$ git log
commit 2095d398152d31c43f14f4200683fd1f6e59f52b (HEAD -> master, origin/master, origin/HEAD)
Merge: a0c550e909 e07a9919b3
Author: Brian Stansberry <brian.stansberry(a)redhat.com>
Date: Tue Dec 8 11:31:42 2020 -0600 Merge pull request #13791 from darranl/WFLY-14174
[WFLY-14174] Update DefaultBindingsAdd to use Phase ID defined in WildFly Core. {code}
Are you using a different version?
> OnOffOpenTracingTestCase leaves the server in a bad state
> ---------------------------------------------------------
>
> Key: WFLY-14199
> URL: https://issues.redhat.com/browse/WFLY-14199
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing, Test Suite
> Affects Versions: 22.0.0.Alpha1
> Reporter: Emmanuel Hugonnet
> Assignee: Emmanuel Hugonnet
> Priority: Major
>
> {color:#333333}OnOffOpenTracingTestCase{color} will leave the server in such a state that SimpleRestClientTestCase will fail. Removing and adding the opentracing subsystem to check that it doesn't work once removed shoudl be reevaluated.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months