cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <Giacomo.P...@pwr.ch>
Subject Re: Shutdown of an producer
Date Sun, 20 Aug 2000 15:49:01 GMT
Stefano Mazzocchi wrote:
> 
> Giacomo Pati wrote:
> >
> > Stefano Mazzocchi wrote:
> > >
> > > Giacomo Pati wrote:
> > > >
> > > > Ricardo Rocha wrote:
> > > > >
> > > > > Stefano Mazzocchi wrote:
> > > > > > I would like to be able to have both init() and destroy() method
> > > > > > implemented, at least, in generators so that we can have resources
> > > > > > started and stopped along with the servlet life cycles to ensure
greater
> > > > > > possible usability compared to pure servlets.
> > > > > >
> > > > > > In practice, this means that every generator that is created
by the
> > > > > > sitemap should be destroyed when the servlet is destroyed.
> > > > > >
> > > > > > These init/destroy cycles might be needed for also the other
pipeline
> > > > > > components... what do you say?
> > > > >
> > > > > +1 for pipeline components at large
> > > >
> > > > Well, I think this wouldn't be possible because almost none of the
> > > > sitemap components are thread save today (and most of them would never
> > > > be) and thus are created per request (and destroyed right after request
> > > > processing).
> > >
> > > Hmmm, this might cause lots of GC problems down the road... hmmmm, we
> > > should make them at least recycleable (Avalon now includes my recycle
> > > classes as well).
> >
> > I haven't looked at it at all but might help reducing GC (BTW: the first
> > C2 implementation had exactly the save behavior)
> 
> Yes, I know. Pier and I talked breafly about this and decided to fine
> tune only after development completion of the first phase... now that we
> are in the second phase (thus the new version 2.0a2), the argument still
> holds: let's get things done first and optimize later (but let's keep in
> mind where the hotspots might reside)

I'm fine with this.

> > >
> > > > Look at the interfaces:
> > > >
> > > >    Serializer
> > > >       impossible to make it thread save because of the setOutputStream
> > > >       method (it has to save it to a instance variable)
> > >
> > > Makes sense.
> > >
> > > >    Transformer/Generator
> > > >       the setup Method of the inherited SitemapModelComponent Interface
> > > >       will be critical too (as with the Serializers saving setup parameters
> > > >       to instance variables)
> > >
> > > I don't get this.
> >
> > Look what those component do with the arguments they get passed in at
> > the setup method. They save them into instance variables. If two
> > simultanious requests need the same Generator/Transformer one would
> > overwrite the setting from the other thread, right? Thus we need
> > separate objects for each request.
> 
> Ok, got it.
> 
> If you look at my Recycle code you can create methods that prepare the
> object for execution and clean it up before recycle. This is general
> enough to work with anything that must be reused. The question is if
> it's easier/less-expensive to throw them away and recreate them instead
> of recycling them.
> 
> Well, I guess we need some real life tests to evaluate this but we'll
> think about this when we are finished implementing.

Yes, might be the best to test it. I'll going close to the recycle code
from the sitemap generation point of view and implement it into the
sitemap xsl.

