[FELIX-6490] Files that cannot be deployed due to a missing handler are not processed again

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Duplicate
• Affects Version/s: fileinstall-3.7.0, fileinstall-3.7.2
• Component/s: File Install
• Assignee: Jean-Baptiste Onofré
• Reporter: Robert Schulte
• Created: 27/Dec/21 16:14
• Updated: 03/Jan/22 14:18
• Resolved: 03/Jan/22 14:18

Description

Context

I tried to migrate a custom Karaf distribution from 4.2.8 to 4.3.3 (fileinstall version 3.6.4 -> 3.7.0). The distribution contains a blueprint (xml) file that is supposed to be handled by one of Karaf's custom ArtifactListener_s. This kind of deploment works for Karaf 4.2.8 but fails for 4.3.3

Issue Analysis

DirectoryWatcher.java#doProcess has a mechanic of retrying deployment for files that could not be matched to a handler on a previous attempt:

private void doProcess(Set<File> files) throws InterruptedException
    {
        List<ArtifactListener> listeners = fileInstall.getListeners();
        List<Artifact> deleted = new ArrayList<Artifact>();
        List<Artifact> modified = new ArrayList<Artifact>();
        List<Artifact> created = new ArrayList<Artifact>();

        // Try to process again files that could not be processed
        synchronized (processingFailures)
        {
            files.addAll(processingFailures);
            processingFailures.clear();
        }
		//...
	}

It is vital that doProcess is invoked although no changes have been observed in the watched folder. Otherwise, the retry mechanism is not effective at all.

The workaround for FELIX-6229 (101a360248311817e1ad4645c549ea77773b0481) introduced a regression (in addition to the possible NPE that was fixed in cbf8174b66af21453ae209c590d4bf7f4a36e36b) that prevents doProcess from being invoked in the absence of changes in the watched directory.

if (files != null && !files.isEmpty()) {
    process(files);
}

The added guard !files.isEmpty() to process(files) renders the retrying logic ineffective

Possible fixes

Revert to old guard

if (files != null) {
    process(files);
}

Account for "processingFailures"

if ((files != null && !files.isEmpty()) || !processingFailures.isEmpty()) {
    process(files);
}

This should probably be accompanied by some refactoring. If the re-processing of processingFailures was more apparent (e.g., by having a dedicated method for this),

• it becomes less likely, that the re-processing gets accidentally broken again
• re-processing could even be decoupled from the scanning interval

Issue Links

• blocks: KARAF-7306 Hot deployment (deploy directory) does not work for provisioned blueprints
• is duplicated by: FELIX-6461 Felix fileinstall doesn't test if files is null, causing retry failure