November 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2395) LOCAL_PING fails when 2 nodes start at the same time

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2395?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2395 at 11/6/19 8:52 AM: --------------------------------------------------------- Hmm, these things cannot be controlled; if multiple nodes are started without an existing coord, then (like with UDP:PING) LOCAL_PING (and SHARED_LOOPBACK_PING) may end up doing discovery at exactly the same time and become singletons, only to be merged later. So, in that sense, both LOCAL_PING and … [View More]SHARED_LOOPBACK_PING mimic the real world (UDP & PING). However, I *can* change this: * The first node to register for a given cluster becomes _coordinator_ (registration needs to be atomic) * When the coord leaves, the next-in-line becomes coord (this is atomic, too, wrt gets) * On a view, we make sure that the first node in the view is the coord (also in the {{discovery}} map). This is because of JGRP-2381. * This _may_ fail when a user has installed a custom view generation policy, need to think about this The important thing here is that we need to have a coord after the first member registers. After that, we adjust the {{discovery}} map (who is coord) based on view changes. A given is that there's always only *one* coord for a given cluster in the {{discovery}} map. WDYT? was (Author: belaban): Hmm, these things cannot be controlled; if multiple nodes are started without an existing coord, then (like with UDP:PING) LOCAL_PING (and SHARED_LOOPBACK_PING) may end up doing discovery at exactly the same time and become singletons, only to be merged later. So, in that sense, both LOCAL_PING and SHARED_LOOPBACK_PING mimic the real world (UDP & PING). However, I *can* change this: * The first node to register for a given cluster becomes _coordinator_ (registration needs to be atomic) * When the coord leaves, the next-in-line becomes coord (this is atomic, too, wrt gets) * On a view, we make sure that the first node in the view is the coord (also in the {{discovery}} map) * This _may_ fail when a user has installed a custom view generation policy, need to think about this The important thing here is that we need to have a coord after the first member registers. After that, we adjust the {{discovery}} map (who is coord) based on view changes. A given is that there's always only *one* coord for a given cluster in the {{discovery}} map. WDYT? > LOCAL_PING fails when 2 nodes start at the same time > ---------------------------------------------------- > > Key: JGRP-2395 > URL: https://issues.jboss.org/browse/JGRP-2395 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.1.6 > Reporter: Dan Berindei > Assignee: Bela Ban > Priority: Major > Fix For: 4.1.8 > > > We have a test that starts 2 nodes in parallel ({{ConcurrentStartTest}} and it is randomly failing since we started using {{LOCAL_PING}}. > {noformat} > 01:02:11,930 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: discovery took 3 ms, members: 1 rsps (0 coords) [done] > 01:02:11,930 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: discovery took 3 ms, members: 1 rsps (0 coords) [done] > 01:02:11,931 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: could not determine coordinator from rsps 1 rsps (0 coords) [done] > 01:02:11,931 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: could not determine coordinator from rsps 1 rsps (0 coords) [done] > 01:02:11,931 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: nodes to choose new coord from are: [Test-NodeB-43694, Test-NodeA-29550] > 01:02:11,931 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: nodes to choose new coord from are: [Test-NodeB-43694, Test-NodeA-29550] > 01:02:11,931 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: I (Test-NodeB-43694) am the first of the nodes, will become coordinator > 01:02:11,931 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: I (Test-NodeA-29550) am not the first of the nodes, waiting for another client to become coordinator > 01:02:11,932 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: discovery took 0 ms, members: 1 rsps (0 coords) [done] > 01:02:11,932 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: could not determine coordinator from rsps 1 rsps (0 coords) [done] > 01:02:11,932 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: nodes to choose new coord from are: [Test-NodeB-43694, Test-NodeA-29550] > ... > 01:02:11,941 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: could not determine coordinator from rsps 1 rsps (0 coords) [done] > 01:02:11,941 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: nodes to choose new coord from are: [Test-NodeB-43694, Test-NodeA-29550] > 01:02:11,941 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: I (Test-NodeA-29550) am not the first of the nodes, waiting for another client to become coordinator > 01:02:11,942 WARN (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: too many JOIN attempts (10): becoming singleton > 01:02:11,942 DEBUG (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: installing view [Test-NodeA-29550|0] (1) [Test-NodeA-29550] > 01:02:11,977 DEBUG (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: created cluster (first member). My view is [Test-NodeB-43694|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl > 01:02:11,977 DEBUG (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: created cluster (first member). My view is [Test-NodeA-29550|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl > {noformat} > The problem seems to be that it takes longer for the coordinator to install the initial view and update {{LOCAL_PING}}'s {{PingData}} then it takes the other node to retry the discovery process 10 times. > In some cases there is no retry, because one node starts slightly faster, but it's not yet coordinator when the 2nd node does its discovery, and both nodes decide they should be coordinator: > {noformat} > 01:13:44,460 INFO (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-5386: no members discovered after 3 ms: creating cluster as first member > 01:13:44,463 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: discovery took 1 ms, members: 1 rsps (0 coords) [done] > 01:13:44,465 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: could not determine coordinator from rsps 1 rsps (0 coords) [done] > 01:13:44,465 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: nodes to choose new coord from are: [Test-NodeB-51165, Test-NodeA-5386] > 01:13:44,466 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: I (Test-NodeB-51165) am the first of the nodes, will become coordinator > 01:13:44,466 DEBUG (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: installing view [Test-NodeB-51165|0] (1) [Test-NodeB-51165] > 01:13:44,466 DEBUG (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-5386: installing view [Test-NodeA-5386|0] (1) [Test-NodeA-5386] > {noformat} > This second failure mode seems to go away if I move the {{discovery}} map access inside the {{synchronized}} block both in {{findMembers()}} and in {{down()}}. -- This message was sent by Atlassian Jira (v7.13.8#713008) [View Less]

