Harmeet,
Do you actually read my emails? Because it sure doesn't sound like it. > 1st thing > ====== > > What would be an appropriate scheduler interface ? The Scheduler interface is an appropriate interface. For a scheduler. This is not a scheduler. This is a timeout. Pick one of my previous emails and read it. > 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. Your implementation almost certainly has the exact same problems, for the exact same reasons. The fault lies in the thread contention on the lookup. Are we clear? You can't avoid that without violating thread safety. Period. It doesn't matter what you do in your implementation - it will either: i) Violate thread safety ii) Slow down asymptotically as the number of contending threads increases. For reset times that are a few percent of the thread execution time, this is disastrous. The reason the Timer was a surprise to you was precisely because you fail to appreciate this point. I didn't bother replying to your Timer implementation because I knew it would crash. I let Noel test it, and it crashed. Surprise. I'll also note that you claimed it wouldn't crash before he ran his test (having run tests of your own) and he managed to bring it down in a minute or two each time. With 5 active connections (as you're on a Win2k box). Try ramping that up to 20. Or 80, when you load all four services. Crash. Thread contention scales non-linearly. I'll also point out that you failed to address any of the comments about the interface designer's comments and why the Java Timer manifests the behavior it does. Again, that's because you don't understand this point. The swapping strategy is not simple. It is simply wrong. --Peter -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
