search

OpenLiberty / open-liberty

Open Liberty is a highly composable, fast to start, dynamic application server runtime environment
https://openliberty.io
Eclipse Public License 2.0
1.14k stars 587 forks source link

OSGi framework UUID shared by liberty servers from same restore #18998

Open sebratton opened 2 years ago

sebratton commented 2 years ago

The OSGi spec calls for each framework instance to have a unique ID: 4.2.8 Framework UUID If the same restore image is used to deploy multipe server instances than this is violated. I don't know of any specific scenario where this is problematic, but it would be idea if we could keep the UUID as being truely unique.

tjwatson commented 2 years ago

We can update the UUID by using the equinox specific service org.eclipse.osgi.service.environment.EnvironmentInfo which has a method setProperty(String, String). There is an internal org.eclipse.osgi.internal.container.InternalUtils.newUUID(EquinoxConfiguration) that Equinox uses to generate the UUID. We would have to use that same type of code to generate the UUID.

But the real challenge is to find any places in Liberty that may have cached the value for some reason. I did look at this at some point and don't recall finding anything that seemed like it mattered that it would use the same UUID. But we need to verify that.

sebratton commented 2 years ago

@tjwatson We discussed this a while back in the context of the UUID being used in FrameworkManger.java. That's the only usage I'm aware of in liberty. As far as I can tell it does not require a true UUID. But if we decide we should honor the semantics of UUID then that's one place we will want to update.

The value there is retrieved via String uuid = systemBundleCtx.getProperty("org.osgi.framework.uuid"). It's cached in a ServerCommandListener instance and in a workarea file .sCommand,. The .sCommand file is already re-generated by a hook, so code is needed to generate and set a new UUID and to update the protected field in ServerCommandListener.

The hook for the UUID will need to run first. Is there a way to guarantee this using service rankings? Also, this seems to be a case where we could be subject to a race condition in the future if logic is added to access the UUID in another thread and it executes before the restore hook.