[JBoss JIRA] (JGRP-2461) Clustering can fail when re-adding an existing node using TCP_NIO2
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2461?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2461:
--------------------------------
Does the issue occur when {{use_ip_addrs}} is {{false}}?
I'm thinking about pulling this option in 5.0 as cruft; nobody seems to use it...
> Clustering can fail when re-adding an existing node using TCP_NIO2
> ------------------------------------------------------------------
>
> Key: JGRP-2461
> URL: https://issues.redhat.com/browse/JGRP-2461
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.8
> Reporter: Robert Mitchell
> Assignee: Bela Ban
> Priority: Major
>
> When a node leaves a cluster and then later attempts to re-enter, a race condition can occur where the clustering fails to occur. Here is the sequence of events that seems to allow this to occur:
> # The rejoining node must have a "higher" IP address than the current cluster coordinator.
> # On the rejoin attempt, the coordinator sends a message to the rejoining node before the rejoining node sends to the coordinator using its prior address. I have seen this happen for two reasons:
> ## UNICAST3 is resending messages (which often happens with the final LEAVE_RSP from the prior cluster membership because it apparently does not get acked before the connection closes)
> ## TCPPING is sending a ping request to the cached prior address.
> # The connection gets established. It will then be used by the rejoining node whenever communicating with the cluster coordinator.
> # However, the cluster coordinator has this as the connection for the prior address. So the following happens whenever it wants to send a message to the rejoining node:
> ## It will attempt to create a new connection.
> ## The rejoining node will reject the connection as a redundant connection with its current connection taking precedence since it is coming from the same logical address as the "bad" connection.
> Since the messages needed to find and join the cluster or merge the two clusters are all unicast messages, the rejoining node will never get them and not be able to join until something happens that causes the initial connection to get closed.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (JGRP-2130) Log: cache result of log.isTraceEnabled()
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2130?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2130:
--------------------------------
Correct, we do use {{is_trace}} in {{TP}}, which is extended by {{UDP}} and {{TCP}}.
> Log: cache result of log.isTraceEnabled()
> -----------------------------------------
>
> Key: JGRP-2130
> URL: https://issues.redhat.com/browse/JGRP-2130
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Labels: CR1
> Fix For: 4.0
>
>
> e.g.
> {noformat}
> boolean trace=log.isTraceEnabled();
> loop {
> if(trace) ...
> }
> {noformat}
> Unfortunately, {{isTraceEnabled()}} is not free in most scenarios, so the cost of invoking this method should be amortized over multiple calls.
> I don't want to cache this at a global level, or else we wouldn't be able to change the log level at runtime...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-5178) [DMN Designer] Generate unnecessary typerRef on output tag
by Michael Anstis (Jira)
[ https://issues.redhat.com/browse/DROOLS-5178?page=com.atlassian.jira.plug... ]
Michael Anstis updated DROOLS-5178:
-----------------------------------
Labels: drools-tools (was: )
> [DMN Designer] Generate unnecessary typerRef on output tag
> ----------------------------------------------------------
>
> Key: DROOLS-5178
> URL: https://issues.redhat.com/browse/DROOLS-5178
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.34.0.Final
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Priority: Minor
> Labels: drools-tools
> Attachments: SampleModel2.dmn, screenshot-1.png
>
>
> Step to reproduce the problem:
> 1. Create a simple decision node with input: string output: string
> 2. Implement the decision node ad a table
> it generates this DMN: [^SampleModel2.dmn]
> the validation engine says
> bq. "WARNING","[_95E9A8C2-34B5-453A-AAF2-9C8BDB092A03] DMN: Decision table with single output on node 'Decision-1' should not have an output type reference (DMN id: _95E9A8C2-34B5-453A-AAF2-9C8BDB092A03, The referenced element should not have a typeref set) ","SampleModel2.dmn","0","0"
> In fact, the dmn contains the following line:
> {code:xml}
> <dmn:output id="_95E9A8C2-34B5-453A-AAF2-9C8BDB092A03" typeRef="string"/>
> {code}
> removing the {{typeRef="string"}} the validation warning disappear.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-5178) [DMN Designer] Generate unnecessary typerRef on output tag
by Michael Anstis (Jira)
[ https://issues.redhat.com/browse/DROOLS-5178?page=com.atlassian.jira.plug... ]
Michael Anstis updated DROOLS-5178:
-----------------------------------
Story Points: 3
Sprint: 2020 Week 10-12 (from Mar 2)
> [DMN Designer] Generate unnecessary typerRef on output tag
> ----------------------------------------------------------
>
> Key: DROOLS-5178
> URL: https://issues.redhat.com/browse/DROOLS-5178
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.34.0.Final
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Priority: Minor
> Labels: drools-tools
> Attachments: SampleModel2.dmn, screenshot-1.png
>
>
> Step to reproduce the problem:
> 1. Create a simple decision node with input: string output: string
> 2. Implement the decision node ad a table
> it generates this DMN: [^SampleModel2.dmn]
> the validation engine says
> bq. "WARNING","[_95E9A8C2-34B5-453A-AAF2-9C8BDB092A03] DMN: Decision table with single output on node 'Decision-1' should not have an output type reference (DMN id: _95E9A8C2-34B5-453A-AAF2-9C8BDB092A03, The referenced element should not have a typeref set) ","SampleModel2.dmn","0","0"
> In fact, the dmn contains the following line:
> {code:xml}
> <dmn:output id="_95E9A8C2-34B5-453A-AAF2-9C8BDB092A03" typeRef="string"/>
> {code}
> removing the {{typeRef="string"}} the validation warning disappear.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-5178) [DMN Designer] Generate unnecessary typerRef on output tag
by Michael Anstis (Jira)
[ https://issues.redhat.com/browse/DROOLS-5178?page=com.atlassian.jira.plug... ]
Michael Anstis moved RHDM-1293 to DROOLS-5178:
----------------------------------------------
Project: Drools (was: Red Hat Decision Manager)
Key: DROOLS-5178 (was: RHDM-1293)
Workflow: GIT Pull Request workflow (was: CDW with docs v1)
Docs QE Status: NEW
Component/s: DMN Editor
(was: Decision Central)
Environment: (was: Business Central)
Affects Version/s: 7.34.0.Final
(was: 7.6.0.GA)
QE Status: NEW
> [DMN Designer] Generate unnecessary typerRef on output tag
> ----------------------------------------------------------
>
> Key: DROOLS-5178
> URL: https://issues.redhat.com/browse/DROOLS-5178
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.34.0.Final
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Priority: Minor
> Labels: drools-tools
> Attachments: SampleModel2.dmn, screenshot-1.png
>
>
> Step to reproduce the problem:
> 1. Create a simple decision node with input: string output: string
> 2. Implement the decision node ad a table
> it generates this DMN: [^SampleModel2.dmn]
> the validation engine says
> bq. "WARNING","[_95E9A8C2-34B5-453A-AAF2-9C8BDB092A03] DMN: Decision table with single output on node 'Decision-1' should not have an output type reference (DMN id: _95E9A8C2-34B5-453A-AAF2-9C8BDB092A03, The referenced element should not have a typeref set) ","SampleModel2.dmn","0","0"
> In fact, the dmn contains the following line:
> {code:xml}
> <dmn:output id="_95E9A8C2-34B5-453A-AAF2-9C8BDB092A03" typeRef="string"/>
> {code}
> removing the {{typeRef="string"}} the validation warning disappear.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month