[
https://issues.apache.org/jira/browse/FELIX-3712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13776675#comment-13776675
]
Thomas Watson commented on FELIX-3712:
--------------------------------------
This issue happens when file install decides to:
1) refresh itself or
2) refreshes a bundle which file install is wired to
When this happens file install will be stopped while one of its directory
watcher threads is waiting for a refresh package operation to complete.
Stopping file install will cause it to attempt to interrupt the directory
watcher threads. This causes the runtime exception to be thrown from
FileInstall#refreshPackages like the reporter of this issue indicates.
In my environment this ultimately makes the current operation to fail, it will
not proceed to start the bundles that just got installed. When file install is
restarted it does not appear to reprocess the bundles from the directory, I
assume because it persisted some timestamp information on the first attempt
(which failed with a runtime exception) so the bundles are not started on file
install restart. So something is off with the file install restarting logic
when a stop was done while waiting for a refresh operation to complete.
This overall issue is happening if gogo command bundle is installed with file
install because gogo command exports the log service package and file install
optionally imports the log service package. File install determines that a new
provider of some optional import of the package is now available and decides it
should refresh the file install bundle to allow it to get wired to the newly
installed log service packages.
This logic seems flawed. In my case file install was already optionally wired
to another provider of the log service package but file install detected that
it was an optional import and a new provider just got installed so it must need
refreshed. I don't think it is a good idea to refresh a bundle just because
another provider showed up for some optional requirement that is already wired
to a perfectly good provider.
> FileInstall throws Interrupted exception when refreshed
> -------------------------------------------------------
>
> Key: FELIX-3712
> URL: https://issues.apache.org/jira/browse/FELIX-3712
> Project: Felix
> Issue Type: Bug
> Components: File Install
> Affects Versions: fileinstall-3.2.4, fileinstall-3.2.6
> Reporter: Per-Erik Svensson
>
> FileInstall will throw exception when refreshing. It is possible there are
> easier ways to reproduce this but here is one way:
> 1) Uninstall gogo command (if available) from the osgi container.
> 2) Install fileinstall
> 3) Put gogo command in the directory watched by fileinstall
> Result: Fileinstall throws
> In main loop, we have serious trouble: java.lang.RuntimeException:
> java.lang.InterruptedException
> java.lang.RuntimeException: java.lang.InterruptedException
> at
> org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:332)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.refresh(DirectoryWatcher.java:677)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:494)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:291)
> Caused by: java.lang.InterruptedException
> at java.lang.Object.wait(Native Method)
> at
> org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:330)
> ... 3 more
> Possible reason: Due to FELIX-3414, the refresh() method in DirectoryWatcher
> was changed from calling
> packageAdmin#refreshPackages() directly, to using the FileInstall#refresh()
> helper method. The later wraps interrupted excpetions in a runtime exception
> which is never caught in the directory watcher's main loop. Thus, the
> directory watcher will re-throw the exception, which it previously did not
> (since the interrupted excpetion would get caught).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
