Closed rymsha closed 4 years ago
First part:
Reinstallation (or update) of an application calls OSGi Bundle uninstall, which first tries to stop the bundle and send a STOPPING event.
STOPPING event triggers a remove of the application from app-registry
Millisecond after that request comes from frontend and recreates the app in app-registry (unfortunately with stop-in-progress bundle) creates javascript engine executor and awaits for configuration (lock L1) before returning it (holding the script-engine registry lock L2)
Bundle gets fully uninstalled.
New app-registry invalidation issued which tries to remove javascript engine executor from script-engine registry. It awaits lock L2
After 10 seconds configuration lock L1 times out and installation continues normally.
After installation is done bundle.start()
is issued. That allows ConfigAdmin to finally issue config change/setup
This explains why sometimes Apache Felix ConfigAdmin doesn't notify about configuration. See #7967
Second Part:
There are many variations of this issue. For instance configuration may and up being provided, but bundle for an Application becomes uninstalled. In this case application will never get into normal state and will keep throwing NullPointerException on ServiceRefImpl.findService
because BundleContext.getServiceReference
always return null for invalid bundle.
Or Bundle gets uninstalled before javascript engine executor gets created. In this case Bundle Classlader will keep throwing IllegalStateException: The bundle is uninstalled
(this one is not permanent as it may only appear before step 5 )
When application gets updated/reinstalled under load it may fail to run properly
ScriptExecutorManager
grabs an application bundle which is invalid (for unknown reason) and uses it to get BundelContext (which is null for not started/invalid bundles)It is easy to fix to validate BundleContext presence, but it actually doesn't solve the problem. Application must wait for the bundle to fully start.