You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Santiago Gala <sg...@hisitech.com> on 2002/03/18 20:24:55 UTC
Re: I propose to upgrade Turbine again - eez ok?
Chris Kimpton wrote:
>Hi,
>
>>>I am currently testing with the new turbine at the moment - anyone
>>>got any concerns about me upgrading turbine...
>>>
>
>Just looked at the turbine-dev list and looks like they are trying to
>do a release - so I will hold off and try upgrading jetspeed after
>the release/with the release later...
>
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. :)
>
>Chris
>
>=====
>http://wc2002.kimptoc.net - someone has got to win...
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! Sports - live college hoops coverage
>http://sports.yahoo.com/
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: I propose to upgrade Turbine again - eez ok?
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Santiago Gala <sg...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: I propose to upgrade Turbine again - eez ok?
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Santiago Gala <sg...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: I propose to upgrade Turbine again - eez ok?
Posted by Chris Kimpton <ki...@yahoo.com>.
Hi,
--- Santiago Gala <sg...@hisitech.com> wrote:
> Chris Kimpton wrote:
>
> >Hi,
> >
> >>>I am currently testing with the new turbine at the moment -
> anyone
> >>>got any concerns about me upgrading turbine...
> >>>
> >
> >Just looked at the turbine-dev list and looks like they are trying
> to
> >do a release - so I will hold off and try upgrading jetspeed after
> >the release/with the release later...
> >
> 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.
I don't think this is the problem.
The problem seems to be related to using ${webappRoot} and accessing
files under /WEB-INF/.
Comparing what the CastorRegistryService does with the
JetspeedTemplateLocatorService, the latter uses
TurbineServlet.getRealPath to "fix" the file name. Whereas the
former get does a new File() on the property found.
I have changed the Castor service to use this for the mapfile and
directory properties and things seem to be working ok...
Does this sound like something that has changed in turbine recently?
Chris
=====
http://wc2002.kimptoc.net - someone has got to win...
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: I propose to upgrade Turbine again - eez ok?
Posted by Chris Kimpton <ki...@yahoo.com>.
Hi,
--- Santiago Gala <sg...@hisitech.com> wrote:
> Chris Kimpton wrote:
>
> >Hi,
> >
> >>>I am currently testing with the new turbine at the moment -
> anyone
> >>>got any concerns about me upgrading turbine...
> >>>
> >
> >Just looked at the turbine-dev list and looks like they are trying
> to
> >do a release - so I will hold off and try upgrading jetspeed after
> >the release/with the release later...
> >
> 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.
I don't think this is the problem.
The problem seems to be related to using ${webappRoot} and accessing
files under /WEB-INF/.
Comparing what the CastorRegistryService does with the
JetspeedTemplateLocatorService, the latter uses
TurbineServlet.getRealPath to "fix" the file name. Whereas the
former get does a new File() on the property found.
I have changed the Castor service to use this for the mapfile and
directory properties and things seem to be working ok...
Does this sound like something that has changed in turbine recently?
Chris
=====
http://wc2002.kimptoc.net - someone has got to win...
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>