[OVSDB-77] Karaf : InventoryListener Event replay code missing in Library on plugin bundle start Created: 11/Sep/14 Updated: 19/Oct/17 Resolved: 12/Jan/16 |
|
| Status: | Resolved |
| Project: | ovsdb |
| Component/s: | Library |
| Affects Version/s: | unspecified |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Madhu Venugopal | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: Mac OS |
||
| External issue ID: | 1802 |
| Description |
|
Though it is a generic problem, it is highly exposed in Karaf runtime. When a passive OVSDB connection is established with the Controller, the OVSDB library uses handleNewPassiveConnection method to inform all the registered listener about the new OVSDB connection. But this works only if the plugin bundle is up and running at this time. Since Karaf takes an alacarte approach, it is possible that the Library feature alone is brought up first followed by the plugin feature. If any OVSDB connections were established with the Library before the Plugin feature is installed, those events are never played back to the Plugin. The fix is to play back the existing and known connections in library to the newly registering connection listener. Something like : for (OvsdbClient client : connections.keySet()) { listener.connected(client); }in registerConnectionListener(). |
| Comments |
| Comment by Madhu Venugopal [ 11/Sep/14 ] |
|
Or it can also be implemented as a pull model from the Plugin (in start() of the InventoryListener) To Pull all the existing connections from the Library. This approach might work better because at the start(), it is guaranteed that all of the other dependencies are resolved and hence the bundle is at a much better position to handle any connection that might pre-exist. I would still suggest spawning a thread to handle the triggered connection event. |
| Comment by Ed Warnicke [ 12/Sep/14 ] |
|
This is just another example of a bundle load order bug. The indeterminacy in OSGI bundle load order makes it a heisenbug most likely to be seen in the field by customers due to variations in bundle load order revealing it. Karaf brings more determinacy, and thus will flush out bugs of this kind, effectively turning customer found defects into things that can be caught by testing. Since things using the config subsystem are loading deterministically, there should not be bugs of this sort in features wired using it. |
| Comment by Sam Hague [ 12/Jan/16 ] |
|
Code is deprecated. |