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