[JBoss JIRA] (JGRP-2470) JBDC_PING can face a split-brain issue when restarting a cooridnator node
by Masafumi Miura (Jira)
Masafumi Miura created JGRP-2470:
------------------------------------
Summary: JBDC_PING can face a split-brain issue when restarting a cooridnator node
Key: JGRP-2470
URL: https://issues.redhat.com/browse/JGRP-2470
Project: JGroups
Issue Type: Bug
Affects Versions: 4.0.22, 4.1.9
Reporter: Masafumi Miura
Assignee: Bela Ban
After [the change|https://github.com/belaban/JGroups/commit/215cdb6] for JGRP-2199, JDBC_PING deletes all entries from the table during the shutdown of the coordinator node.
This behavior has a possibility to cause a split-brain when restarting a coordinator node. Because, as all entries are lost in the following scenario, the restarting node can not find any information about existing nodes from the table and does not form a cluster.
0. node1 and node2 form a cluster. The node1 is a coordinator.
1. Trigger a restart of the node1
2. The node1 removes their node information from the table
3. The node2 becomes a new coordinator
4. The node2 updates their node information in the table
5. The node1 clears all entries from the table
6. The node1 starts again
7. The node1 does not join the existing cluster because there's no node information in the table
Note: If step 5 happens before step 4, the split-brain issue does not happen. However, as step 4 and step 5 happen on different nodes, these steps can happen in parallel. So, the order is undefined. So, for example, if the shutdown of node1 takes a long time, there's a high possibility to face this issue.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13390) :migrate operation on legacy messaging subsystem fails with 7.4.0.CD19 (WF19)
by Emmanuel Hugonnet (Jira)
[ https://issues.redhat.com/browse/WFLY-13390?page=com.atlassian.jira.plugi... ]
Emmanuel Hugonnet moved JBEAP-19278 to WFLY-13390:
--------------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-13390 (was: JBEAP-19278)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JMS
Migration
(was: JMS)
(was: Migration)
Affects Version/s: 19.0.0.Final
(was: 7.4.0.CD19)
> :migrate operation on legacy messaging subsystem fails with 7.4.0.CD19 (WF19)
> -----------------------------------------------------------------------------
>
> Key: WFLY-13390
> URL: https://issues.redhat.com/browse/WFLY-13390
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Migration
> Affects Versions: 19.0.0.Final
> Reporter: Emmanuel Hugonnet
> Assignee: Emmanuel Hugonnet
> Priority: Critical
>
> CD19 (WF19) introduces several failures in tests running the {{:migrate}} operation on legacy configuration files.
> See [^standalone-full-ha-migrate.xml.original] for configuration file which is subject of migration.
> {code}
> ...
> <broadcast-groups>
> <broadcast-group name="groupS">
> <socket-binding>messaging-group</socket-binding>
> </broadcast-group>
> ...
> </broadcast-groups>
> ...
> {code}
> See [^standalone-full-ha-migrate.xml.migrated] for configuration file after migration using 7.3.0 EAP.
> {code}
> ...
> <broadcast-group socket-binding="messaging-group" name="groupS"/>
> ...
> {code}
> Migration outcome with 7.4.0.CD19.CR1 (WF19)
> {code}
> {
> "outcome" : "failed",
> "result" : {
> "migration-warnings" : [],
> "migration-error" : {
> "operation" : {
> "socket-binding" : "messaging-group",
> "connectors" : null,
> "operation" : "add",
> "address" : [
> {
> "subsystem" : "messaging-activemq"
> },
> {
> "server" : "default"
> },
> {
> "broadcast-group" : "groupS"
> }
> ],
> "operation-headers" : {
> "caller-type" : "user",
> "access-mechanism" : "NATIVE"
> }
> },
> "result" : {
> "outcome" : "failed",
> "failure-description" : "WFLYCTL0155: 'connectors' may not be null",
> "rolled-back" : true
> }
> }
> },
> "failure-description" : "WFLYMSG0081: Migration failed, see results for more details.",
> "rolled-back" : true
> }
> {code}
> Unfortunately I do not have a deeper knowledge of messaging subsystem to be able to tell what should be the best outcome of migration here.
> Could be related to https://issues.redhat.com/browse/WFLY-10339 Broadcast/discovery-group resources have ambiguous requirement specs
> *Steps to reproduce*
> {code}
> $ cp standalone-full-ha-migrate.xml.original jboss-eap-7.4/standalone/configuration/standalone.xml
> $ ./jboss-eap-7.4/bin/jboss-cli.sh
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] embed-server --admin-only=true
> [standalone@embedded /] /subsystem=messaging:migrate
> {
> "outcome" => "failed",
> ...
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13390) :migrate operation on legacy messaging subsystem fails with WF19
by Emmanuel Hugonnet (Jira)
[ https://issues.redhat.com/browse/WFLY-13390?page=com.atlassian.jira.plugi... ]
Emmanuel Hugonnet updated WFLY-13390:
-------------------------------------
Summary: :migrate operation on legacy messaging subsystem fails with WF19 (was: :migrate operation on legacy messaging subsystem fails with 7.4.0.CD19 (WF19))
> :migrate operation on legacy messaging subsystem fails with WF19
> ----------------------------------------------------------------
>
> Key: WFLY-13390
> URL: https://issues.redhat.com/browse/WFLY-13390
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Migration
> Affects Versions: 19.0.0.Final
> Reporter: Emmanuel Hugonnet
> Assignee: Emmanuel Hugonnet
> Priority: Critical
>
> CD19 (WF19) introduces several failures in tests running the {{:migrate}} operation on legacy configuration files.
> See [^standalone-full-ha-migrate.xml.original] for configuration file which is subject of migration.
> {code}
> ...
> <broadcast-groups>
> <broadcast-group name="groupS">
> <socket-binding>messaging-group</socket-binding>
> </broadcast-group>
> ...
> </broadcast-groups>
> ...
> {code}
> See [^standalone-full-ha-migrate.xml.migrated] for configuration file after migration using 7.3.0 EAP.
> {code}
> ...
> <broadcast-group socket-binding="messaging-group" name="groupS"/>
> ...
> {code}
> Migration outcome with 7.4.0.CD19.CR1 (WF19)
> {code}
> {
> "outcome" : "failed",
> "result" : {
> "migration-warnings" : [],
> "migration-error" : {
> "operation" : {
> "socket-binding" : "messaging-group",
> "connectors" : null,
> "operation" : "add",
> "address" : [
> {
> "subsystem" : "messaging-activemq"
> },
> {
> "server" : "default"
> },
> {
> "broadcast-group" : "groupS"
> }
> ],
> "operation-headers" : {
> "caller-type" : "user",
> "access-mechanism" : "NATIVE"
> }
> },
> "result" : {
> "outcome" : "failed",
> "failure-description" : "WFLYCTL0155: 'connectors' may not be null",
> "rolled-back" : true
> }
> }
> },
> "failure-description" : "WFLYMSG0081: Migration failed, see results for more details.",
> "rolled-back" : true
> }
> {code}
> Unfortunately I do not have a deeper knowledge of messaging subsystem to be able to tell what should be the best outcome of migration here.
> Could be related to https://issues.redhat.com/browse/WFLY-10339 Broadcast/discovery-group resources have ambiguous requirement specs
> *Steps to reproduce*
> {code}
> $ cp standalone-full-ha-migrate.xml.original jboss-eap-7.4/standalone/configuration/standalone.xml
> $ ./jboss-eap-7.4/bin/jboss-cli.sh
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] embed-server --admin-only=true
> [standalone@embedded /] /subsystem=messaging:migrate
> {
> "outcome" => "failed",
> ...
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (SWSQE-1125) Update job parameters for jaeger
by Filip Brychta (Jira)
Filip Brychta created SWSQE-1125:
------------------------------------
Summary: Update job parameters for jaeger
Key: SWSQE-1125
URL: https://issues.redhat.com/browse/SWSQE-1125
Project: Kiali QE
Issue Type: QE Task
Reporter: Filip Brychta
Assignee: Filip Brychta
We are still using parameters for jaeger like:
JAEGER_OPERATOR_HUB=quay.io/maistra
JAEGER_OPERATOR_IMAGE=jaeger-rhel7-operator
JAEGER_OPERATOR_TAG=latest-qe
JAEGER_HUB=quay.io/maistra
JAEGER_TAG=latest-qe
We need to make it optional as it's not necessary when using OLM.
Remember to update default values and PR jobs.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years