Package org.glassfish.deployment.autodeploy

Class AutodeployRetryManager

  • All Implemented Interfaces:
    org.glassfish.hk2.api.PostConstruct
    @Service
@Singleton
public class AutodeployRetryManager
extends Object
implements org.glassfish.hk2.api.PostConstruct
    Manages retrying of autodeployed files in case a file is copied slowly.

    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 {@link \ufffd} method and the reportSuccessfulDeployment, reportFailedDeployment, reportSuccessfulUndeployment, and reportUnsuccessfulUndeployment methods.

    The client should invoke shouldAttemptDeployment(java.io.File) 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 {@link 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 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 shouldAttemptDeployment(java.io.File) 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 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.

    Author:
    tjquinn

    • Field Detail

      • deplLogger

        public static final Logger deplLogger

    • Constructor Detail

      • AutodeployRetryManager

        public AutodeployRetryManager()

    • Method Detail

      • postConstruct

        public void postConstruct()
        Specified by:
        postConstruct in interface org.glassfish.hk2.api.PostConstruct