[JBoss JIRA] (JGRP-2463) TransferQueueBundler: Message to stopped node blocks the bundler thread
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2463?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2463:
--------------------------------
Hi [~dan.berindei]
Can this be reproduced?
Establishing a connection to a port on which no process is listening will result in an ICMP error message back to the sender, and the connection will be closed immediately, so this should not be an issue.
This scenario _can_ occur when:
* The receiver doesn't read messages off of the TCP socket -> the TCP send-window at the sender will become 0 and the sender will block
* The receiver is suspended ({{CTRL-Z}} or {{kill -SIGTSTP PID}}); this ends up being the same scenario as above
We _could_ experiment with a bundler that has 1 queue for destination (and 1 associated thread dequeuing), and {{RED}} dropping messages before/when the queue gets full. However, this is too complicated a change...
I think we should use {{TCP_NIO2}} for scenarios in which TCP writes can block. I guess I should move JGRP-2108 up... wdyt?
> TransferQueueBundler: Message to stopped node blocks the bundler thread
> -----------------------------------------------------------------------
>
> Key: JGRP-2463
> URL: https://issues.redhat.com/browse/JGRP-2463
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.2.1
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.2.2, 5.0.0.Alpha4
>
>
> {{TransferQueueBundler}} sends all the messages from a single thread. When one of the {{TP.doSend()}} calls blocks, the bundler thread no longer makes any progress, and it doesn't send messages to any destination, even if {{TP.doSend()}} is only slow for one particular destination.
> One example is when sending a message to a stopped node, e.g. the coordinator sending a {{LEAVE_RSP}} after the leaver has already stopped. The bundler thread calls {{TP.doSend()}}, the connection no longer exists, so it ends up calling {{BaseServer.createConnection()}}. If the stopped node's machine is no longer up or it is configured to drop messages to closed ports, the connection open blocks the bundler thread for {{TCP.sock_conn_timeout}}(default: 2s).
> {{UNICAST3}} also retransmits the highest sent message every {{UNICAST3.xmit_interval}} (default: 500ms), for {{UNICAST3.max_retransmit_time}}(default: 1 min), so the bundler thread will block more than once for the same message.
> I assume the bundler thread will also block if the transport is {{TCP}}, one of the destinations is overloaded, and the TCP connection's send buffer is full. Normally applications try to spread the workload evenly among members, but e.g. with RELAY2 not all the members will be site masters.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 12 months
[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)
3 years, 12 months
[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)
3 years, 12 months
[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)
3 years, 12 months
[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)
3 years, 12 months
[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)
3 years, 12 months
[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)
3 years, 12 months