• Bug
  • Status: Open
  • 2 Major
  • Resolution:
  • DSO:L1
  • interfaces
  • Reporter: wharley
  • January 09, 2009
  • 0
  • Watchers: 1
  • December 16, 2011

Description

For an object to be shared, it must be loaded by a classloader with a registered name. When a change is broadcast to another node, if the class must be loaded on that node, the registered classloader name is used to look up the correct classloader. Thus, it is important that a given classloader name correctly identifies the same classloader on all nodes.

Classes in TIMs are loaded from OSGi bundle classloaders. These classloaders are registered by ModulesLoader.

From a debug-instrumented run of tim-hibernate-3.2.5-system-tests ContainerHibernate325Test, here is what the list of registered names looks like:

Standard.ext Standard.system Tomcat.shared Tomcat.common Tomcat.catalina Tomcat.Catalina:localhost:/manager Tomcat.Catalina:localhost:/events Tomcat.Catalina:localhost:/cargocpc Modules.BundleClassLoader(id=8,gen=0) Modules.BundleClassLoader(id=9,gen=0) Modules.BundleClassLoader(id=10,gen=0) Modules.BundleClassLoader(id=6,gen=0) Modules.BundleClassLoader(id=3,gen=0) Modules.BundleClassLoader(id=4,gen=0) Modules.BundleClassLoader(id=1,gen=0) Modules.BundleClassLoader(id=5,gen=0) Modules.BundleClassLoader(id=7,gen=0) Modules.BundleClassLoader(id=2,gen=0)

Note that the bundle loader names do not designate the bundle. The “Modules.” prefix comes from our code; the rest seems to just be the toString() of the classloader object.

The problem with this is that “Modules.BundleClassLoader(id=5,gen=0)” (for example) does not uniquely identify a module; it presumably depends on the order the module was loaded, which could be different on two nodes, if the nodes contain different apps.

Therefore, an object shared in one TIM (say, tim-ehcache, which shares some MemoryStoreEvictionPolicy objects as roots) might not be loadable on another node, even though the TIM in question exists on both nodes.

I think the BundleClassLoader registered name should be based on the name and version of the bundle, not on the toString of the loader object.

This bug report is based on code inspection and on observation of the names; I have not tried to actually reproduce the expected bug. Maybe some other magic prevents it from happening in practice.

Comments

Fiona OShea 2009-02-20

how important is this? Do we need to resolve in Quintara timeframe?

Walter Harley 2009-02-20

It’s ugly but I am not aware of any problems in the field that have resulted from it.

Alex Miller 2009-02-20

I’d prefer to leave it in 3.0.0 as secondary priority so that someone can take a look if they get a chance.

Alex Miller 2009-03-19

Seems like this is fairly hard to trigger as a problem as it requires using different tc-configs with different orderings of modules AND having bundles loading clustered classes.