April 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13126) Refactor EJB client affinity processing

by Ranabir Chakraborty (Jira)

[ https://issues.redhat.com/browse/WFLY-13126?page=com.atlassian.jira.plugi... ] Ranabir Chakraborty commented on WFLY-13126: -------------------------------------------- [~cfang] Is this issue still open ? Can you please provide the steps to reproduce the issue ? > Refactor EJB client affinity processing > --------------------------------------- > > Key: WFLY-13126 > URL: https://issues.redhat.com/browse/WFLY-13126 > Project: WildFly > Issue Type: Feature Request > Components: EJB > Reporter: Cheng Fang > Assignee: Richard Achmatowicz > Priority: Major > Labels: EAP-CD20 > > Refactor of jboss-ejb-client internal operation: change the way in which proxy affinity (an object that decides on which node invocation should be performed) is determined. Instead of calculating it on client side we would let server set the affinity when necessary and propagate it to the client. > This refactor is supposed to reduce the complexity of jboss-ejb-client code and as a result, make it significantly easier to maintain. Richard has prepared a comprehensive document describing the suggested modifications: https://mojo.redhat.com/docs/DOC-1204767 > Parallelly, the test suite has to be refactored to make it compatible with the new algorithm and to provide broad coverage of jboss-ejb-client operation. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5207) Review oopath syntax and optimize performances where possible

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-5207?page=com.atlassian.jira.plug... ] Mario Fusco updated DROOLS-5207: -------------------------------- Issue Type: Bug (was: Task) > Review oopath syntax and optimize performances where possible > ------------------------------------------------------------- > > Key: DROOLS-5207 > URL: https://issues.redhat.com/browse/DROOLS-5207 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[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: -------------------------------- [~bjetal2003] Can I close this issue? > 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)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10742) Wildfly 13 having wrong version of Maven dependency

by Bartosz Baranowski (Jira)

