Bug 1154121
| Summary: | Error JBAS014613: Operation ("read-resource") with JON | ||
|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise Application Platform 6 | Reporter: | gbonocor |
| Component: | Domain Management | Assignee: | Brian Stansberry <brian.stansberry> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Petr Kremensky <pkremens> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.2.2 | CC: | brian.stansberry, dandread, kkhan |
| Target Milestone: | DR7 | ||
| Target Release: | EAP 6.4.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | Bug | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
What's happening here is the exception handling logic during operation execution needs better discrimination of internal requests vs external requests. During boot it writes things in the server log that it would not at other times because if they occurred as part of boot they would be critical and would need to be logged. For example, some boot step expecting to be able to read /subsystem=web and failing to do so would almost certainly be something that needs to be logged. But an external caller coming in in the middle of boot and trying to read it before it's created is not a problem to the server and should not be logged. Perhaps better than using the knowledge of the caller type in the exception handling is to use it to avoid executing the operation at all and return to the client a NoSuchResource failure message (for the root resource). The standard practice for clients likely to have a race where they invoke an op against a still-booting server[1] is to read the 'server-state' attribute on the root resource, ignoring failures and retrying until it returns 'RUNNING' or a timeout occurs. Responding with the NoSuchResource failure would work fine with that approach. [1] e.g. the Arquillian containers and EAP's own testsuite fixtures The customer asked me if there is a possibility to get this fix in EAP 6.2.... Remote management operations during server boot now fails with JBAS013493. eg. /host=master:reload /host=master:read-resource fails unless Host controller is booted. Verified on EAP 6.4.0.DR10. |
Description of problem: Error in server.log file after clean install and server start: 10:49:46,987 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("read-resource") failed - address: ([("subsystem" => "web")]) - failure description: "JBAS014807: Management resource '[(\"subsystem\" => \"web\")]' not found" The errors are looping all the EAP subsystems Version-Release number of selected component (if applicable): JON 3.3 DR01 How reproducible: Steps to Reproduce: 1. Install and start JON 2. 3. Actual results: Errors in server.log after clean install/start. Expected results: Should be zero silent errors in server.log See also https://bugzilla.redhat.com/show_bug.cgi?id=1127356