Raphaël Luta escribió:
>
> [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...
I think I made it run, but I will study the issue, since I still get
some errors I cannot understand
>
> 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 had to enter the "mud", and I'm full of it currently :-)
I will start commiting after I check the changes in turbine
initialization.
> 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]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
