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 Fri, 18 Aug 2000 23:23:06 GMT
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)

> 
> > 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.

> >    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?

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