Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
-
None
Description
If a bundle exporting a service is started/stopped frequently (e.g. start/1 sec/stop/1 sec/start ...) can happen that the serviceRegistration created during the start is coupled to an invalidated serviceReference belonging to a previous serviceRegistration.
This is happening because the serviceRegistry stores the pairs <serviceRegistration,serviceReference> using the address of the serviceRegistration as index. In case of fast start/stop cycles, the serviceRegistration is destroyed, the serviceReference is invalidated (but not removed from the hashmap) and the new serviceRegistration is created using the same address of the previous one (for the allocator is easy to allocate the same memory for something we just destroyed reusing the same memory chunk and the same pointer). Of course the hashMap is not updated.
The effect is that when getting the serviceReference for the just created serviceRegistration, we get back the invalidated one belonging to the old serviceRegistration.
Proposal is to use as index not the serviceRegistration pointer but the serviceID, that is managed as monotonically increasing counter: this way the key cannot be reused (we can ignore counter wraparound phenomenon, since they may happen only when starting 4 billions services...) and the coupling <serviceRegistration,serviceReference> should be always coherent.