Bug 1266615
| Summary: | [GSS](6.4.z) DefaultDeploymentOperations.getDeploymentsStatus doesn't consider model operation result outcome | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise Application Platform 6 | Reporter: | Aaron Ogburn <aogburn> | ||||
| Component: | Microcontainer and Deployers | Assignee: | Aaron Ogburn <aogburn> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Jan Martiska <jmartisk> | ||||
| Severity: | unspecified | Docs Contact: | eap-docs <eap-docs> | ||||
| Priority: | unspecified | ||||||
| Version: | 6.4.3 | CC: | ajustin, istudens, jawilson, jmartisk, vtunka | ||||
| Target Milestone: | CR1 | ||||||
| Target Release: | EAP 6.4.5 | ||||||
| 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: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1235745 | ||||||
| Attachments: |
|
||||||
Created attachment 1077255 [details]
deploymentscanneroometest.war.zip
Verified in EAP 6.4.5.CR1. Retroactively bulk-closing issues from released EAP 6.4 cumulative patches. Retroactively bulk-closing issues from released EAP 6.4 cumulative patches. |
Description of problem: The deployment scanner doesn't properly consider the result outcome of its read child operation during getDeploymentsStatus(). This has bad consequences if the operation fails, for instance due to an OOME or possibly some other unexpected exception. The operation catches the exception and returns an empty result. The deployment scanner misinterprets that empty result to mean there are no applications deployed and sets .undeployed marker files for all of them. The deployment scanner should confirm if the operation was a success or not so we can avoid potential side effects of undeployed applications from an OOME. Version-Release number of selected component (if applicable): EAP 6.4.3 How reproducible: Very Steps to reproduce: 1. Lowering -Xmx to 400m helped to reproduce with easier OOMEs 2. Set a very frequent scan interval can help induce the issue <deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-interval="5000"/> 3. deploy attached deploymentscanneroometest.war with a .dodeploy marker 4. request localhost:8080/deploymentscanneroometest/ to generate an OOME and check for the application being moved to .undeployed Actual results: JBoss may undeploy applications as a side effect of an OOME if the OOME induces an exception in the deployment scanner's model operations with a message like: INFO [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 2) JBAS015018: Deployment deploymentscanneroometest.war was previously deployed by this scanner but has been removed from the server deployment list by another management tool. Marker file $EAP_HOME/standalone/deployments/deploymentscanneroometest.war.undeployed is being added to record this fact. Expected results: JBoss does not undeploy applications as a side effect of an OOME