[JBoss JIRA] (DROOLS-5072) DMN investigate wire DT static analysis to kie-maven-plugin
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5072?page=com.atlassian.jira.plug... ]
Matteo Mortari updated DROOLS-5072:
-----------------------------------
Sprint: 2020 Week 16-18 (from Apr 13), 2020 Week 22-24 (from May 25), 2020 Week 25-27 (from Jun 15), 2020 Week 28-30 (from Jul 6), 2020 Week 31-33 (from Jul 27), 2020 Week 37-39 (from Sep 7) (was: 2020 Week 16-18 (from Apr 13), 2020 Week 22-24 (from May 25), 2020 Week 25-27 (from Jun 15), 2020 Week 28-30 (from Jul 6), 2020 Week 31-33 (from Jul 27), 2020 Week 34-36 (from Aug 17))
> DMN investigate wire DT static analysis to kie-maven-plugin
> -----------------------------------------------------------
>
> Key: DROOLS-5072
> URL: https://issues.redhat.com/browse/DROOLS-5072
> Project: Drools
> Issue Type: Feature Request
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Priority: Major
>
> followup [DROOLS-5020]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 8 months
[JBoss JIRA] (JGRP-1957) S3_PING: Nodes never removed from .list file
by ofer keren (Jira)
[ https://issues.redhat.com/browse/JGRP-1957?page=com.atlassian.jira.plugin... ]
ofer keren commented on JGRP-1957:
----------------------------------
Thanks !! [~belaban]
> S3_PING: Nodes never removed from .list file
> --------------------------------------------
>
> Key: JGRP-1957
> URL: https://issues.redhat.com/browse/JGRP-1957
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.4
> Environment: JGroups client running on Mac OS X - Yosemite
> JDK 1.7.71
> Reporter: Nick Sawadsky
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.6
>
>
> I'm not 100% sure, but it seems like there might be a defect here.
> I'm using TCP, S3_PING, and MERGE3.
> I've set logical_addr_cache_max_size to 2 for testing purposes, although I don't think the value of this setting affects my test results.
> I start a single node, node A. Then I start a second node, node B.
> I then repeatedly shutdown and restart node B.
> Each time node B starts, a new row is added to the .list file stored in S3.
> But even if I continue this process for 15 minutes, old rows are never removed from the .list file, so it continues to grow in size.
> I've read the docs and mailing list threads, so I'm aware that the list is not immediately updated as soon as a member leaves. But I was expecting that when a view change occurs, nodes no longer in the view would be marked for removal (line 2193 of TP.java) and then after the logical_addr_cache_expiration has been reached and the reaper kicks in, once a new node joins, the expired cache entries would be purged from the file.
> I dug in to the code a bit, and what seems to be happening is that the MERGE3 protocol periodically generates a FIND_MBRS event. S3_PING retrieves the membership from the .list file, which includes expired nodes. And then all of these members are re-added to the logical address cache (line 157 of S3_PING.java, line 533 of Discovery.java, line 2263 of TP.java).
> So expired nodes are continually re-added to the logical address cache, preventing them from ever being reaped.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 8 months
[JBoss JIRA] (JGRP-1957) S3_PING: Nodes never removed from .list file
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-1957?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-1957:
--------------------------------
T means the member is a coordinator (true), F means it isn't (false).
> S3_PING: Nodes never removed from .list file
> --------------------------------------------
>
> Key: JGRP-1957
> URL: https://issues.redhat.com/browse/JGRP-1957
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.4
> Environment: JGroups client running on Mac OS X - Yosemite
> JDK 1.7.71
> Reporter: Nick Sawadsky
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.6
>
>
> I'm not 100% sure, but it seems like there might be a defect here.
> I'm using TCP, S3_PING, and MERGE3.
> I've set logical_addr_cache_max_size to 2 for testing purposes, although I don't think the value of this setting affects my test results.
> I start a single node, node A. Then I start a second node, node B.
> I then repeatedly shutdown and restart node B.
> Each time node B starts, a new row is added to the .list file stored in S3.
> But even if I continue this process for 15 minutes, old rows are never removed from the .list file, so it continues to grow in size.
> I've read the docs and mailing list threads, so I'm aware that the list is not immediately updated as soon as a member leaves. But I was expecting that when a view change occurs, nodes no longer in the view would be marked for removal (line 2193 of TP.java) and then after the logical_addr_cache_expiration has been reached and the reaper kicks in, once a new node joins, the expired cache entries would be purged from the file.
> I dug in to the code a bit, and what seems to be happening is that the MERGE3 protocol periodically generates a FIND_MBRS event. S3_PING retrieves the membership from the .list file, which includes expired nodes. And then all of these members are re-added to the logical address cache (line 157 of S3_PING.java, line 533 of Discovery.java, line 2263 of TP.java).
> So expired nodes are continually re-added to the logical address cache, preventing them from ever being reaped.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 8 months
[JBoss JIRA] (DROOLS-5618) DMN DT Analysis advanced 2NF detection
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5618?page=com.atlassian.jira.plug... ]
Matteo Mortari updated DROOLS-5618:
-----------------------------------
Description:
In a table such as
!screenshot-1.png|thumbnail!
rules 4,5,6 and rules 7,8 should be candidate of 2NF violations.
was:
In a table such as
!image-2020-09-03-11-07-19-348.png|thumbnail!
rules 4,5,6 and rules 7,8 should be candidate of 2NF violations.
> DMN DT Analysis advanced 2NF detection
> --------------------------------------
>
> Key: DROOLS-5618
> URL: https://issues.redhat.com/browse/DROOLS-5618
> Project: Drools
> Issue Type: Enhancement
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Priority: Major
> Attachments: screenshot-1.png
>
>
> In a table such as
> !screenshot-1.png|thumbnail!
> rules 4,5,6 and rules 7,8 should be candidate of 2NF violations.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 8 months