We have a customer who is using DeploymentStore table to register deployments. In some cases, they noticed that the deployment is marked as -1 (STATE_OBSOLETE) and from the code we can see that this happens due to the failure of the undeploy call:

~~~
deploymentService.undeploy(unit); 
~~~

In case when the failure of undeploy happens the system does not clean up the relevant resources properly. 
When the undeploy call is invoked it closes the associated runtime manager:
~~~
((AbstractRuntimeManager) manager).close(true); 
~~~
When the associated runtime manager makes the close call, it cleans up the associated resources, especially the relevant timer job that is created for the deployment.

However, in the current code implementation, the DeploymentSynchronizer simply catches the exception and mark the deployment as obsolete without further cleaning up the relevant resources:

~~~    
try {
        logger.debug("Existing deployment unit {} to be undeployed", unit.getIdentifier());
        entries.remove(unit.getIdentifier());
        deploymentService.undeploy(unit);
    } catch (Exception e) {
        logger.warn("Deployment unit {} failed to undeploy: {}", unit.getIdentifier(), e.getMessage(), e);
        entries.put(unit.getIdentifier(), unit);
        deploymentStore.markDeploymentUnitAsObsolete(unit);
    }
~~~
So, in the above code we do not propagate the Exception and the relevant resources are not cleaned. Our suggestion is to make the following change in the code:
~~~
try {
        logger.debug("Existing deployment unit {} to be undeployed", unit.getIdentifier());
        entries.remove(unit.getIdentifier());
        deploymentService.undeploy(unit);
    } catch (Exception e) {
        logger.warn("Deployment unit {} failed to undeploy: {}", unit.getIdentifier(), e.getMessage(), e);
        entries.put(unit.getIdentifier(), unit);
        deploymentStore.markDeploymentUnitAsObsolete(unit);
        throw new RuntimeException("xxxx"); 
    }
~~~