5 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2395) LOCAL_PING fails when 2 nodes start at the same time

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2395?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2395 at 11/6/19 8:45 AM: --------------------------------------------------------- Hmm, these things cannot be controlled; if multiple nodes are started without an existing coord, then (like with UDP:PING) LOCAL_PING (and SHARED_LOOPBACK_PING) may end up doing discovery at exactly the same time and become singletons, only to be merged later. So, in that sense, both LOCAL_PING and … [View More]SHARED_LOOPBACK_PING mimic the real world (UDP & PING). However, I *can* change this: * The first node to register for a given cluster becomes _coordinator_ (registration needs to be atomic) * When the coord leaves, the next-in-line becomes coord (this is atomic, too, wrt gets) * On a view, we make sure that the first node in the view is the coord (also in the {{discovery}} map) * This _may_ fail when a user has installed a custom view generation policy, need to think about this The important thing here is that we need to have a coord after the first member registers. After that, we adjust the {{discovery}} map (who is coord) based on view changes. A given is that there's always only *one* coord for a given cluster in the {{discovery}} map. WDYT? was (Author: belaban): Hmm, these things cannot be controlled; if multiple nodes are started without an existing coord, then (like with UDP:PING) LOCAL_PING (and SHARED_LOOPBACK_PING) may end up doing discovery at exactly the same time and become singletons, only to be merged later. So, in that sense, both LOCAL_PING and SHARED_LOOPBACK_PING mimic the real world (UDP & PING). However, I *can* change this: * The first node to register for a given cluster becomes _coordinator_ (registration needs to be atomic) * When the coord leaves, the next-in-line becomes coord (this is atomic, too, wrt gets) * This _may_ fail when a user has installed a custom view generation policy, need to think about this WDYT? > LOCAL_PING fails when 2 nodes start at the same time > ---------------------------------------------------- > > Key: JGRP-2395 > URL: https://issues.jboss.org/browse/JGRP-2395 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.1.6 > Reporter: Dan Berindei > Assignee: Bela Ban > Priority: Major > Fix For: 4.1.8 > > > We have a test that starts 2 nodes in parallel ({{ConcurrentStartTest}} and it is randomly failing since we started using {{LOCAL_PING}}. > {noformat} > 01:02:11,930 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: discovery took 3 ms, members: 1 rsps (0 coords) [done] > 01:02:11,930 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: discovery took 3 ms, members: 1 rsps (0 coords) [done] > 01:02:11,931 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: could not determine coordinator from rsps 1 rsps (0 coords) [done] > 01:02:11,931 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: could not determine coordinator from rsps 1 rsps (0 coords) [done] > 01:02:11,931 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: nodes to choose new coord from are: [Test-NodeB-43694, Test-NodeA-29550] > 01:02:11,931 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: nodes to choose new coord from are: [Test-NodeB-43694, Test-NodeA-29550] > 01:02:11,931 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: I (Test-NodeB-43694) am the first of the nodes, will become coordinator > 01:02:11,931 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: I (Test-NodeA-29550) am not the first of the nodes, waiting for another client to become coordinator > 01:02:11,932 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: discovery took 0 ms, members: 1 rsps (0 coords) [done] > 01:02:11,932 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: could not determine coordinator from rsps 1 rsps (0 coords) [done] > 01:02:11,932 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: nodes to choose new coord from are: [Test-NodeB-43694, Test-NodeA-29550] > ... > 01:02:11,941 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: could not determine coordinator from rsps 1 rsps (0 coords) [done] > 01:02:11,941 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: nodes to choose new coord from are: [Test-NodeB-43694, Test-NodeA-29550] > 01:02:11,941 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: I (Test-NodeA-29550) am not the first of the nodes, waiting for another client to become coordinator > 01:02:11,942 WARN (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: too many JOIN attempts (10): becoming singleton > 01:02:11,942 DEBUG (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: installing view [Test-NodeA-29550|0] (1) [Test-NodeA-29550] > 01:02:11,977 DEBUG (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: created cluster (first member). My view is [Test-NodeB-43694|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl > 01:02:11,977 DEBUG (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: created cluster (first member). My view is [Test-NodeA-29550|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl > {noformat} > The problem seems to be that it takes longer for the coordinator to install the initial view and update {{LOCAL_PING}}'s {{PingData}} then it takes the other node to retry the discovery process 10 times. > In some cases there is no retry, because one node starts slightly faster, but it's not yet coordinator when the 2nd node does its discovery, and both nodes decide they should be coordinator: > {noformat} > 01:13:44,460 INFO (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-5386: no members discovered after 3 ms: creating cluster as first member > 01:13:44,463 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: discovery took 1 ms, members: 1 rsps (0 coords) [done] > 01:13:44,465 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: could not determine coordinator from rsps 1 rsps (0 coords) [done] > 01:13:44,465 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: nodes to choose new coord from are: [Test-NodeB-51165, Test-NodeA-5386] > 01:13:44,466 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: I (Test-NodeB-51165) am the first of the nodes, will become coordinator > 01:13:44,466 DEBUG (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: installing view [Test-NodeB-51165|0] (1) [Test-NodeB-51165] > 01:13:44,466 DEBUG (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-5386: installing view [Test-NodeA-5386|0] (1) [Test-NodeA-5386] > {noformat} > This second failure mode seems to go away if I move the {{discovery}} map access inside the {{synchronized}} block both in {{findMembers()}} and in {{down()}}. -- This message was sent by Atlassian Jira (v7.13.8#713008) [View Less]

