On Wed, Sep 19, 2012 at 2:02 PM, Mircea Markus <mircea.markus(a)jboss.com>wrote:
On 19 Sep 2012, at 12:57, Manik Surtani wrote:
Hi guys,
Having briefly investigated
https://issues.jboss.org/browse/ISPN-2314, I
consider the fix (
https://github.com/infinispan/infinispan/pull/1318) to
be rather fishy.
Sure it works, but it masks the fact that the order in which things are
started has changed (This IMO seems to be the result of
http://issues.jboss.org/browse/ISPN-2256).
Not only that, but the fact that you have to modify both the component
registry and the configuration makes me think that there're situations
where the configuration changes are applied, and others where it's not
(hence why you have to change the component registry).
So, can we please stop and try to understand what really is happening
here? I was expecting Mircea to have a look into a fix for this since it
looks related to cache start order.
Personally, I don't really see why the lifecycle manager has to mess up
with the component registry. Changes to the configuration were 'enough'
(until 2256) and I don't see why that should change.
It appears that the cache is already constructed when the cache starting
callback is issued. This means any changes to the configuration at this
point won't have any effect. But changing the configuration is still
necessary to allow for restarts.
The cacheStartingCallback was being invoked from two places:
- when the cache was first created from InternalCacheFactory
- on subsequent re-starts from ComponentRegistry.start()
As the same call happened at different stages of initialisation I've only
kept the 2nd call for consistency.
Perhaps we need two notifications? One during initialization, and one
during startup?
On the other hand, I'm not sure why would the interceptor chain exist
during restart but not during start. AFAIK it's a volatile component, so it
should be removed during shutdown.
Cheers
Dan