> > > >    Matcher/Selector:
> > > >      they must be thread save because the sitemap handles them as such
> > > > but
> > > >      these are not relevant for the purpose we are discussing here
> > >
> > > Correct.
> > >
> > > >    Generator
> > > >       Also here the XMLProducer and the SitemapModelComponent Interface
> > > >       wouldn't allow them to be thread save
> > > >
> > > > And I didn't mentioned other Interfaces like XMLConsumer
> > > > (ContentHandler) which are hardly thread save because it is likely that
> > > > one might need access to instance variables in the ContentHandler
> > > > methods.
> > > >
> > > > I mean there are ways to make an object thread save but most of these
> > > > methods aren't efficent enough in a SAX pipeline.
> > >
> > > Very good point.
> > >
> > > > One could say we can use a pool for those objects but I think this
> > > > wouldn't help at all for this purpose (which FooBarGenerator is
> > > > responsible for beeing called at destroy()).
> > >
> > > No, you're right, pooling would help in performance and memory usage,
> > > but not for the problems we are discussing here.
> > >
> > > > So, this is why I've proposed the following in a mail yesterday:
> > > >
> > > > Giacomo Pati wrote:
> > > > >
> > > > > I have no idea for C1 (I'm not familiar with C1 code). For me the
> > > > > CocoonServlet.java is meant as an example how to use C2 in a servlet
> > > > > environment and thus would suggest to hack the destroy method there
or
> > > > > subclass it an overwrite the destroy method to do what you like.
> > >
> > > Ok, I understand this comment much more now, but I still don't like
> > > people having to write their own serlvet wrapper around the Cocoon class
> > > to make it work. This would ruin the inversion of control principle big
> > > deal.
> > >
> > > But this might have an important role: the Servlet API experts are
> > > discussing ways to enforce servlets to be clusterable and distributable.
> > > Just like EJB, such servlets should not perform any machine specific
> > > things (like starting a thread or holding reference to a resource) and
> > > should use JNDI for all those things.
> > >
> > > We are using Avalon (which allows us to abstract components just like
> > > JNDI does, in fact the Avalon project is working on using JNDI as an
> > > alternative for enterprise-capable blocks and components) so might find
> > > ourselves already in shape.
> >
> > Yup, I've seen that discussions.
> >
> > > So, let's sum up:
> > >
> > > the init() method in Cocoon is equivalent to
> > > Composer.setComponentManager() or Configurable.setConfigurations(),
> > > being called after the class construction but before real-time
> > > execution.
> >
> > Exactly.
> >
> > > the destroy() method doesn't exist in Cocoon, but for servlets it's
> > > normally use to close resources that are allocated by the init() method.
> > >
> > > These resources normally are connection pools, background threads, files
> > > and all other things that good behaving servlets should _not_ have
> > > direct access to.
> > >
> > > So, how do we have something like this in Cocoon? we use Avalon!
> > >
> > > Suppose you want a connection pool:
> > >
> > > - write your Avalon component that does that
> > > - make it implement the Service interface (thus init() and destroy()
> > > will be called on you)
> > > - install this component into Cocoon
> > > - access the working instance of the component you want by implementing
> > > the Composer interface and calling the ComponentManager with the role
> > > you want. If you have several components for the same role, use the
> > > NamedComponent interface and ask for the component with the given role
> > > and wanted name.
> > >
> > > This removes the need for destroy() inside our pipeline components and
> > > remove the distribution problems that the Servlet API inherently has.
> > >
> > > So, I remove my proposal to add the destroy() method to pipeline
> > > components.
> > >
> > > Comments?
> >
> > I have to say that I'm not that familiar with Avalon behaviour. Would
> > this mean that the servlet calls Avalon for a Cocoon instance instead
> > creating it itself like it does today?
> 
> No, not at all.
> 
> The things is: if your Generator needs a Connection Pool, instead of
> using init()/destroy() cloning the Servlet lifecycle, it calles up the
> ComponentManager (or JNDI, whichever Avalon ends up using) and gets the
> instance of the connection pool and uses it.

Ok, this ComponentManager behaviour is what I already meant it is for.
One thing we have to take care of is that there are components that gets
instantiated when requested with a ComponentManager (i.e. parser)
instead of reused. I mean there is no way to say 'this is a thread safe
component, that component must be instantiated per request and the other
one should be recycled'. Does anybody has an idea how to accomplish
this? My oppinion is that such classes should implement an (possibly
empty) interfaces.

> This solves many problems that the Servlet API has and allows people to
> have services that have to be inited and destroied like services.
> 
> Is it clear enough?

Totally.

Giacomo

PWR GmbH, Organisation & Entwicklung      Tel:   +41 (0)1 856 2202
Giacomo Pati, CTO/CEO                     Fax:   +41 (0)1 856 2201
Hintereichenstrasse 7                     Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen                    Web:   http://www.pwr.ch

Mime
View raw message