You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Gerhard Froehlich <g-...@gmx.de> on 2001/12/09 23:44:30 UTC
Added Resource Monitor in Cocoon.java
Hi,
I implemented the Excalibur Resource Monitor into
Cocoon.java. The Resource Monitor observes now
the cocoon.xconf file and notifies Cocoon.java,
when the file has changed.
Cheers
Gerhard
"Sorry, but my karma just ran over your dogma."
Re: Added Resource Monitor in Cocoon.java
Posted by Antti Koivunen <an...@users.sourceforge.net>.
Gerhard Froehlich wrote:
>>From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>>
>>
>>Berin Loritsch a écrit :
>>
>>>Sylvain Wallez wrote:
>>>
>>>
>
> <skip/>
>
>>>Keep in mind, that I am also working on an asynchronous command structure for
>>>Avalon, something that ActiveMonitor, Pools, etc. would all be able to take
>>>advantage of. The basic gist is this:
>>>
>>>There are a number of maintenance/management tasks that components have to
>>>take at periodic times like ActiveMonitor, DataSourcePools, Cache implementations,
>>>etc. The problem is that having a whole thread for control management for
>>>each of these items is too heavy, as is performing the maintenance synchronously.
>>>
>>Have you looked at java.util.Timer in JDK1.3 ? AFAIK, it is meant for
>>this kind of things.
>>
>
> AIUI it forces for every TimerTaks an own Thread (non Deamon). When you have
> many Maintainance Taks you will have large ThreadPool and that would be a
> Performance issue again.
Actually, java.util.Timer uses a priority queue of TimerTasks, ordered
by the next execution time, and the timer thread can be run as a daemon.
A quote from JDK 1.3.1 javadocs:
"Implementation note: This class scales to large numbers of concurrently
scheduled tasks (thousands should present no problem). Internally, it
uses a binary heap to represent its task queue, so the cost to schedule
a task is O(log n), where n is the number of concurrently scheduled tasks."
> The approach here is that you have a queue, in which you put your events and
> at the end of this queue there is maybe 1-3 threads which are popping the
> events from the queue and hand them over to the corresponding EventHandler.
>
> Therefor you can have so many tasks if you want, but the number of threads
> is small...
This is exactly the idea and one of the key concepts of SEDA.
>
>
>>>Part of the lessons learned from the Staged Event Driven Architecture is that
>>>many times, you only need a small number of threads (in this case, one) to
>>>handle _all_ of your management tasks. The SEDA architecture goes so far as
>>>to apply this to all I/O as it is asynchronous in that architecture. The
>>>scalability of the solution is insane. For instance, a plain HTTP server
>>>built on top of the SEDA architecture was able to handle 10,000 simultaneous
>>>connections and outperform Apache httpd using IBM JDK 1.1.8 on a Linux box
>>>with 4 500 MHz processors and a Gig of RAM. Apache only made it to about
>>>512 simultaneous connections due to process per user limitations--not to
>>>mention several requests took much longer....
>>>
>>I definitely have to read this stuff...
>>
>
> It's quite interesting...
>
>
>>>I am not proposing the SEDA architecture for Cocoon (although I might examine
>>>a simple HTTP implementation that supports Servlets later).....
>>>
>>>I am proposing the migration towards an infrastructure where maintenance
>>>commands can be performed asynchronously--and checking for source file
>>>changes is only one of those commands.
>>>
>>We have to identify what are those tasks that need to be done
>>periodically and those that don't need it.
>>
>>I would say that checking configuration file changes doesn't need to be
>>done asynchronously, for several reasons :
>>- in a production environment, these files aren't likely to change
>>often, and thus periodic check is most often a waste of time,
>>- in a development environment, people that change these files
>>immediately issue a request to check the effect of the change.
>>Synchronous (possibly deferred) check is then IMO more adequate.
>>
>>Cache management, on the contrary, can be considered the other way :
>>even in a production environment, periodic asynchronous check effecively
>>has something to do, which is purge cache entries associated to changed
>>resources. This isn't absolutely needed from a functional point of view
>>but allows to free earlier some memory/disk resources that would without
>>that have been freed later by the MRU policy.
>>
>
> Be careful, at the end you have for every special case a special solution.
> Personally I want something more generic, which fits for the most cases.
Without getting into Cocoon internals (not an expert, _yet_ ;), in the
long run, it would be nice to have a generic "scheduled task management"
architecture, probably based on the event handling model. In addition to
providing a consistent API, it should really help to improve
scalability, and make things easier to manage (self-adjusting Pool,
Cache implementations [with fewer threads], less external I/O, etc.)
(: Anrie ;)
>
>
>>>I am also going to supply a PoolResource implementation in the next version
>>>of Excalibur so that we can now *gasp* get the internal information of the
>>>Pool implementations of Cocoon's resources! How about them apples?
>>>
>>Aahh, this would be really great :)
>>
>>
>>>But you have to start somewhere....
>>>
>>>
>>>>>If you want, I remove this stuff for now, but only for a clean reboot of this
>>>>>issue ;-).
>>>>>
>>>>>
>>>>Let's keep it for now, until we decide if this is the right way to go or
>>>>not. I will try to spend some time for show-casing the strategy I
>>>>proposed, so people can look at both.
>>>>
>>>:)
>>>
>>>Your solution works for the file issue, but the asyncronous maintenance issues
>>>are something completely different.
>>>
>>Agree. That's why we have to carefully identify those things that need
>>asynchronous management.
>>
>>BTW, I added a new components.source.DelayedLastModified and updated
>>sitemap.Handler to showcase deferred calls to Source.getLastModified().
>>Please have a look at it.
>>
>>
>
> Gerhard
>
> "Three o'clock is always too late or too early for
> anything you want to do.
> (Jean-Paul Sartre)"
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Added Resource Monitor in Cocoon.java
Posted by Gerhard Froehlich <g-...@gmx.de>.
>From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>
>
>Berin Loritsch a écrit :
>>
>> Sylvain Wallez wrote:
>>
<skip/>
>>
>> Keep in mind, that I am also working on an asynchronous command structure for
>> Avalon, something that ActiveMonitor, Pools, etc. would all be able to take
>> advantage of. The basic gist is this:
>>
>> There are a number of maintenance/management tasks that components have to
>> take at periodic times like ActiveMonitor, DataSourcePools, Cache implementations,
>> etc. The problem is that having a whole thread for control management for
>> each of these items is too heavy, as is performing the maintenance synchronously.
>
>Have you looked at java.util.Timer in JDK1.3 ? AFAIK, it is meant for
>this kind of things.
AIUI it forces for every TimerTaks an own Thread (non Deamon). When you have
many Maintainance Taks you will have large ThreadPool and that would be a
Performance issue again.
The approach here is that you have a queue, in which you put your events and
at the end of this queue there is maybe 1-3 threads which are popping the
events from the queue and hand them over to the corresponding EventHandler.
Therefor you can have so many tasks if you want, but the number of threads
is small...
>> Part of the lessons learned from the Staged Event Driven Architecture is that
>> many times, you only need a small number of threads (in this case, one) to
>> handle _all_ of your management tasks. The SEDA architecture goes so far as
>> to apply this to all I/O as it is asynchronous in that architecture. The
>> scalability of the solution is insane. For instance, a plain HTTP server
>> built on top of the SEDA architecture was able to handle 10,000 simultaneous
>> connections and outperform Apache httpd using IBM JDK 1.1.8 on a Linux box
>> with 4 500 MHz processors and a Gig of RAM. Apache only made it to about
>> 512 simultaneous connections due to process per user limitations--not to
>> mention several requests took much longer....
>
>I definitely have to read this stuff...
It's quite interesting...
>> I am not proposing the SEDA architecture for Cocoon (although I might examine
>> a simple HTTP implementation that supports Servlets later).....
>>
>> I am proposing the migration towards an infrastructure where maintenance
>> commands can be performed asynchronously--and checking for source file
>> changes is only one of those commands.
>
>We have to identify what are those tasks that need to be done
>periodically and those that don't need it.
>
>I would say that checking configuration file changes doesn't need to be
>done asynchronously, for several reasons :
>- in a production environment, these files aren't likely to change
>often, and thus periodic check is most often a waste of time,
>- in a development environment, people that change these files
>immediately issue a request to check the effect of the change.
>Synchronous (possibly deferred) check is then IMO more adequate.
>
>Cache management, on the contrary, can be considered the other way :
>even in a production environment, periodic asynchronous check effecively
>has something to do, which is purge cache entries associated to changed
>resources. This isn't absolutely needed from a functional point of view
>but allows to free earlier some memory/disk resources that would without
>that have been freed later by the MRU policy.
Be careful, at the end you have for every special case a special solution.
Personally I want something more generic, which fits for the most cases.
>> I am also going to supply a PoolResource implementation in the next version
>> of Excalibur so that we can now *gasp* get the internal information of the
>> Pool implementations of Cocoon's resources! How about them apples?
>
>Aahh, this would be really great :)
>
>> But you have to start somewhere....
>>
>> >>If you want, I remove this stuff for now, but only for a clean reboot of this
>> >>issue ;-).
>> >>
>> >
>> > Let's keep it for now, until we decide if this is the right way to go or
>> > not. I will try to spend some time for show-casing the strategy I
>> > proposed, so people can look at both.
>>
>> :)
>>
>> Your solution works for the file issue, but the asyncronous maintenance issues
>> are something completely different.
>
>Agree. That's why we have to carefully identify those things that need
>asynchronous management.
>
>BTW, I added a new components.source.DelayedLastModified and updated
>sitemap.Handler to showcase deferred calls to Source.getLastModified().
>Please have a look at it.
>
Gerhard
"Three o'clock is always too late or too early for
anything you want to do.
(Jean-Paul Sartre)"
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Added Resource Monitor in Cocoon.java
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Berin Loritsch a écrit :
>
> Sylvain Wallez wrote:
>
> >
> > Gerhard Froehlich a écrit :
> >
>
> >>All your arguments above are correct. For the Cocoon.java the ActiveMonitor is
> >>overkill, but what do you want? The Cocoon.java was a starting point to implement
> >>a central Resource Monitoring to reduce our huge lastModified calls. Maybe
> >>Cocoon.java is not right Example for lastModified calls. But look into
> >>the piplines (even CachingxxxPiplines).
> >>Somebody has to start, I did. Which way shall we take? Is this an
> >>issue or not?
> >>That's my question now!
> >>If not we can stop here now. If yes then we should search for a solution
> >>which fits.
> >>
> >
> > Sorry if I offended you. I agree with your last sentence, but I was
> > afraid some important design decision would be taken too quickly just
> > because some code is in. As I seem to be the only one to have a
> > different opinion on this subject, I wanted to say it loud, because you
> > are coding so fast :)
>
> Keep in mind, that I am also working on an asynchronous command structure for
> Avalon, something that ActiveMonitor, Pools, etc. would all be able to take
> advantage of. The basic gist is this:
>
> There are a number of maintenance/management tasks that components have to
> take at periodic times like ActiveMonitor, DataSourcePools, Cache implementations,
> etc. The problem is that having a whole thread for control management for
> each of these items is too heavy, as is performing the maintenance synchronously.
Have you looked at java.util.Timer in JDK1.3 ? AFAIK, it is meant for
this kind of things.
> Part of the lessons learned from the Staged Event Driven Architecture is that
> many times, you only need a small number of threads (in this case, one) to
> handle _all_ of your management tasks. The SEDA architecture goes so far as
> to apply this to all I/O as it is asynchronous in that architecture. The
> scalability of the solution is insane. For instance, a plain HTTP server
> built on top of the SEDA architecture was able to handle 10,000 simultaneous
> connections and outperform Apache httpd using IBM JDK 1.1.8 on a Linux box
> with 4 500 MHz processors and a Gig of RAM. Apache only made it to about
> 512 simultaneous connections due to process per user limitations--not to
> mention several requests took much longer....
I definitely have to read this stuff...
> I am not proposing the SEDA architecture for Cocoon (although I might examine
> a simple HTTP implementation that supports Servlets later).....
>
> I am proposing the migration towards an infrastructure where maintenance
> commands can be performed asynchronously--and checking for source file
> changes is only one of those commands.
We have to identify what are those tasks that need to be done
periodically and those that don't need it.
I would say that checking configuration file changes doesn't need to be
done asynchronously, for several reasons :
- in a production environment, these files aren't likely to change
often, and thus periodic check is most often a waste of time,
- in a development environment, people that change these files
immediately issue a request to check the effect of the change.
Synchronous (possibly deferred) check is then IMO more adequate.
Cache management, on the contrary, can be considered the other way :
even in a production environment, periodic asynchronous check effecively
has something to do, which is purge cache entries associated to changed
resources. This isn't absolutely needed from a functional point of view
but allows to free earlier some memory/disk resources that would without
that have been freed later by the MRU policy.
> I am also going to supply a PoolResource implementation in the next version
> of Excalibur so that we can now *gasp* get the internal information of the
> Pool implementations of Cocoon's resources! How about them apples?
Aahh, this would be really great :)
> But you have to start somewhere....
>
> >>If you want, I remove this stuff for now, but only for a clean reboot of this
> >>issue ;-).
> >>
> >
> > Let's keep it for now, until we decide if this is the right way to go or
> > not. I will try to spend some time for show-casing the strategy I
> > proposed, so people can look at both.
>
> :)
>
> Your solution works for the file issue, but the asyncronous maintenance issues
> are something completely different.
Agree. That's why we have to carefully identify those things that need
asynchronous management.
BTW, I added a new components.source.DelayedLastModified and updated
sitemap.Handler to showcase deferred calls to Source.getLastModified().
Please have a look at it.
Sylvain.
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Added Resource Monitor in Cocoon.java
Posted by Gerhard Froehlich <g-...@gmx.de>.
>From: Berin Loritsch [mailto:bloritsch@apache.org]
>
>Sylvain Wallez wrote:
>
>>
>> Gerhard Froehlich a écrit :
>>
>
>>>All your arguments above are correct. For the Cocoon.java the ActiveMonitor is
>>>overkill, but what do you want? The Cocoon.java was a starting point to implement
>>>a central Resource Monitoring to reduce our huge lastModified calls. Maybe
>>>Cocoon.java is not right Example for lastModified calls. But look into
>>>the piplines (even CachingxxxPiplines).
>>>Somebody has to start, I did. Which way shall we take? Is this an
>>>issue or not?
>>>That's my question now!
>>>If not we can stop here now. If yes then we should search for a solution
>>>which fits.
>>>
>>
>> Sorry if I offended you. I agree with your last sentence, but I was
>> afraid some important design decision would be taken too quickly just
>> because some code is in. As I seem to be the only one to have a
>> different opinion on this subject, I wanted to say it loud, because you
>> are coding so fast :)
>
>
>Keep in mind, that I am also working on an asynchronous command structure for
>Avalon, something that ActiveMonitor, Pools, etc. would all be able to take
>advantage of. The basic gist is this:
Yeah, right _asynchronous_ that's the magic word here. I think that's the main
difference to the Sylvains more synchronous idea -in honor-!
>There are a number of maintenance/management tasks that components have to
>take at periodic times like ActiveMonitor, DataSourcePools, Cache implementations,
>etc. The problem is that having a whole thread for control management for
>each of these items is too heavy, as is performing the maintenance synchronously.
Totaly agree.
>Part of the lessons learned from the Staged Event Driven Architecture is that
>many times, you only need a small number of threads (in this case, one) to
>handle _all_ of your management tasks. The SEDA architecture goes so far as
>to apply this to all I/O as it is asynchronous in that architecture. The
>scalability of the solution is insane. For instance, a plain HTTP server
>built on top of the SEDA architecture was able to handle 10,000 simultaneous
>connections and outperform Apache httpd using IBM JDK 1.1.8 on a Linux box
>with 4 500 MHz processors and a Gig of RAM. Apache only made it to about
>512 simultaneous connections due to process per user limitations--not to
>mention several requests took much longer....
>
>I am not proposing the SEDA architecture for Cocoon (although I might examine
>a simple HTTP implementation that supports Servlets later).....
>
>I am proposing the migration towards an infrastructure where maintenance
>commands can be performed asynchronously--and checking for source file
>changes is only one of those commands.
I totaly agree with you in the points above.
I can identify just for the Store Management different events, like JVM Memory
controls, Store size, Filesystem clean up, Hastable optimization, etc....
With the normal Thread based approach this would be covered with different threads,
like now! This costs performance and resources!
Buuuut don't underestimate the effort to manage the result of your events back
to the action (through queues, either). But that's a part of the Asynchron I/O
issue in the SEDA design (damn I've to re-read this stuff).
>I am also going to supply a PoolResource implementation in the next version
>of Excalibur so that we can now *gasp* get the internal information of the
>Pool implementations of Cocoon's resources! How about them apples?
>
>But you have to start somewhere....
:-) I know where.
>>>If you want, I remove this stuff for now, but only for a clean reboot of this
>>>issue ;-).
>>>
>>
>> Let's keep it for now, until we decide if this is the right way to go or
>> not. I will try to spend some time for show-casing the strategy I
>> proposed, so people can look at both.
Gerhard
"Confucius say too much.
(Recent Chinese Proverb)"
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Added Resource Monitor in Cocoon.java
Posted by Berin Loritsch <bl...@apache.org>.
Sylvain Wallez wrote:
>
> Gerhard Froehlich a écrit :
>
>>All your arguments above are correct. For the Cocoon.java the ActiveMonitor is
>>overkill, but what do you want? The Cocoon.java was a starting point to implement
>>a central Resource Monitoring to reduce our huge lastModified calls. Maybe
>>Cocoon.java is not right Example for lastModified calls. But look into
>>the piplines (even CachingxxxPiplines).
>>Somebody has to start, I did. Which way shall we take? Is this an
>>issue or not?
>>That's my question now!
>>If not we can stop here now. If yes then we should search for a solution
>>which fits.
>>
>
> Sorry if I offended you. I agree with your last sentence, but I was
> afraid some important design decision would be taken too quickly just
> because some code is in. As I seem to be the only one to have a
> different opinion on this subject, I wanted to say it loud, because you
> are coding so fast :)
Keep in mind, that I am also working on an asynchronous command structure for
Avalon, something that ActiveMonitor, Pools, etc. would all be able to take
advantage of. The basic gist is this:
There are a number of maintenance/management tasks that components have to
take at periodic times like ActiveMonitor, DataSourcePools, Cache implementations,
etc. The problem is that having a whole thread for control management for
each of these items is too heavy, as is performing the maintenance synchronously.
Part of the lessons learned from the Staged Event Driven Architecture is that
many times, you only need a small number of threads (in this case, one) to
handle _all_ of your management tasks. The SEDA architecture goes so far as
to apply this to all I/O as it is asynchronous in that architecture. The
scalability of the solution is insane. For instance, a plain HTTP server
built on top of the SEDA architecture was able to handle 10,000 simultaneous
connections and outperform Apache httpd using IBM JDK 1.1.8 on a Linux box
with 4 500 MHz processors and a Gig of RAM. Apache only made it to about
512 simultaneous connections due to process per user limitations--not to
mention several requests took much longer....
I am not proposing the SEDA architecture for Cocoon (although I might examine
a simple HTTP implementation that supports Servlets later).....
I am proposing the migration towards an infrastructure where maintenance
commands can be performed asynchronously--and checking for source file
changes is only one of those commands.
I am also going to supply a PoolResource implementation in the next version
of Excalibur so that we can now *gasp* get the internal information of the
Pool implementations of Cocoon's resources! How about them apples?
But you have to start somewhere....
>>If you want, I remove this stuff for now, but only for a clean reboot of this
>>issue ;-).
>>
>
> Let's keep it for now, until we decide if this is the right way to go or
> not. I will try to spend some time for show-casing the strategy I
> proposed, so people can look at both.
:)
Your solution works for the file issue, but the asyncronous maintenance issues
are something completely different.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Added Resource Monitor in Cocoon.java
Posted by Stefano Mazzocchi <st...@apache.org>.
Gerhard Froehlich wrote:
> >So let's discuss the two strategies (ActiveMonitor / delayed system
> >calls) and see what finally comes out. It would be good also if other
> >people come in this discussion.
>
> Yeah would be great. Stefano hint, hint ;)
In all honesty, I think you guys (you, Sylvain and Berin) are doing a
great job, I don't have much to add. Besides, I already have so many
irons in the fire... :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Added Resource Monitor in Cocoon.java
Posted by Gerhard Froehlich <g-...@gmx.de>.
Sylvain,
>From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>
>
>Gerhard Froehlich a écrit :
>>
>> Sylvain,
>> >From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>> >
>> >
>> >Gerhard Froehlich a écrit :
>> >>
>> >> Hi,
>> >> I implemented the Excalibur Resource Monitor into
>> >> Cocoon.java. The Resource Monitor observes now
>> >> the cocoon.xconf file and notifies Cocoon.java,
>> >> when the file has changed.
>> >>
>> >> Cheers
>> >> Gerhard
>> >>
>> >
>> >Sorry to be so annoying about resource and monitors, but from a design
>> >point of view, I think using ActiveMonitor this way is overkill.
>>
>> No problem, dude. False pride is unsuitable, searching for the
>> most perfect solution is suitable!
>>
>> >As Berin said, the purpose of ActiveMonitor is to trigger some action
>> >when a resource changes. Just changing the "lastModified" attribute
>> >isn't IMO an action that justifies a background thread to periodically
>> >monitor the filesystem.
>> >
>> >On the other hand, the FileResource with delayed call to
>> >File.lastModified() I proposed yesterday (see
>> >http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100799905918225&w=2 )
>> >seems to me more appropriate in this case :
>> >
>> >- only Cocoon uses cocoon.xconf, and it already keeps the associated
>> >Source object as an attribute. So there's no need to register it in a
>> >centralized monitor.
>> >
>> >- like ActiveMonitor, it reduces the number of filesystem calls and
>> >ensures the age of the "lastModified" information isn't greater that the
>> >refresh period, but unlike ActiveMonitor, doesn't refresh it
>> >unnecessarily at _every_ refresh period.
>> >
>> >Thoughts ?
>>
>> All your arguments above are correct. For the Cocoon.java the ActiveMonitor is
>> overkill, but what do you want? The Cocoon.java was a starting point to implement
>> a central Resource Monitoring to reduce our huge lastModified calls. Maybe
>> Cocoon.java is not right Example for lastModified calls. But look into
>> the piplines (even CachingxxxPiplines).
>> Somebody has to start, I did. Which way shall we take? Is this an
>> issue or not?
>> That's my question now!
>> If not we can stop here now. If yes then we should search for a solution
>> which fits.
>
>Sorry if I offended you. I agree with your last sentence, but I was
I'm not offended! A quote from the actual flame war against jon in the
jakarta-general list "if you can't take the heat, then get out of the kitchen."
>afraid some important design decision would be taken too quickly just
>because some code is in. As I seem to be the only one to have a
>different opinion on this subject, I wanted to say it loud, because you
>are coding so fast :)
Hehe nice said. Maybe it was a little bit hasty the whole think, but
we learnd much, eh?
>So let's discuss the two strategies (ActiveMonitor / delayed system
>calls) and see what finally comes out. It would be good also if other
>people come in this discussion.
Yeah would be great. Stefano hint, hint ;)
>> <flame_point>
>> Sometimes I've the feeling the devs here are so keen on
>> integrating fancy and sexy new stuff into Cocoon that they forget the basis!
>> </flame_point>
>
>No flame from me here. I've spent and still spend much time (more
>commits soon) correcting some non-blocking bugs that are annoying me in
>my daily work.
>
>> If you want, I remove this stuff for now, but only for a clean reboot of this
>> issue ;-).
>
>Let's keep it for now, until we decide if this is the right way to go or
>not. I will try to spend some time for show-casing the strategy I
>proposed, so people can look at both.
Yupp as you want. No problem for me to remove this bit of code...
Cheers
Gerhard
---------------------------------
Never share a foxhole with anyone
braver than you are.
---------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Added Resource Monitor in Cocoon.java
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Gerhard Froehlich a écrit :
>
> Sylvain,
> >From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> >
> >
> >Gerhard Froehlich a écrit :
> >>
> >> Hi,
> >> I implemented the Excalibur Resource Monitor into
> >> Cocoon.java. The Resource Monitor observes now
> >> the cocoon.xconf file and notifies Cocoon.java,
> >> when the file has changed.
> >>
> >> Cheers
> >> Gerhard
> >>
> >
> >Sorry to be so annoying about resource and monitors, but from a design
> >point of view, I think using ActiveMonitor this way is overkill.
>
> No problem, dude. False pride is unsuitable, searching for the
> most perfect solution is suitable!
>
> >As Berin said, the purpose of ActiveMonitor is to trigger some action
> >when a resource changes. Just changing the "lastModified" attribute
> >isn't IMO an action that justifies a background thread to periodically
> >monitor the filesystem.
> >
> >On the other hand, the FileResource with delayed call to
> >File.lastModified() I proposed yesterday (see
> >http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100799905918225&w=2 )
> >seems to me more appropriate in this case :
> >
> >- only Cocoon uses cocoon.xconf, and it already keeps the associated
> >Source object as an attribute. So there's no need to register it in a
> >centralized monitor.
> >
> >- like ActiveMonitor, it reduces the number of filesystem calls and
> >ensures the age of the "lastModified" information isn't greater that the
> >refresh period, but unlike ActiveMonitor, doesn't refresh it
> >unnecessarily at _every_ refresh period.
> >
> >Thoughts ?
>
> All your arguments above are correct. For the Cocoon.java the ActiveMonitor is
> overkill, but what do you want? The Cocoon.java was a starting point to implement
> a central Resource Monitoring to reduce our huge lastModified calls. Maybe
> Cocoon.java is not right Example for lastModified calls. But look into
> the piplines (even CachingxxxPiplines).
> Somebody has to start, I did. Which way shall we take? Is this an
> issue or not?
> That's my question now!
> If not we can stop here now. If yes then we should search for a solution
> which fits.
Sorry if I offended you. I agree with your last sentence, but I was
afraid some important design decision would be taken too quickly just
because some code is in. As I seem to be the only one to have a
different opinion on this subject, I wanted to say it loud, because you
are coding so fast :)
So let's discuss the two strategies (ActiveMonitor / delayed system
calls) and see what finally comes out. It would be good also if other
people come in this discussion.
> <flame_point>
> Sometimes I've the feeling the devs here are so keen on
> integrating fancy and sexy new stuff into Cocoon that they forget the basis!
> </flame_point>
No flame from me here. I've spent and still spend much time (more
commits soon) correcting some non-blocking bugs that are annoying me in
my daily work.
> If you want, I remove this stuff for now, but only for a clean reboot of this
> issue ;-).
Let's keep it for now, until we decide if this is the right way to go or
not. I will try to spend some time for show-casing the strategy I
proposed, so people can look at both.
Sylvain.
> Cheers
> Gerhard
>
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Added Resource Monitor in Cocoon.java
Posted by Gerhard Froehlich <g-...@gmx.de>.
Sylvain,
>From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>
>
>Gerhard Froehlich a écrit :
>>
>> Hi,
>> I implemented the Excalibur Resource Monitor into
>> Cocoon.java. The Resource Monitor observes now
>> the cocoon.xconf file and notifies Cocoon.java,
>> when the file has changed.
>>
>> Cheers
>> Gerhard
>>
>
>Sorry to be so annoying about resource and monitors, but from a design
>point of view, I think using ActiveMonitor this way is overkill.
No problem, dude. False pride is unsuitable, searching for the
most perfect solution is suitable!
>As Berin said, the purpose of ActiveMonitor is to trigger some action
>when a resource changes. Just changing the "lastModified" attribute
>isn't IMO an action that justifies a background thread to periodically
>monitor the filesystem.
>
>On the other hand, the FileResource with delayed call to
>File.lastModified() I proposed yesterday (see
>http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100799905918225&w=2 )
>seems to me more appropriate in this case :
>
>- only Cocoon uses cocoon.xconf, and it already keeps the associated
>Source object as an attribute. So there's no need to register it in a
>centralized monitor.
>
>- like ActiveMonitor, it reduces the number of filesystem calls and
>ensures the age of the "lastModified" information isn't greater that the
>refresh period, but unlike ActiveMonitor, doesn't refresh it
>unnecessarily at _every_ refresh period.
>
>Thoughts ?
All your arguments above are correct. For the Cocoon.java the ActiveMonitor is
overkill, but what do you want? The Cocoon.java was a starting point to implement
a central Resource Monitoring to reduce our huge lastModified calls. Maybe
Cocoon.java is not right Example for lastModified calls. But look into
the piplines (even CachingxxxPiplines).
Somebody has to start, I did. Which way shall we take? Is this an
issue or not?
That's my question now!
If not we can stop here now. If yes then we should search for a solution
which fits.
<flame_point>
Sometimes I've the feeling the devs here are so keen on
integrating fancy and sexy new stuff into Cocoon that they forget the basis!
</flame_point>
If you want, I remove this stuff for now, but only for a clean reboot of this
issue ;-).
Cheers
Gerhard
------------------------------------------------------------------
Calvin: People think it must be fun to be a super genius, but they
don't realize how hard it is to put up with all the idiots in the
world.
Hobbes: Isn't your pants' zipper supposed to be in the front?
------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Added Resource Monitor in Cocoon.java
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Gerhard Froehlich a écrit :
>
> Hi,
> I implemented the Excalibur Resource Monitor into
> Cocoon.java. The Resource Monitor observes now
> the cocoon.xconf file and notifies Cocoon.java,
> when the file has changed.
>
> Cheers
> Gerhard
>
Sorry to be so annoying about resource and monitors, but from a design
point of view, I think using ActiveMonitor this way is overkill.
As Berin said, the purpose of ActiveMonitor is to trigger some action
when a resource changes. Just changing the "lastModified" attribute
isn't IMO an action that justifies a background thread to periodically
monitor the filesystem.
On the other hand, the FileResource with delayed call to
File.lastModified() I proposed yesterday (see
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100799905918225&w=2 )
seems to me more appropriate in this case :
- only Cocoon uses cocoon.xconf, and it already keeps the associated
Source object as an attribute. So there's no need to register it in a
centralized monitor.
- like ActiveMonitor, it reduces the number of filesystem calls and
ensures the age of the "lastModified" information isn't greater that the
refresh period, but unlike ActiveMonitor, doesn't refresh it
unnecessarily at _every_ refresh period.
Thoughts ?
Sylvain.
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org