cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Shutdown of an producer
Date Fri, 18 Aug 2000 13:14:07 GMT
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).

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

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

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.

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?
 
> Comments are very welcome (could be that I am blinded by something :)
> 
> 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


-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Mime
View raw message