It seems that when I install the Rules engine (either through PaperUI or by hitting the endpoint http://{ip_addr}/rest/extensions/misc-ruleengine/install) the event stream crashes, hence why the loading spinner never completes in PaperUI.
Steps to reproduce:
curl http://{ip_addr}/rest/events to listen to the event stream.Our app depends on the Rules engine, so it needs to be able to listen for the install completed event. I've tried installing other extensions and I can see them being logged when they're installed/uninstalled. This seems to only happen when installing the Rules engine.
Yes, I'm seeing the same thing and I am able to reproduce this with your steps.
Could you investigate, why the Paper UI actually succeeds to receive the event? For me the spinner stops and I can see the "Rule Engine installed" notification.
It only fails to do so, if at the same time I also do the curl command. Maybe there is some issue with providing SSE events to different receivers at the same time?
If I don't curl the event stream, the callback still never happens and the loading spinner animates indefinitely. I'm running my own instance of openhab where nothing is listening to the event stream.
I just tried installing/uninstalling some of the other extensions in Add-ons > Misc and this happens to a few others as well. Google Calendar Scheduler never receives the finished callback when installing, but it does receive the finished callback when uninstalling. HomeKit Integration doesn't receive the finished callback for either installing or uninstalling. Hue Emulation receives the finished callback when installing, but doesn't when uninstalling. This is very odd.
I'm experience similar behaviour on both openhab 2.0.0 and 2.1.0-snapshot. I'm not entirely sure how to debug this.
Here are my findings regarding the loss of SSE connection during/after extension install:
The problem occurs only on extensions which extend the REST API of ESH. During install/uninstall of these extensions the OSGi JAX RS bridge (found here) recognises a change in REST resource configuration and calls reload on the underlying ServletContainer (find sources here). ServletContainer#reload will then shutdown the ApplicationHandler (which handles all requests and also serves as a ContainerLifecycleListener for all resources, sources here) and create a new ApplicationHandler with the changed resource config.
I assume the effect we are seeing here is a race condition between the SSE thread and the OSGI JAX RS bridge. Sometimes the SSE comes first and is able to provide feedback to the UI. Nevertheless will the SSE connection be broken after the ServletContainer reloads all resources.
There does not seem to be any good way to address this issue with the current REST API implementation (that is based on Jersey). So I think we should close this as a won't fix.