[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)
4 years, 9 months
- 1
- 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)
4 years, 9 months
- 1
- 0