| Developers can deploy apps in expanded directory form, rather than in JAR-format archives. This saves the developer time and effort in building the archive file and it saves GlassFish from having to expand the archive as part of deployment. Historically, GlassFish has not permitted directory deployment to remote instances or clusters. GlassFish 3.1 lifts this restriction. A challenge and a solution Directory deployment to remote instances does not transfer the files. Rather, it simply tells the remote instance where the directory is. For this to work, the DAS and the remote instances must see the same actual directory when they access the same directory path. To avoid deploying a different file set to an instance, GlassFish will make sure the files in the directory as seen by the DAS are the same as those seen by the instances. 2 User Experience Users do two things to use this feature.
- Make sure that the full file path provided on the deploy command exists on the DAS and on all instances specified by the --target option. If the user gives a relative file path, conceptually the corresponding full absolute path is sent to the DAS and to the target instances. The deployed directory must be accessible as the same path on the DAS and all affected instances. Further, the path the DAS and each instance must contain the same files.
- Use the deploy command (or use the deploy function in the admin console) and specify a directory for the path and the target(s) to which the application is to be deployed.
If GlassFish determines that the DAS and the instances do not see the same files, it will report an error. Some Background
During any deployment operation, both the DAS and the target instance(s) do some work with the deployed application. GlassFish will try to make sure that the DAS and the instance(s) see the same files when they refer to the deployment directory provided by the user. The user must therefore make sure that the full file path on the deploy command exists on the DAS and the instances, and that the files accessible using that path are the same on the DAS and the instances. Often users will accomplish this by using a network file system. The actual technique GlassFish uses to decide whether the DAS and the target instances see the same files is an implementation decision and might change over time. GlassFish is likely to use some heuristic that does not guarantee - but makes it very likely - that the deployed directories are in fact identical. 3 Design We will add a DAS-only supplemental command (for the moment, call it CheckRemoteDirDepl) that runs before DeployCommand. If a directory deployment is requested and a non-DAS target is specified, CheckRemoteDirDepl will build a list of URIs of files in the deployment directory. The URIs will be relative to the directory being deployed and arranged using URI.compareTo. Using URIs, and relative ones at that, removes any platform dependencies in file name formatting for files within the directory. CheckRemoteDirDeploy will then invoke InstanceCheckRemoteDirDeploy on all the targeted instances, passing:
- the Adler32 checksum of the assembled URI list (see explanation below),
- the path of the directory being deployed expressed as an absolute URI, and
- the OS type of the DAS - either Windows or non-Windows.
InstanceCheckRemoteDirDeploy on each targeted instance will build its own list of URIs in the directory path, exactly as CheckRemoteDirDeploy did. It returns success if the checksum of its own list matches the checksum sent from the DAS, failure if the checksums differ. Back on the DAS, if CheckRemoteDirDeploy detects at least one failure report from a remote InstanceCheckRemoteDirDeploy then it reports failure, preventing the DeployCommand from even starting. 3 Non-goals Developer override of directory contents check During the review we talked about possibly providing an option on the "deploy" command which would allow a user to bypass the consistency check and do the directory deploy on the requested instances anyway. GlassFish will not support such an override because it seems there is no use case for which this makes sense. If we know the target instances do not have the same files as the DAS when they inventory the directory, only trouble will arise by letting the user force the deployment to proceed and thus knowingly rendering the instances inconsistent. Directory deployment with non-homogeneous OS types GlassFish will not support directory deployment to instances unless the DAS and all instances in the target are of the same OS type. This is why the DAS sends its OS type. Even in URI form, the device part of the path will be different for Windows vs. non-Windows systems with the ":" device separator present in the Windows format. It is out of scope for this feature to try to figure out the correspondence between a device on a Windows system and the mounted file system on a non-Windows system. The first part of InstanceCheckRemoteDirDeploy will check the DAS OS type passed on the command against its own OS type to avoid this problem. 4 Why a checksum? The DAS sends a checksum to each instance, rather than the entire inventory of files it can see in the directory, to drastically reduce the size of the network message. The cost of computing the checksum in the DAS and in each target instance is expected to be much lower than the cost of transmitting the URIs themselves - in a much larger network message - to all target instances. We'll use the Adler32 checksum, purportedly much faster and almost as reliable as CRC32. The checksum will be updated with URI.toASCIIString().asBytes() for each relative URI GlassFish finds in the deployed directory. |
