[JBoss JIRA] (AS7-2673) CLI shutdown * operation (kills domain controller first, beheads host controllers)
by mark yarborough (Created) (JIRA)
CLI shutdown * operation (kills domain controller first, beheads host controllers)
----------------------------------------------------------------------------------
Key: AS7-2673
URL: https://issues.jboss.org/browse/AS7-2673
Project: Application Server 7
Issue Type: Bug
Components: CLI
Affects Versions: 7.1.0.Alpha1
Reporter: mark yarborough
Assignee: Alexey Loubyansky
Priority: Trivial
>From the CLI with a domain controller and two host controllers running, using wildcard command intended to shut down everything:
[domain@localhost:9999 host] cd ..
[domain@localhost:9999 /] ls host
host2-9 host3 master
[domain@localhost:9999 /] ./host=*:shutdown
{"outcome" => "success"}
[domain@localhost:9999 /] ls
[domain@localhost:9999 /]
Success is reported, and we're no longer connected to a domain controller. A follow up check reveals that the domain controller (host=master) was shutdown, but the host controllers (host2-9 and host3) are still up and now searching for the missing domain controller:
<snippet from host3 console>
[Host Controller] 20:47:07,351 WARN [org.jboss.as.domain.controller] (Thread-14) Could not connect to remote domain controller 127.0.0.1:9999
[Host Controller] 20:47:22,357 WARN [org.jboss.as.domain.controller] (Thread-14) Could not connect to remote domain controller 127.0.0.1:9999
[Host Controller] 20:47:37,364 WARN [org.jboss.as.domain.controller] (Thread-14) Could not connect to remote domain controller 127.0.0.1:9999
[Host Controller] 20:47:52,370 WARN [org.jboss.as.domain.controller] (Thread-14) Could not connect to remote domain controller 127.0.0.1:9999
It appears that the DC was shutdown first, so no communication path the HCs, so they were not shutdown. Perhaps the wildcard should be disallowed for the shutdown operation, or intelligence added to shutdown the DC last... Just wanted to let you know.
Running something called jboss-as-7.1.0.Alpha2-SNAPSHOT downloaded by Rich Raposa for a GLS class around 10-Nov-2011. I chose "Affects Version" because that was the closest on the list...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-4140) Change distributtion of -Dmcast through testsuite
by Pavel Janousek (JIRA)
[ https://issues.jboss.org/browse/AS7-4140?page=com.atlassian.jira.plugin.s... ]
Pavel Janousek commented on AS7-4140:
-------------------------------------
HornetQ mcast address is hard-coded now only - can't be configured. Mirek Novak knows more info if needed - JIRAs already filled - JBPAPP-8336.
Only in configuration standalone-full-ha.xml is issue visible.
> Change distributtion of -Dmcast through testsuite
> -------------------------------------------------
>
> Key: AS7-4140
> URL: https://issues.jboss.org/browse/AS7-4140
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Test Suite
> Affects Versions: 7.1.1.Final
> Reporter: Pavel Janousek
> Assignee: Richard Achmatowicz
> Priority: Blocker
> Fix For: 7.1.2.Final
>
>
> Please change present behavior.
> We need to define only one property -Dmcast (for ex., the name doesn't matter now) as command line parameter - this multicast address is needed to be distributed to every subsystem which manages any multicast communication. It is needed to be unique in every subsystem - JGroups, HornetQ etc. because we must avoid to interfere each other => port assignation must be unique for every a such component.
> This change is needed in both - IPV4 and IPv6...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-4140) Change distributtion of -Dmcast through testsuite
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/AS7-4140?page=com.atlassian.jira.plugin.s... ]
Richard Achmatowicz commented on AS7-4140:
------------------------------------------
We should already be able to use one multicast address (-Dmcast) as long as all of the multicast channels use different ports, which they do at the moment. I'm checking with Andy Taylor for the HornetQ configuration in standalone-full-ha.xml, as there are multicast addresses used there too which have been temporarily overlooked.
The way things work at the moment, you may specify -Dmcast, -Dmcast.jgroupsDiag and -Dmcast.modcluster. If you specify only -Dmcast, the remaining addresses use the value of -Dmcast.
I have tested:
1. loopback configuration
{noformat}
./integration-tests.sh -Dipv6
{noformat}
which assigns -Dnode=::1, -Dnode1=::1 and -Dmcast=ff01::1. To use this loopback-based configuration, you need to set a static multicast route on lo, using
{noformat}
# as sudo or root
# route -A inet6 add ff01::/32 dev lo
{noformat}
2. non-loopback configuration
{noformat}
./integration-tests.sh -Dnode0=<a global mcast address> -Dnode1=<another global mcast address> -Dmcast=<a global mcast address>
e.g.
./integration-tests.sh -Dnode0=<a global mcast address> -Dnode1=<another global mcast address> -Dmcast=ff0e::1
{noformat}
I did see an issue with this on Friday, but it may be local to my mamchine. This configuration should work for standalone.xml, standalone-full.xml and standalone-ha.xml.
The configuration standalone-full-ha.xml needs some adjustment due to HornetQ mcast addresses as mentioned earlier.
> Change distributtion of -Dmcast through testsuite
> -------------------------------------------------
>
> Key: AS7-4140
> URL: https://issues.jboss.org/browse/AS7-4140
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Test Suite
> Affects Versions: 7.1.1.Final
> Reporter: Pavel Janousek
> Assignee: Richard Achmatowicz
> Priority: Blocker
> Fix For: 7.1.2.Final
>
>
> Please change present behavior.
> We need to define only one property -Dmcast (for ex., the name doesn't matter now) as command line parameter - this multicast address is needed to be distributed to every subsystem which manages any multicast communication. It is needed to be unique in every subsystem - JGroups, HornetQ etc. because we must avoid to interfere each other => port assignation must be unique for every a such component.
> This change is needed in both - IPV4 and IPv6...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-4140) Change distributtion of -Dmcast through testsuite
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/AS7-4140?page=com.atlassian.jira.plugin.s... ]
Richard Achmatowicz edited comment on AS7-4140 at 3/12/12 11:52 AM:
--------------------------------------------------------------------
We should already be able to use one multicast address (-Dmcast) as long as all of the multicast channels use different ports, which they do at the moment. I'm checking with Andy Taylor for the HornetQ configuration in standalone-full-ha.xml, as there are multicast addresses used there too which have been temporarily overlooked.
The way things work at the moment, you may specify -Dmcast, -Dmcast.jgroupsDiag and -Dmcast.modcluster. If you specify only -Dmcast, the remaining addresses use the value of -Dmcast.
I have tested:
1. loopback configuration
{noformat}
./integration-tests.sh -Dipv6
{noformat}
which assigns -Dnode=::1, -Dnode1=::1 and -Dmcast=ff01::1. To use this loopback-based configuration, you need to set a static multicast route on lo, using
{noformat}
# as sudo or root
# route -A inet6 add ff01::/32 dev lo
{noformat}
2. non-loopback configuration
{noformat}
./integration-tests.sh -Dnode0=<a global mcast address> -Dnode1=<another global mcast address> -Dmcast=<a global mcast address>
e.g.
./integration-tests.sh -Dnode0=<a global mcast address> -Dnode1=<another global mcast address> -Dmcast=ff0e::1
{noformat}
I did see an issue with this on Friday, but it may be local to my machine. This configuration should work for standalone.xml, standalone-full.xml and standalone-ha.xml.
The configuration standalone-full-ha.xml needs some adjustment due to HornetQ mcast addresses as mentioned earlier.
was (Author: rachmato):
We should already be able to use one multicast address (-Dmcast) as long as all of the multicast channels use different ports, which they do at the moment. I'm checking with Andy Taylor for the HornetQ configuration in standalone-full-ha.xml, as there are multicast addresses used there too which have been temporarily overlooked.
The way things work at the moment, you may specify -Dmcast, -Dmcast.jgroupsDiag and -Dmcast.modcluster. If you specify only -Dmcast, the remaining addresses use the value of -Dmcast.
I have tested:
1. loopback configuration
{noformat}
./integration-tests.sh -Dipv6
{noformat}
which assigns -Dnode=::1, -Dnode1=::1 and -Dmcast=ff01::1. To use this loopback-based configuration, you need to set a static multicast route on lo, using
{noformat}
# as sudo or root
# route -A inet6 add ff01::/32 dev lo
{noformat}
2. non-loopback configuration
{noformat}
./integration-tests.sh -Dnode0=<a global mcast address> -Dnode1=<another global mcast address> -Dmcast=<a global mcast address>
e.g.
./integration-tests.sh -Dnode0=<a global mcast address> -Dnode1=<another global mcast address> -Dmcast=ff0e::1
{noformat}
I did see an issue with this on Friday, but it may be local to my mamchine. This configuration should work for standalone.xml, standalone-full.xml and standalone-ha.xml.
The configuration standalone-full-ha.xml needs some adjustment due to HornetQ mcast addresses as mentioned earlier.
> Change distributtion of -Dmcast through testsuite
> -------------------------------------------------
>
> Key: AS7-4140
> URL: https://issues.jboss.org/browse/AS7-4140
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Test Suite
> Affects Versions: 7.1.1.Final
> Reporter: Pavel Janousek
> Assignee: Richard Achmatowicz
> Priority: Blocker
> Fix For: 7.1.2.Final
>
>
> Please change present behavior.
> We need to define only one property -Dmcast (for ex., the name doesn't matter now) as command line parameter - this multicast address is needed to be distributed to every subsystem which manages any multicast communication. It is needed to be unique in every subsystem - JGroups, HornetQ etc. because we must avoid to interfere each other => port assignation must be unique for every a such component.
> This change is needed in both - IPV4 and IPv6...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-4140) Change distributtion of -Dmcast through testsuite
by Pavel Janousek (JIRA)
[ https://issues.jboss.org/browse/AS7-4140?page=com.atlassian.jira.plugin.s... ]
Pavel Janousek moved JBPAPP-8421 to AS7-4140:
---------------------------------------------
Project: Application Server 7 (was: JBoss Enterprise Application Platform)
Key: AS7-4140 (was: JBPAPP-8421)
Workflow: GIT Pull Request workflow (was: jira)
Affects Version/s: 7.1.1.Final
(was: EAP 6.0.0 ER 4)
Component/s: Test Suite
(was: Testsuite)
Security: (was: JBoss Internal)
Fix Version/s: 7.1.2.Final
(was: EAP 6.0.0 ER 4)
Docs QE Status: (was: NEW)
> Change distributtion of -Dmcast through testsuite
> -------------------------------------------------
>
> Key: AS7-4140
> URL: https://issues.jboss.org/browse/AS7-4140
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Test Suite
> Affects Versions: 7.1.1.Final
> Reporter: Pavel Janousek
> Assignee: Richard Achmatowicz
> Priority: Blocker
> Fix For: 7.1.2.Final
>
>
> Please change present behavior.
> We need to define only one property -Dmcast (for ex., the name doesn't matter now) as command line parameter - this multicast address is needed to be distributed to every subsystem which manages any multicast communication. It is needed to be unique in every subsystem - JGroups, HornetQ etc. because we must avoid to interfere each other => port assignation must be unique for every a such component.
> This change is needed in both - IPV4 and IPv6...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] Created: (AS7-1753) Intermittent failure in CompositeOperationHandlerUnitTestCase testRestartRequired
by Brian Stansberry (JIRA)
Intermittent failure in CompositeOperationHandlerUnitTestCase testRestartRequired
---------------------------------------------------------------------------------
Key: AS7-1753
URL: https://issues.jboss.org/browse/AS7-1753
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 7.1.0.Alpha1
This pops up occasionally
<testcase time="0.203" classname="org.jboss.as.controller.CompositeOperationHandlerUnitTestCase" name="testRestartRequired">
<failure message="expected:<[restart-requir]ed> but was:<[undefin]ed>" type="org.junit.ComparisonFailure">org.junit.ComparisonFailure: expected:<[restart-requir]ed> but was:<[undefin]ed>
at org.junit.Assert.assertEquals(Assert.java:123)
at org.junit.Assert.assertEquals(Assert.java:145)
at org.jboss.as.controller.CompositeOperationHandlerUnitTestCase.testRestartRequired(CompositeOperationHandlerUnitTestCase.java:496)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:172)
at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:104)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:70)
</failure>
<system-out>========= New Test
{
"outcome" => "success",
"result" => {
"step-1" => {
"outcome" => "success",
"result" => 1,
"response-headers" => {
"runtime-update-skipped" => true,
"operation-requires-restart" => true
}
},
"step-2" => {
"outcome" => "success",
"result" => 2
}
}
}
======================
</system-out>
</testcase>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month