[JBoss JIRA] Created: (JBAS-9096) Management only domain mode
by Brian Stansberry (JIRA)
Management only domain mode
---------------------------
Key: JBAS-9096
URL: https://issues.jboss.org/browse/JBAS-9096
Project: JBoss Application Server
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: Domain Management
Reporter: Brian Stansberry
Fix For: 7.0.0.Beta4
See parent task for core concept.
With domain mode this is fairly simple. A host controller / domain controller is essentially a "management only" process. So implement this feature should be a simple matter of adding a command line flag that tells the process not to launch servers.
If the host is the master DC, we need to think through what the behavior should be if a remote host tries to register.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] Created: (JBAS-8135) By default use a common identifier anywhere a server "id" notion is exposed in the configuration
by Brian Stansberry (JIRA)
By default use a common identifier anywhere a server "id" notion is exposed in the configuration
------------------------------------------------------------------------------------------------
Key: JBAS-8135
URL: https://jira.jboss.org/browse/JBAS-8135
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 7.0.0.M1
This JIRA is based on feedback we received after the Andiamo BOF at JBoss World 2010:
>> * JBoss Transactions, jvm-route, jboss messaging all require a
>> unique identifier for them to behave properly in a clustered
>> environment. I would like one unique identifier for each server
>> configuration and for all services that need a unique identifier
>> to reference it by default. Then I don't have to worry about
>> unique identifiers when creating new servers.
(The jboss messaging bit is out of date with respect to AS 7, which will use HornetQ and thus has no ServerPeerId configuration required. But the basic point is spot-on.)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] Created: (AS7-895) Intermittent issues pushing content for deployment "full-replace" to slave host
by Brian Stansberry (JIRA)
Intermittent issues pushing content for deployment "full-replace" to slave host
-------------------------------------------------------------------------------
Key: AS7-895
URL: https://issues.jboss.org/browse/AS7-895
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 7.0.0.CR1
Intermittently seeing this:
java.lang.AssertionError: "Operation was not applied successfully to any servers"
at org.junit.Assert.fail(Assert.java:91)
at org.jboss.as.test.integration.domain.DomainTestSupport.validateResponse(DomainTestSupport.java:124)
at org.jboss.as.test.integration.domain.DeploymentManagementTestCase.executeOnMaster(DeploymentManagementTestCase.java:718)
at org.jboss.as.test.integration.domain.DeploymentManagementTestCase.testManagedFullReplaceUnmanaged(DeploymentManagementTestCase.java:639)
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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:115)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:102)
at org.apache.maven.surefire.Surefire.run(Surefire.java:180)
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.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021)
Standard Output
Reading response from http://127.0.0.1:8080/test/index.html:
Reading response from http://127.0.0.1:8630/test/index.html:
Reading response from http://127.0.0.1:8080/test/index.html:
OK
Reading response from http://127.0.0.1:8630/test/index.html:
OK
Failed response:
{
"outcome" => "failed",
"result" => {"server-groups" => {
"main-server-group" => {
"main-one" => {
"host" => "master",
"response" => {
"outcome" => "success",
"result" => undefined,
"compensating-operation" => {
"operation" => "full-replace-deployment",
"address" => [],
"name" => "test.war",
"content" => [{"hash" => bytes {
0x00, 0xbf, 0x50, 0x4d, 0x4b, 0x51, 0x74, 0x52,
0x3b, 0x21, 0x10, 0x3c, 0x80, 0xe6, 0x8b, 0x86,
0xe1, 0x19, 0x41, 0xf6
}}],
"runtime-name" => "test.war"
}
}
},
"main-three" => {
"host" => "slave",
"response" => {
"outcome" => "failed",
"failure-description" => "No deployment content with hash 00bf504d4b5174523b21103c80e68b86e11941f6 is available in the deployment content repository."
}
}
},
"other-server-group" => {"other-two" => {
"host" => "slave",
"response" => {
"outcome" => "failed",
"failure-description" => "No deployment content with hash 00bf504d4b5174523b21103c80e68b86e11941f6 is available in the deployment content repository."
}
}}
}},
"failure-description" => "Operation was not applied successfully to any servers"
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] Created: (JBAS-9193) Tighten up the ServerEnvironment and HostControllerEnvironment contracts
by Brian Stansberry (JIRA)
Tighten up the ServerEnvironment and HostControllerEnvironment contracts
------------------------------------------------------------------------
Key: JBAS-9193
URL: https://issues.jboss.org/browse/JBAS-9193
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Domain Management
Reporter: Brian Stansberry
Fix For: 7.0.0.Beta4
Right now the contract/usage of these classes is a bit of a mishmash. The idea was to store state that's read from Main(). But if there's anything in these that can be overridden from standalone.xml, either we should restrict access to that data or make sure that it has the correct value if a change is made via the management API. For example, the server name can come from standalone.xml if the 'name' attribute is set and for sure will come from the HostController in domain mode.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] Created: (AS7-1384) Strange state after :reload
by Heiko Rupp (JIRA)
Strange state after :reload
---------------------------
Key: AS7-1384
URL: https://issues.jboss.org/browse/AS7-1384
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Reporter: Heiko Rupp
Assignee: Brian Stansberry
7.1 snapshot
I did change a socket binding, so reload is needed. Did a /:read-resource
Then :reload
},
"response-headers" => {"process-state" => "reload-required"}
}
[standalone@localhost:9999 /] :reload
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
[standalone@localhost:9999 /] :reload
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
I think after the reload (which succeeded) the process-state should no longer be "reload needed".
Also
{"result" => } should be defined and not just null.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months