apache/flink · warning · ProgramInvocationException

Could not close the JAR file: {t.getMessage()}

Error message

Could not close the JAR file: {t.getMessage()}

What it means

Thrown by getEntryPointClassNameFromJar in the finally block when jar.close() raises a Throwable. The original operation (reading the manifest/attributes) may have succeeded, but this close error masks it because the finally rethrows. It indicates an I/O or resource problem with the jar file handle.

Source

Thrown at flink-clients/src/main/java/org/apache/flink/client/program/PackagedProgram.java:452

            }

            // check for a main class
            className = attributes.getValue(PackagedProgram.MANIFEST_ATTRIBUTE_MAIN_CLASS);
            if (className != null) {
                return className;
            } else {
                throw new ProgramInvocationException(
                        "Neither a '"
                                + MANIFEST_ATTRIBUTE_MAIN_CLASS
                                + "', nor a '"
                                + MANIFEST_ATTRIBUTE_ASSEMBLER_CLASS
                                + "' entry was found in the jar file.");
            }
        } finally {
            try {
                jar.close();
            } catch (Throwable t) {
                throw new ProgramInvocationException(
                        "Could not close the JAR file: " + t.getMessage(), t);
            }
        }
    }

    @Nullable
    private static URL loadJarFile(File jar) throws ProgramInvocationException {
        if (jar != null) {
            URL jarFileUrl;

            try {
                jarFileUrl = jar.getAbsoluteFile().toURI().toURL();
            } catch (MalformedURLException e1) {
                throw new IllegalArgumentException("The jar file path is invalid.");
            }

            checkJarFile(jarFileUrl);

View on GitHub (pinned to 2f3c205e92)

Solutions

  1. Ensure the jar is on a stable, local filesystem during submission.
  2. Increase the OS file-descriptor limit (ulimit -n) if handle exhaustion is suspected.
  3. Disable/reconfigure antivirus that may lock jar files mid-read.
  4. Note: if the manifest read succeeded before close failed, the useful result is lost in the rethrow — retry after fixing the file-handle issue.
Defensive patterns

Strategy: try-catch

Validate before calling

// Ensure the jar is on a stable local FS and readable before submission
if (!jarFile.exists() || !jarFile.canRead()) {
    throw new IllegalArgumentException("Jar inaccessible: " + jarFile);
}
// Optionally copy the jar to a local temp dir to avoid remote-FS disconnects during read

Try / catch

try {
    PackagedProgram.newBuilder().setJarFile(jarFile).build();
} catch (ProgramInvocationException pie) {
    if (pie.getMessage().startsWith("Could not close the JAR file")) {
        // the manifest read may have succeeded; retry after fixing file-handle / FS issue
    }
    throw pie;
}

Prevention

When it happens

Trigger: jar.close() fails in the finally clause — typically an IOException from the underlying random-access file/channel, or a Throwable from a closed/invalidated handle (e.g. the file was deleted during read).

Common situations: The jar file is on a network/remote filesystem that disconnects during read; the jar is deleted/moved concurrently; the OS file-handle limit is exhausted; antivirus locking the file.

Related errors


AI-assisted analysis of apache/flink@2f3c205e92 (2026-08-14). Data as JSON: /api/errors/99370fb4c84933a4. Report an issue: GitHub.