[Rafal, I copy this message to you because I don't know if you are on the
Jetspeed list and this is Services related]
Santiago Gala wrote:
>
> I think I found it. I will try to summarise, as an opportunity to get
> corrected if I make some error in my reasoning.
>
> The problem is with the sequence of initialization of services.
>
> Turbine provides two "rounds" of initialization for services. In the
> first round, services get called with a ServletConfig object. Here we
> perform most of our work. In the second round, services get called
> without any argument.
>
That's quite accurate, most of our services perform early initialization
rather than late initialization.
> The problem is that we don't implement the second round init(). The
> default behaviour in turbine for the secound round is to call
> setInit(true). So, the problem is that a lot of times, our services are
> requested while they are being initialized. The result is that turbine
> will return the "half cooked" services to the thread aking for them.
>
> I think the default behaviour in TurbineBaseService init() is wrong. A
> better default would be something like:
>
> init(Object), init(RunData) and init(ServletConfig) do setInit(true)
> (Turbine should guarantee that only one of these methods is called for
> each service)
>
> public void init() throws InitializationException {
>
> if(!getInit()) {
> throw new InitializationException("Not yet inited");
> }
>
> }
>
> As a default implementation it should not assume that any service is to
> be considered initialized when asked for, specially since the default
> first round init() does nothing. In the way I think it should be, a
> service that overrides early init takes responsibility of setting init
> to true, and one that does not override it gets inited right. The way it
> is now, a service should override both methods if it does any
> initialization, to avoid race conditions like the ones we have.
>
> I have fixed the problems by implementing late init methods in some
> services (I will check for all and every service that has initialization
> process). This implementation waits for getInit() returning true, while
> printing messages every 100 milliseconds, to avoid either having an
> exception thrown or delivering a service that is "on its way".
>
> Some of the services implementation used synchronized in the two init to
> have mutual exclusion between both initializations. It will not work,
> except by locking turbine if some service is requested during
> initialization of other service.
>
I agree that Turbine Services should probably make sure the late init is
called on an object when early init is complete, however what you propose
will not completely solve the specific RegistryManager issue which, as far as
I can understand, is that early init in RegistryManager has an hidden dependency
on RegistryManager through EntryFactory and PortletEntryNormalizer.
Actually if you do block late init() on the RegistryManager as should be, you
have a deadlock...
So the *real* fix for this specific bug is to remove this dependency, but digging
deep into the JetspeedConfig/PortletRegistry is not something I relish...
I still agree with you that TurbineServices should ensure that late init is always
called when early init is complete to avoid race conditions and highlight the kind
of bugs we have
--
Raphaël Luta - [EMAIL PROTECTED]
Vivendi Universal Networks - Services Manager / Paris
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
