portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Rall <...@finemaltcoding.com>
Subject Re: I propose to upgrade Turbine again - eez ok?
Date Fri, 29 Mar 2002 17:30:30 GMT
Santiago Gala <sgala@hisitech.com> writes:

> The problem is the patch about race conditions on service
> initialization. I will not be able to test it, so it will not go to
> the release.
> The problem seems to be that, when you ask for a service twice (in
> separate threads),
> - the first one triggers (early and then late) initialization of the service
> - the second one tries to get it and, since it is not (yet) in the
> services hashmap, initializes a new instance.
> So the singleton paradigm breaks, and after this the workings of
> turbine are rather messed up. We have a race condition going on. It
> happens about one in three times in my setup, depending on DNS times
> and HTTP proxies being filled up or not.
> It happens in Jetspeed because the CastorRegistryService is *very*
> slow to initialize, uses remote resources with unpredictable delays,
> and it is requested by quite a few services (and service initialized
> threads) in Jetspeed. The most problematic seems to be the
> DaemonService, since it spawns threads.
> I'm trying to find a solution where Turbine does not need to be
> patched for single singletons and avoiding double lock
> synchronization, but I'm not sure if I will be able.
> I thought that there was a contract in Turbine where services were
> singletons, so I think this behaviour looks like a bug in turbine-2.
> "Spamming" turbine-dev, to look for further insight. :)

Santiago, have you tried synchronizing the body of init() on
CastorRegistryService.class (or some other static member)?  I've had
to take similar measures for services which establish socket
connections in SourceCast.

- Daniel

To unsubscribe, e-mail:   <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>

View raw message