Bug 1266615 - [GSS](6.4.z) DefaultDeploymentOperations.getDeploymentsStatus doesn't consider model operation result outcome
Summary: [GSS](6.4.z) DefaultDeploymentOperations.getDeploymentsStatus doesn't conside...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Microcontainer and Deployers
Version: 6.4.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: CR1
: EAP 6.4.5
Assignee: Aaron Ogburn
QA Contact: Jan Martiska
eap-docs
URL:
Whiteboard:
Depends On:
Blocks: 1235745
TreeView+ depends on / blocked
 
Reported: 2015-09-25 20:40 UTC by Aaron Ogburn
Modified: 2019-09-12 08:59 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)
deploymentscanneroometest.war.zip (653 bytes, application/zip)
2015-09-25 20:50 UTC, Aaron Ogburn
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker WFCORE-1014 0 Major Resolved DefaultDeploymentOperations.getDeploymentsStatus doesn't consider model operation result outcome 2020-07-04 03:47:04 UTC

Description Aaron Ogburn 2015-09-25 20:40:19 UTC
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

Comment 1 Aaron Ogburn 2015-09-25 20:50:58 UTC
Created attachment 1077255 [details]
deploymentscanneroometest.war.zip

Comment 2 Aaron Ogburn 2015-09-25 21:01:50 UTC
PR: https://github.com/jbossas/jboss-eap/pull/2567

Comment 3 Jan Martiska 2015-11-05 08:22:08 UTC
Verified in EAP 6.4.5.CR1.

Comment 4 Petr Penicka 2017-01-17 11:43:11 UTC
Retroactively bulk-closing issues from released EAP 6.4 cumulative patches.

Comment 5 Petr Penicka 2017-01-17 11:43:12 UTC
Retroactively bulk-closing issues from released EAP 6.4 cumulative patches.


Note You need to log in before you can comment on or make changes to this bug.