@Service @Singleton public class AutodeployRetryManager extends Object implements org.glassfish.hk2.api.PostConstruct
If a file is copied into the autodeploy directory slowly, it can appear there before the copy operation has finished, causing the attempt to autodeploy it to fail. This class encapsulates logic to decide whether to retry the deployment of such files on successive loops through the autodeployer thread, reporting failure only if the candidate file has failed to deploy earlier and has remained stable in size for a (configurable) period of time.
The main public entry point are the � method and
the reportSuccessfulDeployment,
reportFailedDeployment, reportSuccessfulUndeployment, and
reportUnsuccessfulUndeployment methods.
The client should invoke shouldAttemptDeployment when it has identified
a candidate file for deployment but before trying to deploy that file. This
retry manager will return whether the caller should attempt to deploy the file,
at least based on whether there has been a previous unsuccessful attempt to
deploy it and, if so, whether the file seems to be stable in size or not.
When the caller actually tries to deploy a file, it must invoke
reportSuccessfulDeployment or reportFailedDeployment)
so that the retry manager keeps its information about the file up-to-date.
Similarly, when the caller tries to undeploy a file it must invoke
{@link reportSuccessfulUndeployment} or {@link reportFailedUndeployment}.
Internally for each file that has failed to deploy the retry manager records the file's size and the timestamp of the most recent failure and the timestamp at which that file will be assumed to be fully copied. At that time the file's retry period will expire. This retry expiration value is extended each time the file changes size since the last time it was checked.
If AutoDeployer previously reported failures to deploy the file and the file's size has been stable for its retry expiration time, then the {@link shouldAttemptDeployment} method returns true to trigger another attempt to deploy the file. If the autodeployer reports another failed deployment then the retry manager concludes that the file is not simply a slow-copying file but is truly invalid. In that case it throws an exception.
Once the caller reports a successful deployment of a file by invoking {@link reportSuccessfulDeployment} the retry manager discards any record of that file from its internal data structures. Similarly the retry manager stops monitoring a file once the autodeployer has made an attempt - successful or unsuccessful - to undeploy it.
An important change from v2 to v3 is the change in the default retry limit. In v2 we could try to open a file as a ZIP file to help decide if it had finished copying, but in v3 we cannot make assumptions about how apps will be packaged (some may be ZIPs, but others may be single files). We need to provide a balance between prompt reporting of a failed auto-deployment vs. handling the case of a slow copy operation which, for a while, manifests itself as a failed deployment.
| Modifier and Type | Field and Description |
|---|---|
static Logger |
deplLogger |
| Constructor and Description |
|---|
AutodeployRetryManager() |
| Modifier and Type | Method and Description |
|---|---|
void |
postConstruct() |
public static final Logger deplLogger
Copyright © 2020. All rights reserved.