Santiago Gala <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
