Robert Schulte created FELIX-6490:
-------------------------------------
Summary: Files that cannot be deployed due to a missing handler
are not processed again
Key: FELIX-6490
URL: https://issues.apache.org/jira/browse/FELIX-6490
Project: Felix
Issue Type: Bug
Components: File Install
Affects Versions: fileinstall-3.7.2, fileinstall-3.7.0
Reporter: Robert Schulte
h2. 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
h2. Issue Analysis
[DirectoryWatcher.java#doProcess|https://github.com/apache/felix-dev/blob/org.apache.felix.fileinstall-3.7.0/fileinstall/src/main/java/org/apache/felix/fileinstall/internal/DirectoryWatcher.java#L381-L385]
has a mechanic of retrying deployment for files that could not be matched to a
handler on a previous attempt:
{code:java}
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();
}
//...
}
{code}
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|https://github.com/apache/felix-dev/commit/101a360248311817e1ad4645c549ea77773b0481#diff-263cdbacfd163ef5ce31dcbb1db83138f78d88eab353f1f587a10199e8ef3817])
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.
{code:java}
if (files != null && !files.isEmpty()) {
process(files);
}
{code}
The added guard {{!files.isEmpty()}} to {{process(files)}} renders the retrying
logic ineffective
h2. Possible fixes
h3. Revert to old guard
{code:java}
if (files != null) {
process(files);
}
{code}
h3. Account for "processingFailures"
{code:java}
if ((files != null && !files.isEmpty()) || !processingFailures.isEmpty()) {
process(files);
}
{code}
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
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
