Good point about scheduler interface ?
2 things to chat about:
1st thing
======
What would be an appropriate scheduler interface ?
public interface DelayedEventScheduler
{
/**
* Schedule an offset based trigger.
* Note that if a TimeTrigger already has same name then it is removed.
*
* @param id trigger identifier
* @param trigger the trigger
* @param target the target
*/
void addTrigger( Object id, long offset, Target target );
/**
* Remove a scheduled trigger by id.
*
* @param id trigger identifier.
* @exception NoSuchElementException if no trigger exists with that name
*/
void removeTrigger( Object id )
throws NoSuchElementException;
/**
* Force a trigger time to be recalculated.
*
* @param id trigger identifier
* @exception NoSuchElementException if no trigger exists with that name
*/
void resetTrigger( Object id )
throws NoSuchElementException;
}
/** calback interface when an event is triggered */
public interface Target
{
void targetTriggered();
}
2nd thing
======
There has been some degree to reluctance to change abstraction. Maybe this
is due to the late release stage. Can the handler keep the same abstraction
but implementation ignore the inappropriate part of the interface and map to
simpler interface. This provides a simple swapping strategy till there is
consensus on 1st point and something to look forward for the next release.
Regarding:
> When we examine the analogous interface and implementation from the Java
> libraries - the Timer - we see exactly the same result. Why is this?
Agreed JDK Timer implemenation had the same problems. It was an unpleasant
surprise to me. But there is a 3rd implementation that was posted that did
not exhibit the same bad behaviour. Try that one. My testing and Noel's
testing indicates significant improvement. There is now an improved version
that addresses issues that were posted in 3rd implementation.
Harmeet
----- Original Message -----
From: "Peter M. Goldstein" <[EMAIL PROTECTED]>
To: "'James Developers List'" <[EMAIL PROTECTED]>
Sent: Monday, October 14, 2002 7:10 PM
Subject: Scheduler Interface
>
> All,
>
> I guess I just don't get it. Someone please explain it to me.
>
> We have an interface, written and implemented in a variety of forms by
> Peter Donald. Peter D. is the primary author of Phoenix, one of the
> continuing primary motivators behind Avalon, and a pretty smart guy.
> When he is confronted with our use of the Scheduler he replied:
>
> SS: Here is why we raised this as an issue. The Apache James mail
> server
> SS: project is using this timer mechanism to implement a connection
> timeout on
> SS: the SMTP port. When it receives data on the the port, it calls
> SS: resetTrigger to resets the timer.
>
> PD: ouch it is not really designed for that!
>
> If the primary designer of the interface recognizes that the use to
> which we are putting the Scheduler is not within its original design
> parameters, why is there such unswerving loyalty to this interface?
>
> When we examine the analogous interface and implementation from the Java
> libraries - the Timer - we see exactly the same result. Why is this?
> It could, one supposes, be simple incompetence on the part of the Sun
> developers. I'm certainly not going to suggest that they don't make
> mistakes. But I think we can conclude, especially with the Avalon case
> to back us up, that the reason applying that class to this problem
> results in OutOfMemoryErrors is that the two models don't fit.
> Schedulers and Timers are fundamentally designed for situations where:
>
> i) In general, events will be triggered
> ii) Events are not continually added and removed extremely frequently
> iii) The event target and the reset condition are not tightly coupled -
> that is, we expect the time to trigger (and hence the time the
> monitoring thread sleeps) to be independent of changes to the target
> during the sleep time. That's simply not true in this case.
>
> Let me repeat. There are extremely good technical reasons why the
> Scheduler model is inappropriate. Those have been laid out in seemingly
> exhaustive detail. References have been cited. The designer of the
> interface thinks this is a bad idea.
>
> On the other hand we have a new, simple, easy to understand interface
> that would allow you to place a Scheduler behind it with no trouble
> whatsoever.
>
> I'm sorry. This is drop dead simple. I don't even see grounds for a
> disagreement.
>
> --Peter
>
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