[ https://issues.redhat.com/browse/WFLY-10742?page=com.atlassian.jira.plugi... ] Bartosz Baranowski resolved WFLY-10742. --------------------------------------- Resolution: Cannot Reproduce > Wildfly 13 having wrong version of Maven dependency > --------------------------------------------------- > > Key: WFLY-10742 > URL: https://issues.redhat.com/browse/WFLY-10742 > Project: WildFly > Issue Type: Bug > Environment: wildfly-13.0.0.Final on Ubuntu 16.04.5 LTS (GNU/Linux 4.4.0-119-generic x86_64) with Java 1.8.0_171 > Reporter: Peter K > Assignee: Bartosz Baranowski > Priority: Major > > I have following Maven dependency in my pom.xml: > {code:xml} > <dependency> > <groupId>com.google.guava</groupId> > <artifactId>guava</artifactId> > <version>20.0</version> > </dependency> > {code} > A) When running it on wildfly-13.0.0.Final on Ubuntu 16.04.5 LTS (GNU/Linux 4.4.0-119-generic x86_64) with Java 1.8.0_171, it is complaining about a missing method in the Guava library (which is a Guava version < 20.0): > {noformat} > 2018-07-23 10:43:21,718 ERROR [stderr] (Thread-182) Exception in thread "Thread-182" java.lang.NoSuchMethodError: com.google.common.collect.Sets$SetView.iterator()Lcom/google/common/collect/UnmodifiableIterator; > 2018-07-23 10:43:21,718 ERROR [stderr] (Thread-182) at org.reflections.Reflections.expandSuperTypes(Reflections.java:380) > 2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at org.reflections.Reflections.<init>(Reflections.java:126) > 2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at org.nd4j.linalg.api.ops.factory.DefaultOpFactory.<init>(DefaultOpFactory.java:71) > 2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > 2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > 2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > 2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) > 2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at java.lang.Class.newInstance(Class.java:442) > 2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at org.nd4j.linalg.factory.Nd4j.initWithBackend(Nd4j.java:6192) > 2018-07-23 10:43:21,720 ERROR [stderr] (Thread-182) at org.nd4j.linalg.factory.Nd4j.initContext(Nd4j.java:6087) > 2018-07-23 10:43:21,720 ERROR [stderr] (Thread-182) at org.nd4j.linalg.factory.Nd4j.<clinit>(Nd4j.java:201) > 2018-07-23 10:43:21,720 ERROR [stderr] (Thread-182) at java.lang.Thread.run(Thread.java:748)}} > {noformat} > B) It runs on Mac OS X 10.13.5 with Java 1.8.0_144 without errors. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5046) [DMN Designer] Marshalling questions

by Toni Rikkola (Jira)

[ https://issues.redhat.com/browse/DROOLS-5046?page=com.atlassian.jira.plug... ] Toni Rikkola updated DROOLS-5046: --------------------------------- Story Points: 3 (was: 5) > [DMN Designer] Marshalling questions > ------------------------------------ > > Key: DROOLS-5046 > URL: https://issues.redhat.com/browse/DROOLS-5046 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.33.0.Final > Reporter: Michael Anstis > Assignee: Toni Rikkola > Priority: Major > Labels: drools-tools > > Our marshaller is EXPLICITLY setting Definitions.typeLanguage to FEEL. Is this acceptable? > DMN1.2 Specification "6.3.2 Definitions metamodel" states : > An instance of Definitions MAY specify a typeLanguage, which is a URI that identifies the default type language used in elements within the scope of this Definitions ... If unspecified, the default typeLanguage is FEEL. > So it is not wrong, but it is not necessary. > --------------------------------------------------------------------------------- > Our marshaller is EXPLICITLY setting ItemDefinition.id > DMN1.2 Specification "7.3.2 - ItemDefinition metamodel" states : > ...an instance of ItemDefinition HAS a name and an OPTIONAL id > So it is not wrong, but it is not necessary. > --------------------------------------------------------------------------------- > Our marshaller IS NOT setting ContextEntry.id > DMN1.2 Specification 10.5.2 - ContextEntry metamodel states : > ...ContextEntry is a specialization of DMNElement, from which it INHERITS the OPTIONAL id... > It is therefore correct for us to exclude the id (but _other tools_ includes it. Is that wrong?!) > --------------------------------------------------------------------------------- > Our marshaller is EXPLICITLY setting DecisionTable.preferredOrientation (to Rule-as-Row) > DMN1.2 Specification 8.3.1 - Decision Table metamodel states : > ...It has a preferredOrientation, which SHALL be one of the enumerated DecisionTableOrientation. > It is therefore not wrong for us to include preferredOrientation and seems mandatory. > --------------------------------------------------------------------------------- > Our marshaller is EXPLICITLY setting inputExpression.id. > DMN1.2 Specification 8.3.2 - Decision Table Input and Output metamodel:- > ...An instance of InputClause is made of an optional inputExpression... [where an inputExpression is an Expression]. > There is not mention as to whether the Expression inherits its id or needs one explicitly defined. > Is it therefore incorrect for us to include the id? > --------------------------------------------------------------------------------- > Our marshaller IS NOT setting outputEntry.expressionLanguage. > DMN1.2 Specification 8.3.2 - Decision Table Input and Output metamodel states (well does NOT state anything!) : > OutputClause does not appear to have an expressionLanguage property; only the UnaryTests that is encapsulated by OutputClause supports it. > Is this an issue with _other tools_'s marshaller? > --------------------------------------------------------------------------------- > [DMN Designer] Marshaller does not support DMN1.2 DecisionTable RuleAnnotation > https://issues.redhat.com/browse/DROOLS-5045 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5031) Use general V&V modularity for all DMN Validation

by Toni Rikkola (Jira)

[ https://issues.redhat.com/browse/DROOLS-5031?page=com.atlassian.jira.plug... ] Toni Rikkola updated DROOLS-5031: --------------------------------- Sprint: 2020 Week 10-12 (from Mar 2) (was: 2020 Week 10-12 (from Mar 2), 2020 Week 13-15 (from Mar 23)) > Use general V&V modularity for all DMN Validation > ------------------------------------------------- > > Key: DROOLS-5031 > URL: https://issues.redhat.com/browse/DROOLS-5031 > Project: Drools > Issue Type: Enhancement > Components: verifier > Reporter: Toni Rikkola > Assignee: Toni Rikkola > Priority: Major > Labels: drools-tools > > Modularity here means. Any part of the validation can be activated or deactivated. This is an existing feature in general verifier used by GDST. This allows for example two range check implementations to work next to each other making each check type a module. > Other benefits of this approach is for example any future needs that might require running the rules. Allowing static and dynamic validation to exist side by side. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5203) Make DMN Validator use generic V&V module for conflicting, misleading, masked and overlapping rows

by Toni Rikkola (Jira)

[ https://issues.redhat.com/browse/DROOLS-5203?page=com.atlassian.jira.plug... ] Toni Rikkola updated DROOLS-5203: --------------------------------- Story Points: 5 > Make DMN Validator use generic V&V module for conflicting, misleading, masked and overlapping rows > -------------------------------------------------------------------------------------------------- > > Key: DROOLS-5203 > URL: https://issues.redhat.com/browse/DROOLS-5203 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Toni Rikkola > Assignee: Toni Rikkola > Priority: Major > Labels: drools-tools > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5210) BRL Column support for GDST to XLS export

by Toni Rikkola (Jira)

Toni Rikkola created DROOLS-5210: ------------------------------------ Summary: BRL Column support for GDST to XLS export Key: DROOLS-5210 URL: https://issues.redhat.com/browse/DROOLS-5210 Project: Drools Issue Type: Feature Request Components: Guided Decision Table Editor, XLS Decision Table Editor Reporter: Toni Rikkola Assignee: Toni Rikkola How good the support will end up being is still open. The goal is to have one column for each variable, but if this is doable or not will depend on the limitations of the XLS table. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2461) Clustering can fail when re-adding an existing node using TCP_NIO2

by Robert Mitchell (Jira)

[ https://issues.redhat.com/browse/JGRP-2461?page=com.atlassian.jira.plugin... ] Robert Mitchell commented on JGRP-2461: --------------------------------------- I put together a test for this and it does not appear to happen if use_ip_addrs is not set. It is difficult to be 100% sure because it is essentially a race condition, but it seems unlikely that as long as I ran the test I would not have seen it happen. > 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)

5 years, 8 months

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 April 2020