[JBoss JIRA] (AS7-5929) :reload operation clears up the restart-required process-state
by Jeff Mesnil (JIRA)
Jeff Mesnil created AS7-5929:
--------------------------------
Summary: :reload operation clears up the restart-required process-state
Key: AS7-5929
URL: https://issues.jboss.org/browse/AS7-5929
Project: Application Server 7
Issue Type: Bug
Reporter: Jeff Mesnil
For the patching service, the patch command leaves the server in a restart-required state
{noformat}
[standalone@localhost:9999 /] patch /home/jmesnil/Developer/jboss-as/build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/patch.zip
{
"outcome" : "success",
"response-headers" : {
"operation-requires-restart" : true,
"process-state" : "restart-required"
}
}
{noformat}
If I try to change the AS7 configuration, the CLI warns me that a restart is required, for example:
{codeformat}
[standalone@localhost:9999 hornetq-server=default] ./queue=foo:add(queue-address=foo)
{
"outcome" => "success",
"response-headers" => {"process-state" => "restart-required"}
}
{codeformat}
However, when I reload the server using the /:reload command, the process-state header is cleared out:
{codeformat}
[standalone@localhost:9999 hornetq-server=default] /:reload
{"outcome" => "success"}
[standalone@localhost:9999 hornetq-server=default] ./queue=bar:add(queue-address=bar)
{"outcome" => "success"}
{codeformat}
This is not correct: until the server is restarted (not reloaded), the result of my patch operation will not be taken into account (eg changing the AS7 module path).
Reloading the server should not clear its process-state if it is set to "restart-required"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-5995) After deploy an application with a wrong module slot dependency the module loader does not recover
by Wolf-Dieter Fink (JIRA)
Wolf-Dieter Fink created AS7-5995:
-------------------------------------
Summary: After deploy an application with a wrong module slot dependency the module loader does not recover
Key: AS7-5995
URL: https://issues.jboss.org/browse/AS7-5995
Project: Application Server 7
Issue Type: Bug
Affects Versions: 7.2.0.Alpha1
Environment: Tested with 7.2. upstream
commit ed2bc551a55ec6a8167a8657cbb5d8abc6e07748
Date: Thu Nov 15 10:15:22 2012 +0100
standalone mode, no difference whether CLI or file-system scanner
Reporter: Wolf-Dieter Fink
If an application is deployed with a dependency and specify a slot in jboss-deployment-structure.xml:
<module name="wfink.tools.performance" slot="1.0" export="true"/>
the module loader will not correct load a new deployment after failing with 'JBAS018759' Caused by: org.jboss.modules.ModuleNotFoundException: Module wfink.tools.performance:1.1 is not found in local module loader.
If after such message the application.ear contain a correct slot, or even no slot entry, the module loader fail with the message above. The slot number is the same as of the failed deployment.
If the server is restarted the application deploy succeeds.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-5558) More useful error messages when management operations can't be found
by Brian Stansberry (JIRA)
Brian Stansberry created AS7-5558:
-------------------------------------
Summary: More useful error messages when management operations can't be found
Key: AS7-5558
URL: https://issues.jboss.org/browse/AS7-5558
Project: Application Server 7
Issue Type: Enhancement
Components: Domain Management
Reporter: Brian Stansberry
Fix For: 7.2.0.CR1
When the ModelController attempts to find the OperationStepHandler for a given operation + address, it needs to handle failure more intelligently. Instead of providing a one-size fits all exception, it should try to determine why the OSH couldn't be found and tailor the exception accordingly. Specifically, clarify whether the problem is the address is invalid or the operation name is invalid, and if it's the address that's invalid, clarify the point in the resource tree where the address goes wrong.
For example, a user attempting to administer a server that has already been shut down gets this fairly useless exception:
Error loading VM metrics
Unexpected HTTP response: 500
Request
{
"operation" => "composite",
"address" => [],
"steps" => [
{
"address" => [
("host" => "master"),
("server" => "server-one"),
("core-service" => "platform-mbean"),
("type" => "memory")
],
"operation" => "read-resource",
"include-runtime" => true
},
{
"address" => [
("host" => "master"),
("server" => "server-one"),
("core-service" => "platform-mbean"),
("type" => "threading")
],
"operation" => "read-resource",
"include-runtime" => true
},
{
"address" => [
("host" => "master"),
("server" => "server-one"),
("core-service" => "platform-mbean"),
("type" => "runtime")
],
"operation" => "read-resource",
"include-runtime" => true
},
{
"address" => [
("host" => "master"),
("server" => "server-one"),
("core-service" => "platform-mbean"),
("type" => "operating-system")
],
"operation" => "read-resource",
"include-runtime" => true
}
]
}
Response
Internal Server Error
{
"outcome" => "failed",
"failure-description" => "JBAS010850: No handler for operation read-resource at address [
(\"host\" => \"master\"),
(\"server\" => \"server-one\"),
(\"core-service\" => \"platform-mbean\"),
(\"type\" => \"memory\")
]",
"rolled-back" => true
}
The reality is no resource exists at address /host=master/server=server-one. The failure message should emphasize this fact.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months