June 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1846) RELAY2: delay shutting down bridge

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/JGRP-1846?page=com.atlassian.jira.plugin.... ] Dan Berindei updated JGRP-1846: ------------------------------- Description: A simple test that starts 2 sites x 2 nodes each and shuts them down in order shows a 1 second delay when shutting down the last node in the first site (B): {code:java} public void testCoordinatorShutdown() throws Exception { a=createNode(LON, "A", LON_CLUSTER, null); b=createNode(LON, "B", LON_CLUSTER, null); x=createNode(SFO, "X", SFO_CLUSTER, null); y=createNode(SFO, "Y", SFO_CLUSTER, null); Util.waitUntilAllChannelsHaveSameSize(10000, 100, a, b); Util.waitUntilAllChannelsHaveSameSize(10000, 100, x, y); waitForBridgeView(2, 20000, 100, a, x); a.close(); Util.waitUntilAllChannelsHaveSameSize(10000, 100, b); b.close(); waitForBridgeView(1, 20000, 100, x); x.close(); y.close(); } {code} And the relevant logs: {noformat} 13:51:30,017 DEBUG (Timer-2,sfo-cluster,X:) [GMS] _X:sfo: installing view [_A:lon|1] (2) [_A:lon, _X:sfo] 13:51:30,028 DEBUG (Incoming-2,global,_X:sfo:) [GMS] _X:sfo: installing view [_X:sfo|2] (1) [_X:sfo] 13:51:30,046 TRACE (Timer-2,lon-cluster,B:) [SHARED_LOOPBACK] _B:lon: sending msg to _X:sfo, src=_B:lon, headers are GMS: GmsHeader[JOIN_REQ]: mbr=_B:lon, UNICAST3: DATA, seqno=1, first, SHARED_LOOPBACK: [cluster_name=global] 13:51:31,046 TRACE (Timer-2,global,_B:lon:) [SHARED_LOOPBACK] _B:lon: sending msg to _X:sfo, src=_B:lon, headers are GMS: GmsHeader[JOIN_REQ]: mbr=_B:lon, UNICAST3: DATA, seqno=1, first, SHARED_LOOPBACK: [cluster_name=global] 13:51:31,099 DEBUG (Incoming-2,global,_X:sfo:) [GMS] _X:sfo: installing view [_X:sfo|3] (2) [_X:sfo, _B:lon] {noformat} Note that while this happens on a background timer thread, the shutdown is delayed nonetheless because {{TP.destroy()}} waits at least 500ms for all the timer threads to finish ({{TimeScheduler3.stopRunning()}}. Perhaps that should change as well, so that timer threads are interrupted and finish immediately. was: A simple test that starts 2 sites x 2 nodes each and shuts them down in order shows a 1 second delay when shutting down the last node in the first site (B): public void testCoordinatorShutdown() throws Exception { a=createNode(LON, "A", LON_CLUSTER, null); b=createNode(LON, "B", LON_CLUSTER, null); x=createNode(SFO, "X", SFO_CLUSTER, null); y=createNode(SFO, "Y", SFO_CLUSTER, null); Util.waitUntilAllChannelsHaveSameSize(10000, 100, a, b); Util.waitUntilAllChannelsHaveSameSize(10000, 100, x, y); waitForBridgeView(2, 20000, 100, a, x); a.close(); Util.waitUntilAllChannelsHaveSameSize(10000, 100, b); b.close(); waitForBridgeView(1, 20000, 100, x); x.close(); y.close(); } And the relevant logs: 13:51:30,017 DEBUG (Timer-2,sfo-cluster,X:) [GMS] _X:sfo: installing view [_A:lon|1] (2) [_A:lon, _X:sfo] 13:51:30,028 DEBUG (Incoming-2,global,_X:sfo:) [GMS] _X:sfo: installing view [_X:sfo|2] (1) [_X:sfo] 13:51:30,046 TRACE (Timer-2,lon-cluster,B:) [SHARED_LOOPBACK] _B:lon: sending msg to _X:sfo, src=_B:lon, headers are GMS: GmsHeader[JOIN_REQ]: mbr=_B:lon, UNICAST3: DATA, seqno=1, first, SHARED_LOOPBACK: [cluster_name=global] 13:51:31,046 TRACE (Timer-2,global,_B:lon:) [SHARED_LOOPBACK] _B:lon: sending msg to _X:sfo, src=_B:lon, headers are GMS: GmsHeader[JOIN_REQ]: mbr=_B:lon, UNICAST3: DATA, seqno=1, first, SHARED_LOOPBACK: [cluster_name=global] 13:51:31,099 DEBUG (Incoming-2,global,_X:sfo:) [GMS] _X:sfo: installing view [_X:sfo|3] (2) [_X:sfo, _B:lon] Note that while this happens on a background timer thread, the shutdown is delayed nonetheless because {{TP.destroy()}} waits at least 500ms for all the timer threads to finish ({{TimeScheduler3.stopRunning()}}. Perhaps that should change as well, so that timer threads are interrupted and finish immediately. > RELAY2: delay shutting down bridge > ---------------------------------- > > Key: JGRP-1846 > URL: https://issues.jboss.org/browse/JGRP-1846 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.5 > Reporter: Dan Berindei > Assignee: Bela Ban > > A simple test that starts 2 sites x 2 nodes each and shuts them down in order shows a 1 second delay when shutting down the last node in the first site (B): > {code:java} > public void testCoordinatorShutdown() throws Exception { > a=createNode(LON, "A", LON_CLUSTER, null); > b=createNode(LON, "B", LON_CLUSTER, null); > x=createNode(SFO, "X", SFO_CLUSTER, null); > y=createNode(SFO, "Y", SFO_CLUSTER, null); > Util.waitUntilAllChannelsHaveSameSize(10000, 100, a, b); > Util.waitUntilAllChannelsHaveSameSize(10000, 100, x, y); > waitForBridgeView(2, 20000, 100, a, x); > a.close(); > Util.waitUntilAllChannelsHaveSameSize(10000, 100, b); > b.close(); > waitForBridgeView(1, 20000, 100, x); > x.close(); > y.close(); > } > {code} > And the relevant logs: > {noformat} > 13:51:30,017 DEBUG (Timer-2,sfo-cluster,X:) [GMS] _X:sfo: installing view [_A:lon|1] (2) [_A:lon, _X:sfo] > 13:51:30,028 DEBUG (Incoming-2,global,_X:sfo:) [GMS] _X:sfo: installing view [_X:sfo|2] (1) [_X:sfo] > 13:51:30,046 TRACE (Timer-2,lon-cluster,B:) [SHARED_LOOPBACK] _B:lon: sending msg to _X:sfo, src=_B:lon, headers are GMS: GmsHeader[JOIN_REQ]: mbr=_B:lon, UNICAST3: DATA, seqno=1, first, SHARED_LOOPBACK: [cluster_name=global] > 13:51:31,046 TRACE (Timer-2,global,_B:lon:) [SHARED_LOOPBACK] _B:lon: sending msg to _X:sfo, src=_B:lon, headers are GMS: GmsHeader[JOIN_REQ]: mbr=_B:lon, UNICAST3: DATA, seqno=1, first, SHARED_LOOPBACK: [cluster_name=global] > 13:51:31,099 DEBUG (Incoming-2,global,_X:sfo:) [GMS] _X:sfo: installing view [_X:sfo|3] (2) [_X:sfo, _B:lon] > {noformat} > Note that while this happens on a background timer thread, the shutdown is delayed nonetheless because {{TP.destroy()}} waits at least 500ms for all the timer threads to finish ({{TimeScheduler3.stopRunning()}}. Perhaps that should change as well, so that timer threads are interrupted and finish immediately. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-1846) RELAY2: delay shutting down bridge

by Dan Berindei (JIRA)

Dan Berindei created JGRP-1846: ---------------------------------- Summary: RELAY2: delay shutting down bridge Key: JGRP-1846 URL: https://issues.jboss.org/browse/JGRP-1846 Project: JGroups Issue Type: Bug Affects Versions: 3.5 Reporter: Dan Berindei Assignee: Bela Ban A simple test that starts 2 sites x 2 nodes each and shuts them down in order shows a 1 second delay when shutting down the last node in the first site (B): public void testCoordinatorShutdown() throws Exception { a=createNode(LON, "A", LON_CLUSTER, null); b=createNode(LON, "B", LON_CLUSTER, null); x=createNode(SFO, "X", SFO_CLUSTER, null); y=createNode(SFO, "Y", SFO_CLUSTER, null); Util.waitUntilAllChannelsHaveSameSize(10000, 100, a, b); Util.waitUntilAllChannelsHaveSameSize(10000, 100, x, y); waitForBridgeView(2, 20000, 100, a, x); a.close(); Util.waitUntilAllChannelsHaveSameSize(10000, 100, b); b.close(); waitForBridgeView(1, 20000, 100, x); x.close(); y.close(); } And the relevant logs: 13:51:30,017 DEBUG (Timer-2,sfo-cluster,X:) [GMS] _X:sfo: installing view [_A:lon|1] (2) [_A:lon, _X:sfo] 13:51:30,028 DEBUG (Incoming-2,global,_X:sfo:) [GMS] _X:sfo: installing view [_X:sfo|2] (1) [_X:sfo] 13:51:30,046 TRACE (Timer-2,lon-cluster,B:) [SHARED_LOOPBACK] _B:lon: sending msg to _X:sfo, src=_B:lon, headers are GMS: GmsHeader[JOIN_REQ]: mbr=_B:lon, UNICAST3: DATA, seqno=1, first, SHARED_LOOPBACK: [cluster_name=global] 13:51:31,046 TRACE (Timer-2,global,_B:lon:) [SHARED_LOOPBACK] _B:lon: sending msg to _X:sfo, src=_B:lon, headers are GMS: GmsHeader[JOIN_REQ]: mbr=_B:lon, UNICAST3: DATA, seqno=1, first, SHARED_LOOPBACK: [cluster_name=global] 13:51:31,099 DEBUG (Incoming-2,global,_X:sfo:) [GMS] _X:sfo: installing view [_X:sfo|3] (2) [_X:sfo, _B:lon] Note that while this happens on a background timer thread, the shutdown is delayed nonetheless because {{TP.destroy()}} waits at least 500ms for all the timer threads to finish ({{TimeScheduler3.stopRunning()}}. Perhaps that should change as well, so that timer threads are interrupted and finish immediately. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-465) Attribute check-for-live-server must set on live server to faillback

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-465?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on WFLY-465: ---------------------------------------------- Nikoleta Ziakova <nziakova(a)redhat.com> changed the Status of [bug 908261|https://bugzilla.redhat.com/show_bug.cgi?id=908261] from ON_QA to MODIFIED > Attribute check-for-live-server must set on live server to faillback > -------------------------------------------------------------------- > > Key: WFLY-465 > URL: https://issues.jboss.org/browse/WFLY-465 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JMS > Reporter: Miroslav Novak > Assignee: Jeff Mesnil > Fix For: 8.2.0.CR1 > > Attachments: standalone-full-ha-backup.xml, standalone-full-ha-live.xml > > > When there is live/backup pair with replicated journal then it should be sufficient to set attribute "check-for-live-server" in messaging subsystem only on backup to force backup server to shutdown when live server comes alive again. Problem is this won't happen. > Only when attribute "check-for-live-server" is set on live server then failback is successful (backup shutdown itself) > It's not well documented where "check-for-live-server" should be set in HornetQ project documentation: > http://docs.jboss.org/hornetq/2.3.0.CR1/docs/user-manual/html_single/inde... > This issue was hit with EAP 6.1.0.DR2 (HQ 2.3.0.CR1). -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-297) The release procedure should validate there are no snapshot dependencies with the enforcer plugin

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-297?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer reopened DROOLS-297: ------------------------------------------- > The release procedure should validate there are no snapshot dependencies with the enforcer plugin > ------------------------------------------------------------------------------------------------- > > Key: DROOLS-297 > URL: https://issues.jboss.org/browse/DROOLS-297 > Project: Drools > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > > Apparently, we've been releasing jars which have snapshot dependencies (non-timestamped). For example drools-wb-jcr2vfs-migration-core 6.0.0.CR4 depends on 5.5.1-SNAPSHOT. Why Nexus's validation no longer prevents this is beyond me. > Anyway, we need to prevent this. Luckily the enforcer plugin has a rule to validate this: > http://maven.apache.org/enforcer/enforcer-rules/requireReleaseVersion.html > During normal development this rule shouldn't be active, as jbpm depends on a drools snapshot etc. > But during a release procedure, it must be executed once. For example, after changing the version and before deploying them. Or as part of the actual deploy build - whatever works best. > One way would be to put it in the release profile "jboss-release", similar to what the jboss-parent pom does (which we extend): > https://github.com/jboss/jboss-parent-pom/blob/master/pom.xml#L700 > But I strongly dislike the use of profiles... -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-297) The release procedure should validate there are no snapshot dependencies with the enforcer plugin

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-297?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer commented on DROOLS-297: ----------------------------------------------- This is not yet something automatically. When releasing I am sure we are not working any more with SNAPSHOTS, but this is a manual approximation. I will reopen this JIRA until we have an automated solution. > The release procedure should validate there are no snapshot dependencies with the enforcer plugin > ------------------------------------------------------------------------------------------------- > > Key: DROOLS-297 > URL: https://issues.jboss.org/browse/DROOLS-297 > Project: Drools > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > > Apparently, we've been releasing jars which have snapshot dependencies (non-timestamped). For example drools-wb-jcr2vfs-migration-core 6.0.0.CR4 depends on 5.5.1-SNAPSHOT. Why Nexus's validation no longer prevents this is beyond me. > Anyway, we need to prevent this. Luckily the enforcer plugin has a rule to validate this: > http://maven.apache.org/enforcer/enforcer-rules/requireReleaseVersion.html > During normal development this rule shouldn't be active, as jbpm depends on a drools snapshot etc. > But during a release procedure, it must be executed once. For example, after changing the version and before deploying them. Or as part of the actual deploy build - whatever works best. > One way would be to put it in the release profile "jboss-release", similar to what the jboss-parent pom does (which we extend): > https://github.com/jboss/jboss-parent-pom/blob/master/pom.xml#L700 > But I strongly dislike the use of profiles... -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3462) wildfly host controller reading the host.xml from namespace version 1.5 will fail

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3462?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3462: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1105522|https://bugzilla.redhat.com/show_bug.cgi?id=1105522] from MODIFIED to POST > wildfly host controller reading the host.xml from namespace version 1.5 will fail > --------------------------------------------------------------------------------- > > Key: WFLY-3462 > URL: https://issues.jboss.org/browse/WFLY-3462 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 9.0.0.CR1 > Reporter: Tom Fonteyne > Assignee: Tom Fonteyne > > current wildfly fails to load host.xml with namespace 1.5 -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3461) wildfly 8.x host controller reading the host.xml from namespace version 1.5 will fail

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3461?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3461: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1105522|https://bugzilla.redhat.com/show_bug.cgi?id=1105522] from MODIFIED to POST > wildfly 8.x host controller reading the host.xml from namespace version 1.5 will fail > ------------------------------------------------------------------------------------- > > Key: WFLY-3461 > URL: https://issues.jboss.org/browse/WFLY-3461 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.2.0.CR1 > Reporter: Tom Fonteyne > Assignee: Tom Fonteyne > > current wildfly fails to load host.xml with namespace 1.5 -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-471) Remove repository jboss-deprecated

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-471?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer resolved DROOLS-471. ------------------------------------------- Resolution: Done > Remove repository jboss-deprecated > ---------------------------------- > > Key: DROOLS-471 > URL: https://issues.jboss.org/browse/DROOLS-471 > Project: Drools > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 6.1.0.Beta2 > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > > 1) In kie-parent-metadata's pom.xml, remove the repository jboss-deprecated: > {code} > <repository> > <id>jboss-deprecated</id> > <name>JBoss Deprecated</name> > <url>https://repository.jboss.org/nexus/content/repositories/deprecated/</url> > <releases> > <enabled>true</enabled> > <updatePolicy>never</updatePolicy> > </releases> > <snapshots> > <enabled>false</enabled> > </snapshots> > </repository> > {code} > https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/pom.... > 2) remove your local repository > 3) Do a mvn-all.sh -Dfull clean install > If it works, commit the change. > If it doesn't, make a list of dependencies that are still coming from the jboss-deprecated repository and make for each dependency a JIRA (or Bugzilla) issue calling to remove it. Tell the module owners who use those deprecated dependencies about the JIRA/BZ and ask them to remove the deprecated dependency. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-471) Remove repository jboss-deprecated

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-471?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer closed DROOLS-471. ----------------------------------------- > Remove repository jboss-deprecated > ---------------------------------- > > Key: DROOLS-471 > URL: https://issues.jboss.org/browse/DROOLS-471 > Project: Drools > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 6.1.0.Beta2 > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > > 1) In kie-parent-metadata's pom.xml, remove the repository jboss-deprecated: > {code} > <repository> > <id>jboss-deprecated</id> > <name>JBoss Deprecated</name> > <url>https://repository.jboss.org/nexus/content/repositories/deprecated/</url> > <releases> > <enabled>true</enabled> > <updatePolicy>never</updatePolicy> > </releases> > <snapshots> > <enabled>false</enabled> > </snapshots> > </repository> > {code} > https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/pom.... > 2) remove your local repository > 3) Do a mvn-all.sh -Dfull clean install > If it works, commit the change. > If it doesn't, make a list of dependencies that are still coming from the jboss-deprecated repository and make for each dependency a JIRA (or Bugzilla) issue calling to remove it. Tell the module owners who use those deprecated dependencies about the JIRA/BZ and ask them to remove the deprecated dependency. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-471) Remove repository jboss-deprecated

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-471?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer commented on DROOLS-471: ----------------------------------------------- done and tested > Remove repository jboss-deprecated > ---------------------------------- > > Key: DROOLS-471 > URL: https://issues.jboss.org/browse/DROOLS-471 > Project: Drools > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 6.1.0.Beta2 > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > > 1) In kie-parent-metadata's pom.xml, remove the repository jboss-deprecated: > {code} > <repository> > <id>jboss-deprecated</id> > <name>JBoss Deprecated</name> > <url>https://repository.jboss.org/nexus/content/repositories/deprecated/</url> > <releases> > <enabled>true</enabled> > <updatePolicy>never</updatePolicy> > </releases> > <snapshots> > <enabled>false</enabled> > </snapshots> > </repository> > {code} > https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/pom.... > 2) remove your local repository > 3) Do a mvn-all.sh -Dfull clean install > If it works, commit the change. > If it doesn't, make a list of dependencies that are still coming from the jboss-deprecated repository and make for each dependency a JIRA (or Bugzilla) issue calling to remove it. Tell the module owners who use those deprecated dependencies about the JIRA/BZ and ask them to remove the deprecated dependency. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2014