5 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2395) LOCAL_PING fails when 2 nodes start at the same time

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2395?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2395: -------------------------------- Hmm, these things cannot be controlled; if multiple nodes are started without an existing coord, then (like with UDP:PING) LOCAL_PING (and SHARED_LOOPBACK_PING) may end up doing discovery at exactly the same time and become singletons, only to be merged later. So, in that sense, both LOCAL_PING and SHARED_LOOPBACK_PING mimic the real world (UDP &… [View More]amp; PING). However, I *can* change this: * The first node to register for a given cluster becomes _coordinator_ (registration needs to be atomic) * When the coord leaves, the next-in-line becomes coord (this is atomic, too, wrt gets) * This _may_ fail when a user has installed a custom view generation policy, need to think about this WDYT? > LOCAL_PING fails when 2 nodes start at the same time > ---------------------------------------------------- > > Key: JGRP-2395 > URL: https://issues.jboss.org/browse/JGRP-2395 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.1.6 > Reporter: Dan Berindei > Assignee: Bela Ban > Priority: Major > Fix For: 4.1.8 > > > We have a test that starts 2 nodes in parallel ({{ConcurrentStartTest}} and it is randomly failing since we started using {{LOCAL_PING}}. > {noformat} > 01:02:11,930 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: discovery took 3 ms, members: 1 rsps (0 coords) [done] > 01:02:11,930 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: discovery took 3 ms, members: 1 rsps (0 coords) [done] > 01:02:11,931 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: could not determine coordinator from rsps 1 rsps (0 coords) [done] > 01:02:11,931 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: could not determine coordinator from rsps 1 rsps (0 coords) [done] > 01:02:11,931 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: nodes to choose new coord from are: [Test-NodeB-43694, Test-NodeA-29550] > 01:02:11,931 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: nodes to choose new coord from are: [Test-NodeB-43694, Test-NodeA-29550] > 01:02:11,931 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: I (Test-NodeB-43694) am the first of the nodes, will become coordinator > 01:02:11,931 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: I (Test-NodeA-29550) am not the first of the nodes, waiting for another client to become coordinator > 01:02:11,932 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: discovery took 0 ms, members: 1 rsps (0 coords) [done] > 01:02:11,932 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: could not determine coordinator from rsps 1 rsps (0 coords) [done] > 01:02:11,932 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: nodes to choose new coord from are: [Test-NodeB-43694, Test-NodeA-29550] > ... > 01:02:11,941 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: could not determine coordinator from rsps 1 rsps (0 coords) [done] > 01:02:11,941 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: nodes to choose new coord from are: [Test-NodeB-43694, Test-NodeA-29550] > 01:02:11,941 TRACE (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: I (Test-NodeA-29550) am not the first of the nodes, waiting for another client to become coordinator > 01:02:11,942 WARN (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: too many JOIN attempts (10): becoming singleton > 01:02:11,942 DEBUG (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: installing view [Test-NodeA-29550|0] (1) [Test-NodeA-29550] > 01:02:11,977 DEBUG (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-43694: created cluster (first member). My view is [Test-NodeB-43694|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl > 01:02:11,977 DEBUG (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-29550: created cluster (first member). My view is [Test-NodeA-29550|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl > {noformat} > The problem seems to be that it takes longer for the coordinator to install the initial view and update {{LOCAL_PING}}'s {{PingData}} then it takes the other node to retry the discovery process 10 times. > In some cases there is no retry, because one node starts slightly faster, but it's not yet coordinator when the 2nd node does its discovery, and both nodes decide they should be coordinator: > {noformat} > 01:13:44,460 INFO (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-5386: no members discovered after 3 ms: creating cluster as first member > 01:13:44,463 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: discovery took 1 ms, members: 1 rsps (0 coords) [done] > 01:13:44,465 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: could not determine coordinator from rsps 1 rsps (0 coords) [done] > 01:13:44,465 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: nodes to choose new coord from are: [Test-NodeB-51165, Test-NodeA-5386] > 01:13:44,466 TRACE (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: I (Test-NodeB-51165) am the first of the nodes, will become coordinator > 01:13:44,466 DEBUG (ForkThread-2,ConcurrentStartTest:[]) [GMS] Test-NodeB-51165: installing view [Test-NodeB-51165|0] (1) [Test-NodeB-51165] > 01:13:44,466 DEBUG (ForkThread-1,ConcurrentStartTest:[]) [GMS] Test-NodeA-5386: installing view [Test-NodeA-5386|0] (1) [Test-NodeA-5386] > {noformat} > This second failure mode seems to go away if I move the {{discovery}} map access inside the {{synchronized}} block both in {{findMembers()}} and in {{down()}}. -- This message was sent by Atlassian Jira (v7.13.8#713008) [View Less]

