[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:
--------------------------------
You don't need to use {{use_ip_addrs}} to mark special nodes; this can be done via custom addresses \[1\]. Use for example {{ExtendedUUID}} or {{FlagsUUID}}.
It would be nice if you could test this, so I know whether your issue is caused by {{use_ip_addrs}}, or not.
\[1\] http://www.jgroups.org/manual4/index.html#CustomAddresses
\[2\] http://www.jgroups.org/manual4/index.html#MembershipChangePolicy
> 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)
6 years, 1 month
[JBoss JIRA] (DROOLS-2254) Automate .proto files rebuild in pom.xml
by Michael Biarnes Kiefer (Jira)
[ https://issues.redhat.com/browse/DROOLS-2254?page=com.atlassian.jira.plug... ]
Michael Biarnes Kiefer updated DROOLS-2254:
-------------------------------------------
Fix Version/s: 7.36.0.Final
(was: 7.35.0.Final)
> Automate .proto files rebuild in pom.xml
> ----------------------------------------
>
> Key: DROOLS-2254
> URL: https://issues.redhat.com/browse/DROOLS-2254
> Project: Drools
> Issue Type: Task
> Components: tools
> Affects Versions: 7.5.0.Final
> Reporter: Dmitry Volodin
> Assignee: Dmitry Volodin
> Priority: Minor
> Fix For: 7.36.0.Final
>
>
> According to contribution guide, any .proto file or protobuf version changes it's necessary to download protoc utility and regenerate Java classes based on .proto files.
> This will add automation for downloading protoc utility and Java classes generation based on Maven Protocol Buffers Plugin. There is no timestamps and other build related info inside generated Java files and no changes will be added on each new build.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-5095) [DMN Designer] Investigate performance switching between editor instances
by Michael Biarnes Kiefer (Jira)
[ https://issues.redhat.com/browse/DROOLS-5095?page=com.atlassian.jira.plug... ]
Michael Biarnes Kiefer updated DROOLS-5095:
-------------------------------------------
Fix Version/s: 7.36.0.Final
(was: 7.35.0.Final)
> [DMN Designer] Investigate performance switching between editor instances
> -------------------------------------------------------------------------
>
> Key: DROOLS-5095
> URL: https://issues.redhat.com/browse/DROOLS-5095
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Affects Versions: 7.33.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Minor
> Labels: drools-tools
> Fix For: 7.36.0.Final
>
> Attachments: switch-dmn.webm
>
>
> This JIRA is to investigate the reported performance issue switching between different DMN Designer instances in Business Central.
> The issue was noticed by [~jomarko] when testing DROOLS-5058 (although the fix therein should have had *zero* affect on switching).
> For more details see the video [^switch-dmn.webm]
> h2. Manual acceptance test
> - Prepare 5 DMN models in project
> - Open all in parallel
> - Try to switch between them, keep all opened
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month