Hi Guys, I know I can't vote, but here is my +1 for making Peter's watchdog changes. How many more programmers is it going to take to explain what Peter, Noel et al have explained till everyone "gets it".
Why has this issue turned into a my code your code battle when clearly there is a CORRECT approach? Peter, Noel ... make those changes and lets get on with it. Why haven't the other committers voted? I am just venting frustration here, sorry guys. Thanks, Serge ----- Original Message ----- From: "Peter M. Goldstein" <[EMAIL PROTECTED]> To: "'James Developers List'" <[EMAIL PROTECTED]> Sent: Tuesday, October 15, 2002 4:10 AM 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]>