5 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12718) Clustering: replicated-cache sampling errors

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-12718?page=com.atlassian.jira.plugin... ] Paul Ferraro commented on WFLY-12718: ------------------------------------- [~tommaso-borgato] Can you re-run these tests against this branch? https://github.com/pferraro/wildfly/tree/clustering This should restore the previous behavior for transactional SESSION granularity caches. > Clustering: replicated-cache sampling errors > -------------------------------------------- > > Key: … [View More]WFLY-12718 > URL: https://issues.jboss.org/browse/WFLY-12718 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 18.0.0.Final > Reporter: Tommasso Borgato > Assignee: Paul Ferraro > Priority: Blocker > > The issue is about replicated-cache in fail-over tests. > WildFly is started in clustered mode using a replicated cache for replicating HTTP session data across cluster nodes; all 4 nodes in the cluster are initialized with the following cli script: > {noformat} > embed-server --server-config=standalone-ha.xml > /subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcp) > /subsystem=infinispan/cache-container=web/replicated-cache=testRepl:add() > /subsystem=infinispan/cache-container=web/replicated-cache=testRepl/component=locking:write-attribute(name=isolation, value=REPEATABLE_READ) > /subsystem=infinispan/cache-container=web/replicated-cache=testRepl/component=transaction:write-attribute(name=mode, value=BATCH) > /subsystem=infinispan/cache-container=web/replicated-cache=testRepl/store=file:add() > /subsystem=infinispan/cache-container=web:write-attribute(name=default-cache, value=testRepl) > {noformat} > The test is run with wildfly-18.0.0.Final.zip; > The same tests run with version wildfly-17.0.1.Final.zip do not have any problem; > hence this looks like a regression; > As usual, we test that the serial value stored in the replicated cache is incremented at every call: when this is not true, we say we have a sampling error; > Here are the runs that exhibit this issue: > - **22.82% Fail Rate with WildFly-18 ** [eap-7.x-clustering-http-session-shutdown-repl#23|https://eap-qe-jenkins.r...] > - **0% Fail Rate with WildFly-17 ** [eap-7.x-clustering-http-session-shutdown-repl#24|https://eap-qe-jenkins.r...] > We also repeated the tests to make sure it can be reproduced: > - **22.75% Fail rate with WildFly-18 ** [eap-7.x-clustering-http-session-shutdown-repl#26|https://eap-qe-jenkins.r...] > - **0% Fail Rate with WildFly-17 ** [eap-7.x-clustering-http-session-shutdown-repl#25|https://eap-qe-jenkins.r...] -- This message was sent by Atlassian Jira (v7.13.8#713008) [View Less]

