September 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-5414) DMN Validation rule check DecisionService at least 1 outputDecision

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-5414?page=com.atlassian.jira.plug... ] Matteo Mortari updated DROOLS-5414: ----------------------------------- Sprint: 2020 Week 37-39 (from Sep 7) (was: 2020 Week 34-36 (from Aug 17)) > DMN Validation rule check DecisionService at least 1 outputDecision > ------------------------------------------------------------------- > > Key: DROOLS-5414 > URL: https://issues.redhat.com/browse/DROOLS-5414 > Project: Drools > Issue Type: Feature Request > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > Labels: good-first-issue > Attachments: screenshot-1.png > > > it is redundant to XSD > !screenshot-1.png|thumbnail! > however given the low effort is good to implement anyway for those use-case where XSD validation is skipped. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-5581) Add groupBy feature to executable model DSL

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-5581?page=com.atlassian.jira.plug... ] Mario Fusco updated DROOLS-5581: -------------------------------- Sprint: 2020 Week 37-39 (from Sep 7) (was: 2020 Week 34-36 (from Aug 17)) > Add groupBy feature to executable model DSL > ------------------------------------------- > > Key: DROOLS-5581 > URL: https://issues.redhat.com/browse/DROOLS-5581 > Project: Drools > Issue Type: Feature Request > Reporter: Mario Fusco > Assignee: Mario Fusco > Priority: Major > > Optaplanner's CS-D requires that the executable model should provide a construct to build an efficient groupBy implementation. > More details are available here [https://docs.google.com/document/d/1IxL2HNMNf_OYxOGGzkVjwXc7NW5ZEear-kz4O...] > We already measured that an implementation based on a 3-rules solution as sketched here [https://github.com/triceo/groupby/blob/master/src/main/resources/org/opta...] fulfills the expected performance requirements, so we need > # a convenient method in the executable model DSL to define a groupBy > # an implementation that internally translates the groupBy defined with 1. into the equivalent of that 3-rules based solution -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

1
0
0 / 0

[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, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-5616) Be able to set with an Env Variable that KIE using XStream does not complain on unknown fields

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5616?page=com.atlassian.jira.plug... ] Toshiya Kobayashi updated DROOLS-5616: -------------------------------------- Story Points: 3 Sprint: 2020 Week 34-36 (from Aug 17) Affects Version/s: 7.42.0.Final > Be able to set with an Env Variable that KIE using XStream does not complain on unknown fields > ---------------------------------------------------------------------------------------------- > > Key: DROOLS-5616 > URL: https://issues.redhat.com/browse/DROOLS-5616 > Project: Drools > Issue Type: Feature Request > Components: kie server > Affects Versions: 7.42.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > > Add an option to trigger xstream.ignoreUnknownElements() -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

1
0
0 / 0

[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, 1 month

1
0
0 / 0

[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, 1 month

1
0
0 / 0

[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: ----------------------------------- Attachment: screenshot-1.png > 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 > !image-2020-09-03-11-07-19-348.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, 1 month

1
0
0 / 0

[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: ----------------------------------- Attachment: (was: image-2020-09-03-11-07-19-348.png) > 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 > !image-2020-09-03-11-07-19-348.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, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13354) Add Galleon layers for the EJB subsystem

by Tommaso Borgato (Jira)

[ https://issues.redhat.com/browse/WFLY-13354?page=com.atlassian.jira.plugi... ] Tommaso Borgato commented on WFLY-13354: ---------------------------------------- [~cfang] it's not clear to which PR to use between [https://github.com/wildfly/wildfly/pull/13524] and [https://github.com/wildfly/wildfly/pull/13527] > Add Galleon layers for the EJB subsystem > ---------------------------------------- > > Key: WFLY-13354 > URL: https://issues.redhat.com/browse/WFLY-13354 > Project: WildFly > Issue Type: Feature Request > Components: Build System, EJB > Reporter: Brian Stansberry > Assignee: Cheng Fang > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

1
0
0 / 0

[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: ---------------------------------- Hi, What is the F and T means ? ip-10-89-1-26-8729 72597f74-8a10-04fb-b397-22a3ed35da84 10.89.1.26:7800 *F* ip-10-89-1-62-4868 ef73921a-2265-50a8-95d4-ebb8cae96944 10.89.1.62:7800 *T* Thanks Ofer > 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, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2020