Uploaded image for project: 'Infinispan'
  1. Infinispan
  2. ISPN-9541

Module initialization is not thread-safe

This issue belongs to an archived project. You can view it, but you can't modify it. Learn more

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • 10.0.0.Final
    • 9.4.0.Final
    • Core, Server
    • None
    • Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 9.4.0.Final, Sprint 10.0.0.Alpha0, Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36, DataGrid Sprint #37, DataGrid Sprint #38, DataGrid Sprint #39

      In my ISPN-9127 fix I created a BasicComponentRegistry interface that represents a mostly-read-only collection of components. It has replaceComponent() method and a rewire() method for testing purposes, but it turns out modules were also relying on the ability to replace existing components in order to work.

      Replacing global components is normally safe during the ModuleLifecycle.cacheManagerStarting(), because none of the components are started yet, so when a component starts later we can still start its dependencies first. But because some modules starts some global components, e.g. by calling manager.getCache(name), that assumption breaks.

      The infinispan-server-event-logger module is a bit more sneaky: it doesn't replace a component, instead it replaces the actual implementation of the event logger in the EventLogManager component. Events that happen before the module's cacheManagerStarting() or after cacheManagerStopping() will be silently dropped from the persistent event log.

      I am investigating making the module a factory of factories. Instead of having a monolitic cacheManagerStarting() method, it could define a set of components that it can create, and a set of components that should be started before the cache manager is "running". We probably need a way to depend on other modules as well, maybe reusing the @Inject and @ComponentName annotations.

              dberinde@redhat.com Dan Berindei (Inactive)
              dberinde@redhat.com Dan Berindei (Inactive)
              Archiver:
              rhn-support-adongare Amol Dongare

                Created:
                Updated:
                Resolved:
                Archived: