You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Conny Kreyßel <Co...@inter-forum.de> on 2000/08/15 17:06:41 UTC
Shutdown of an producer
How can I make it sure that when cocoon will shutdown that I will informed
that I can close all my open connections?
-Conny-
Re: Shutdown of an producer
Posted by Stefano Mazzocchi <st...@apache.org>.
Giacomo Pati wrote:
> 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.
Why don't you post such a question to the Avalon mail list. I recall
talking with Federico about exactly this, but I don't know his plans on
this.
> > 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.
Cool.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Shutdown of an producer
Posted by Giacomo Pati <Gi...@pwr.ch>.
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
Re: Shutdown of an producer
Posted by "Pier P. Fumagalli" <pi...@apache.org>.
Stefano Mazzocchi wrote:
>
> Nice to have you back, my friend. :)
>
> I, from my side, missed you very much and I'm happy things got cleared
> up for you.
>
> Welcome back!
I'm not "back".... Just reading email...
Pier
Re: Shutdown of an producer
Posted by Stefano Mazzocchi <st...@apache.org>.
"Pier P. Fumagalli" wrote:
>
> Stefano Mazzocchi wrote:
> > Giacomo Pati wrote:
> > > Stefano Mazzocchi wrote:
> > > > Giacomo Pati wrote:
> > > > >
> > > > > 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)
>
> There should be hooks where objects can be recycled in the C2 code (as I
> left it months ago)... But I never wrote anything to actually recycle
> those objects.
> I agree w/ Stefano, leave hooks for optimization (such as pools and
> recyclable objects) but it might be better to have something working
> before writing the actual "optimized" code.
Nice to have you back, my friend. :)
I, from my side, missed you very much and I'm happy things got cleared
up for you.
Welcome back!
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Shutdown of an producer
Posted by Giacomo Pati <Gi...@pwr.ch>.
"Pier P. Fumagalli" wrote:
>
> Stefano Mazzocchi wrote:
> > Giacomo Pati wrote:
> > > Stefano Mazzocchi wrote:
> > > > Giacomo Pati wrote:
> > > > >
> > > > > 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)
>
Hi Pier :)
Welcome back.
> There should be hooks where objects can be recycled in the C2 code (as I
> left it months ago)... But I never wrote anything to actually recycle
> those objects.
I know, but code has changed much since your first donation. I don't
know if you have watched the list. The sitemap is know compiled by use
of XSP. The hooks might have been gone :)
> I agree w/ Stefano, leave hooks for optimization (such as pools and
> recyclable objects) but it might be better to have something working
> before writing the actual "optimized" code.
I'll see where to insert FIXMEs to mark those places.
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
Re: Shutdown of an producer
Posted by "Pier P. Fumagalli" <pi...@apache.org>.
Stefano Mazzocchi wrote:
> Giacomo Pati wrote:
> > Stefano Mazzocchi wrote:
> > > Giacomo Pati wrote:
> > > >
> > > > 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)
There should be hooks where objects can be recycled in the C2 code (as I
left it months ago)... But I never wrote anything to actually recycle
those objects.
I agree w/ Stefano, leave hooks for optimization (such as pools and
recyclable objects) but it might be better to have something working
before writing the actual "optimized" code.
Pier
Re: Shutdown of an producer
Posted by Stefano Mazzocchi <st...@apache.org>.
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)
> >
> > > 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.
> > > 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.
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?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Shutdown of an producer
Posted by Giacomo Pati <Gi...@pwr.ch>.
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
Re: Shutdown of an producer
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Shutdown of an producer
Posted by Giacomo Pati <Gi...@pwr.ch>.
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).
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)
Transformer/Generator
the setup Method of the inherited SitemapModelComponent Interface
will be critical too (as with the Serializers saving setup
parameters
to instance variables)
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
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.
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()).
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.
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
Re: Shutdown of an producer
Posted by Ricardo Rocha <ri...@apache.org>.
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
Re: Shutdown of an producer
Posted by Stefano Mazzocchi <st...@apache.org>.
Giacomo Pati wrote:
>
> Giacomo Pati wrote:
> >
> > Stefano Mazzocchi wrote:
> > >
> > > Conny Kreyßel wrote:
> > > >
> > > > How can I make it sure that when cocoon will shutdown that I will informed
> > > > that I can close all my open connections?
> > > >
> > > > -Conny-
> > >
> > > Oh, you can't in Cocoon1 but I totally agree we -have- to have something
> > > like this for Cocoon2...
> > >
> > > Giacomo, is this the case today?
> >
> > No.
>
> Sorry, I hit the send button too quick :)
>
> What does 'when cocoon will shutdown' mean? I don't get this? The
> servlet part of C2 will be called at the destroy method. Isn't that
> enough 'beeing informed'?
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?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Shutdown of an producer
Posted by Giacomo Pati <Gi...@pwr.ch>.
Giacomo Pati wrote:
>
> Stefano Mazzocchi wrote:
> >
> > Conny Kreyßel wrote:
> > >
> > > How can I make it sure that when cocoon will shutdown that I will informed
> > > that I can close all my open connections?
> > >
> > > -Conny-
> >
> > Oh, you can't in Cocoon1 but I totally agree we -have- to have something
> > like this for Cocoon2...
> >
> > Giacomo, is this the case today?
>
> No.
Sorry, I hit the send button too quick :)
What does 'when cocoon will shutdown' mean? I don't get this? The
servlet part of C2 will be called at the destroy method. Isn't that
enough 'beeing informed'?
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
Re: Shutdown of an producer
Posted by Giacomo Pati <Gi...@pwr.ch>.
Stefano Mazzocchi wrote:
>
> Conny Kreyßel wrote:
> >
> > How can I make it sure that when cocoon will shutdown that I will informed
> > that I can close all my open connections?
> >
> > -Conny-
>
> Oh, you can't in Cocoon1 but I totally agree we -have- to have something
> like this for Cocoon2...
>
> Giacomo, is this the case today?
No.
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
Re: Shutdown of an producer
Posted by Stefano Mazzocchi <st...@apache.org>.
Conny Kreyßel wrote:
>
> How can I make it sure that when cocoon will shutdown that I will informed
> that I can close all my open connections?
>
> -Conny-
Oh, you can't in Cocoon1 but I totally agree we -have- to have something
like this for Cocoon2...
Giacomo, is this the case today?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------