5 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-256) Duration of server configuration is not printed

by Yeray Borges (Jira)

[ https://issues.jboss.org/browse/WFWIP-256?page=com.atlassian.jira.plugin.... ] Yeray Borges reassigned WFWIP-256: ---------------------------------- Assignee: Yeray Borges (was: Jean Francois Denise) > Duration of server configuration is not printed > ----------------------------------------------- > > Key: WFWIP-256 > URL: https://issues.jboss.org/browse/WFWIP-256 > Project: WildFly WIP > Issue Type: Bug > … [View More]

5 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1395) Use HTTPS for JBoss artifact repository

by Jan Stourac (Jira)

[ https://issues.jboss.org/browse/JBJCA-1395?page=com.atlassian.jira.plugin... ] Jan Stourac resolved JBJCA-1395. -------------------------------- Resolution: Done MR has been merged into 1.4 branch. As such, this should be fixed in an upcoming {{1.4.19.Final}} release then. > Use HTTPS for JBoss artifact repository > --------------------------------------- > > Key: JBJCA-1395 > URL: https://issues.jboss.org/browse/JBJCA-1395 > … [View More]

5 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12766) Upgrade WildFly Common to 1.5.2.Final

by Yeray Borges (Jira)

Yeray Borges created WFLY-12766: ----------------------------------- Summary: Upgrade WildFly Common to 1.5.2.Final Key: WFLY-12766 URL: https://issues.jboss.org/browse/WFLY-12766 Project: WildFly Issue Type: Component Upgrade Reporter: Yeray Borges Assignee: Yeray Borges This dependency is brought in by wildfly-core into wildfly, however, we are still requiring it explicitly in wildfly because it … [View More]

5 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1395) Use HTTPS for JBoss artifact repository

by Jan Stourac (Jira)

[ https://issues.jboss.org/browse/JBJCA-1395?page=com.atlassian.jira.plugin... ] Jan Stourac commented on JBJCA-1395: ------------------------------------ Not sure what is correct state now as I've provided MR here https://github.com/ironjacamar/ironjacamar/pull/693. > Use HTTPS for JBoss artifact repository > --------------------------------------- > > Key: JBJCA-1395 > URL: https://issues.jboss.org/browse/JBJCA-1395 > Project: … [View More]

5 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1395) Use HTTPS for JBoss artifact repository

by Jan Stourac (Jira)

[ https://issues.jboss.org/browse/JBJCA-1395?page=com.atlassian.jira.plugin... ] Jan Stourac reassigned JBJCA-1395: ---------------------------------- Assignee: Jan Stourac > Use HTTPS for JBoss artifact repository > --------------------------------------- > > Key: JBJCA-1395 > URL: https://issues.jboss.org/browse/JBJCA-1395 > Project: IronJacamar > Issue Type: Bug > Components: Build > … [View More]

5 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1395) Use HTTPS for JBoss artifact repository

by Jan Stourac (Jira)

[ https://issues.jboss.org/browse/JBJCA-1395?page=com.atlassian.jira.plugin... ] Jan Stourac updated JBJCA-1395: ------------------------------- Git Pull Request: https://github.com/ironjacamar/ironjacamar/pull/693 > Use HTTPS for JBoss artifact repository > --------------------------------------- > > Key: JBJCA-1395 > URL: https://issues.jboss.org/browse/JBJCA-1395 > Project: IronJacamar > Issue Type: Bug > … [View More]

5 years, 4 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 November 2019