• Type: Story
    • Status: Resolved (View workflow)
    • Priority: Medium
    • Resolution: Done
    • Affects versions: None
    • Fix versions:
    • Components: None
    • Labels:
    • Sprint:
      Sprint 174
    • Story Points:
    • Capitalizable:


      Apart from being additional unnecessary work, redeploying (unpacking) our EARs every time Repose starts also leads to issues when running multiple instances of Repose. If multiple instances of Repose share the same deployment directory, then each instance will try to unpack the EARs. If one instance is attempting to read (e.g., load a class) from one of the unpacked files while another instance is re-writing that file, we see errors. We saw this happen with some regularity in the RemoteDatastoreServiceTest.

      Instead, we should avoid redeployment if the files we need are already deployed. We can do so by either:

      • Avoiding deployment if the artifact-specific deployment directory for an artifact already exists.
        • If a file in that directory has been corrupted, we would not fix it, which could lead to difficult-to-diagnose issues.
          • For example, if the Repose process was killed partway through writing a file, subsequent runs of Repose may fail repeatedly since the file is "bad" but not being rewritten. If a file was intentionally modified, we are going to overwrite that modification (though really, that shouldn't happen).
      • Avoiding deployment of specific files if the file already exists.
        • We would want to verify the checksum of deployed files to ensure their integrity.
          • I suggest using CRC since it is fast, and we get it for free on one end (the EAR end) since we use a ZipEntryStream.
      • Load classes directly from EAR files, which can be treated as static. They are installed by the Repose package, and really should not change (unless Repose is being upgraded in a non-containerized environment, which should stop the process first).

      The classes that perform deployment are the ArtifactManager and EarClassProvider classes.

      Story Grooming note:

      • We should lock on the directory instead of the EAR(s).
      • If we are locked on the directory, log the fact that Repose is waiting for the directory to unlock.
      • Logs Logs Logs

      Acceptance Criteria:

      • We can safely start multiple instances of Repose on a single host.
        • We shouldn't see any race conditions around the artifact exploding.




            • Assignee:
              damien.johnson Damien Johnson
              damien.johnson Damien Johnson
            • Votes:
              0 Vote for this issue
              1 Start watching this issue


              • Created: