Giacomo Pati wrote:
On Tue, 2 Nov 2004, Vadim Gritsenko wrote:
Giacomo Pati wrote:
Ok, guys, lets see if we can find a consensus for this issue.
The issues have been:
- Excalibur Event package is deprecated. We need a replacement of those
functionalities we are in need for the core (scheduling
On Fri, 5 Nov 2004, Vadim Gritsenko wrote:
Giacomo Pati wrote:
A thread pool consists of:
- max. # of threads that run simultaneously
- a possible queue to stack up ready to run Runnables
If you have a lot of short living Runnables at low priority (logically)
you'd prefere to have a thread pool
On Wed, 3 Nov 2004, Henrik Gustafsson wrote:
And you will never need to cancel a scheduled command, or?
IIRC Excalibur Event didn't have that as well. A ThreadPool can be
shutdown, sure. But for more use the cron block.
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML
Ok, guys, lets see if we can find a consensus for this issue.
The issues have been:
- Excalibur Event package is deprecated. We need a replacement of those
functionalities we are in need for the core (scheduling Runnables once,
with delays, periodically)
- Some stated that the cron block seems
Giacomo Pati wrote:
Ok, guys, lets see if we can find a consensus for this issue.
The issues have been:
- Excalibur Event package is deprecated. We need a replacement of those
functionalities we are in need for the core (scheduling Runnables once,
with delays, periodically)
- Some stated that
On Tue, 2 Nov 2004, Vadim Gritsenko wrote:
Giacomo Pati wrote:
Ok, guys, lets see if we can find a consensus for this issue.
The issues have been:
- Excalibur Event package is deprecated. We need a replacement of those
functionalities we are in need for the core (scheduling Runnables once,
with
From: Giacomo Pati [EMAIL PROTECTED]
Ok, guys, lets see if we can find a consensus for this issue.
The issues have been:
- Excalibur Event package is deprecated. We need a replacement of those
functionalities we are in need for the core (scheduling Runnables once,
with delays, periodically)
-
Giacomo Pati wrote:
And eliminating ALL spawing of new Threads in the code will
eventually allow us to be more J2EE spec conformant (I do
know of prominent J2EE app servers Cocoon isn't able to run
in just because of spawning own sub threads).
Yepp.
I think this is on of our core
Giacomo Pati wrote:
I suppose in the trunk only (not in 2.1) or did you strip off
ALL event package references?
I didn't change anything in 2.1 - but I guess that the event package
is only used in the continuations manager in 2.1 as well. if that is
the case, change 2.1 as well and we are
On Sat, 30 Oct 2004, Carsten Ziegeler wrote:
Giacomo Pati wrote:
I suppose in the trunk only (not in 2.1) or did you strip off
ALL event package references?
I didn't change anything in 2.1 - but I guess that the event package
is only used in the continuations manager in 2.1 as well. if that is
the
On Oct 30, 2004, at 6:17 AM, Giacomo Pati wrote:
On Sat, 30 Oct 2004, Carsten Ziegeler wrote:
Giacomo Pati wrote:
I suppose in the trunk only (not in 2.1) or did you strip off
ALL event package references?
I didn't change anything in 2.1 - but I guess that the event package
is only used in the
Peter Royal wrote:
Why Quartz vs Event?
Given the requirements that Vadim laid out:
* Continuation manager.
Need to execute single task periodically.
* Store janitor.
Need to execute single task periodically.
* DefaultIncludeCacheManager.
Need to execute single
Carsten Ziegeler wrote:
I think the key point is that we are using Quartz as the implementation,
but not as the interface. Now we already have the quartz block with
the required implementation, so it's easy to use that.
The first step is to do this move. If then someone things that an
own
Ralph Goers wrote:
I'm not saying don't do this, but I am asking if this is
really what you want. After briefly looking at the Event
interface and the Cron block, they appear to be very
different. The Cron block appears to be about job
scheduling, which is fine if that is really what
On 30-okt-04, at 18:46, Ralph Goers wrote:
Carsten Ziegeler wrote:
I think the key point is that we are using Quartz as the
implementation,
but not as the interface. Now we already have the quartz block with
the required implementation, so it's easy to use that.
The first step is to do this move.
On Sat, 30 Oct 2004, Unico Hommes wrote:
On 30-okt-04, at 18:46, Ralph Goers wrote:
Carsten Ziegeler wrote:
I think the key point is that we are using Quartz as the
implementation,
but not as the interface. Now we already have the quartz block with
the required implementation, so it's easy to use
On Sat, 30 Oct 2004, Ralph Goers wrote:
Carsten Ziegeler wrote:
I think the key point is that we are using Quartz as the implementation,
but not as the interface. Now we already have the quartz block with
the required implementation, so it's easy to use that.
The first step is to do this move. If
On 30-okt-04, at 21:02, Giacomo Pati wrote:
On Sat, 30 Oct 2004, Unico Hommes wrote:
On 30-okt-04, at 18:46, Ralph Goers wrote:
Carsten Ziegeler wrote:
I think the key point is that we are using Quartz as the
implementation,
but not as the interface. Now we already have the quartz block with
the
The current implementation of our continuations manager uses
the excalibur event package for the background checker that
checks for expired continuations.
Now, this approach has the problem, that excalibur event is
deprecated. In addition we aren't using it somewhere else,
so it would be great if
Carsten Ziegeler wrote:
The current implementation of our continuations manager uses
the excalibur event package for the background checker that
checks for expired continuations.
Now, this approach has the problem, that excalibur event is
deprecated. In addition we aren't using it somewhere else,
On Fri, 29 Oct 2004, Carsten Ziegeler wrote:
The current implementation of our continuations manager uses
the excalibur event package for the background checker that
checks for expired continuations.
Now, this approach has the problem, that excalibur event is
deprecated. In addition we aren't
Carsten Ziegeler wrote:
The current implementation of our continuations manager uses
the excalibur event package for the background checker that
checks for expired continuations.
Now, this approach has the problem, that excalibur event is
deprecated. In addition we aren't using it somewhere else,
Giacomo Pati wrote:
On Fri, 29 Oct 2004, Carsten Ziegeler wrote:
The current implementation of our continuations manager uses the
excalibur event package for the background checker that checks for
expired continuations.
Now, this approach has the problem, that excalibur event is
On Fri, 29 Oct 2004, Carsten Ziegeler wrote:
Giacomo Pati wrote:
On Fri, 29 Oct 2004, Carsten Ziegeler wrote:
The current implementation of our continuations manager uses the
excalibur event package for the background checker that checks for
expired continuations.
Now, this approach has the
Giacomo Pati wrote:
Yes, we used the CommandManager in some projects. It is based
on the PooledExecutor from Doug Leas concurrent-utils
package. It comes in quite handy as you can put tasks there
you'd like to be done asynchroniously (ie. indexing a
uploaded document with lucene to
On Fri, 29 Oct 2004, Carsten Ziegeler wrote:
Giacomo Pati wrote:
Yes, we used the CommandManager in some projects. It is based
on the PooledExecutor from Doug Leas concurrent-utils
package. It comes in quite handy as you can put tasks there
you'd like to be done asynchroniously (ie. indexing a
Giacomo Pati wrote:
Sure, no problem. How should it be named?
What does it do? :)
Someone mentioned Crons JobScheduler as it has a fireJob()
method that could do it but would we want the cron block go
into the core?
Hmm, I think this depends on the effort it takes to create it.
If we
On Fri, 29 Oct 2004, Carsten Ziegeler wrote:
Giacomo Pati wrote:
Sure, no problem. How should it be named?
What does it do? :)
Someone mentioned Crons JobScheduler as it has a fireJob()
method that could do it but would we want the cron block go
into the core?
Hmm, I think this depends on the
Giacomo Pati wrote:
On Fri, 29 Oct 2004, Carsten Ziegeler wrote:
Giacomo Pati wrote:
On Fri, 29 Oct 2004, Carsten Ziegeler wrote:
The current implementation of our continuations manager uses the
excalibur event package for the background checker that checks for
expired continuations.
Now, this
Unico Hommes wrote:
...
I believe that the excalibur event package lives on at d-haven [1]. Why
not use that?
Oh oh. We did this discussion with the container, I hope we don't have
to go over this again for every Avalon dependency we have ;-P
1. http://api.d-haven.org/event/
--
Nicola Ken
Nicola Ken Barozzi wrote:
Unico Hommes wrote:
...
I believe that the excalibur event package lives on at d-haven [1].
Why not use that?
Oh oh. We did this discussion with the container, I hope we don't have
to go over this again for every Avalon dependency we have ;-P
Nope just with
On Oct 29, 2004, at 4:41 AM, Carsten Ziegeler wrote:
Yesterday, I wrote a simple replacement which I checked into 2.2:
a simple background thread is initialized that sleeps for a
configured period of time, checks the continuations, sleeps etc.
Now, this solution should work.
The question is now,
Il giorno 29/ott/04, alle 11:26, Sylvain Wallez ha scritto:
java.util.TimerTask?
+1. Do the simplest thing that might possibly work. KISS, YAGNI, etc.
etc. etc.
Ugo
--
Ugo Cei - http://beblogging.com/
smime.p7s
Description: S/MIME cryptographic signature
Nicola Ken Barozzi wrote:
Unico Hommes wrote:
...
I believe that the excalibur event package lives on at d-haven [1].
Why not use that?
Or we could stick with excalibur-event, if there is nothing wrong with it.
Oh oh. We did this discussion with the container, I hope we don't have
to go over
Vadim Gritsenko said:
Nicola Ken Barozzi wrote:
Unico Hommes wrote:
...
I believe that the excalibur event package lives on at d-haven [1].
Why not use that?
Or we could stick with excalibur-event, if there is nothing wrong with it.
I believe the major concern is making sure that the
Ralph Goers wrote:
I believe that the excalibur event package lives on at
d-haven [1].
Why not use that?
Or we could stick with excalibur-event, if there is nothing
wrong with it.
I believe the major concern is making sure that the Cocoon
core only relies on solid,
Bart Molenkamp wrote:
Maybe CRON can handle this job? Or isn't it a good idea to have the core
of Cocoon depent on CRON?
unfortunately, CRON is not a portable service across OS and we do
support silly microsoft OSs too.
--
Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
Stefano Mazzocchi wrote:
Bart Molenkamp wrote:
Maybe CRON can handle this job? Or isn't it a good idea to have the core
of Cocoon depent on CRON?
unfortunately, CRON is not a portable service across OS and we do
support silly microsoft OSs too.
We have a Cron block based on Quartz scheduler. I
Unico Hommes wrote:
Giacomo Pati wrote:
On Fri, 29 Oct 2004, Carsten Ziegeler wrote:
Giacomo Pati wrote:
On Fri, 29 Oct 2004, Carsten Ziegeler wrote:
The current implementation of our continuations manager uses the
excalibur event package for the background checker that checks for
expired
Vadim Gritsenko wrote:
Nicola Ken Barozzi wrote:
Unico Hommes wrote:
...
I believe that the excalibur event package lives on at d-haven [1].
Why not use that?
Or we could stick with excalibur-event, if there is nothing wrong with it.
Oh oh. We did this discussion with the container, I hope we
Carsten Ziegeler wrote:
Ok, let's see what we have: Cocoon is not using the Event package
at all, apart from the continuations checker which can be implemented
in just a few lines - I did this for 2.2 - apart from that Cocoon does
not need it.
There are people out there who might be using this
On Fri, 29 Oct 2004, Stefano Mazzocchi wrote:
Bart Molenkamp wrote:
Maybe CRON can handle this job? Or isn't it a good idea to have the core
of Cocoon depent on CRON?
unfortunately, CRON is not a portable service across OS and we do support
silly microsoft OSs too.
The Cron block was meant, not
On Fri, 29 Oct 2004, Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
Ok, let's see what we have: Cocoon is not using the Event package
at all, apart from the continuations checker which can be implemented
in just a few lines - I did this for 2.2 - apart from that Cocoon does
not need it.
There are
Giacomo Pati wrote:
So, the question remains. Either we
integrate refactor the excalibur event package
or
make the Quartz/Cron block core as it does all we need
Yepp, I think we should use a compromise here: let's take the
fastes road and add quartz to the core. The
On Fri, 29 Oct 2004, Carsten Ziegeler wrote:
Giacomo Pati wrote:
So, the question remains. Either we
integrate refactor the excalibur event package
or
make the Quartz/Cron block core as it does all we need
Yepp, I think we should use a compromise here: let's take the
fastes road and add
45 matches
Mail list logo
