----- Original Message ----- From: "Peter M. Goldstein" <[EMAIL PROTECTED]> > > 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.
All right here is a more precise question. What would be an appropriate scheduler interface for James timeout monitoring ? Please put forward a proposal as set of interfaces. > 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. Here are some questions to consider. - Have you bothered to measure performace and scalability of alternate approaches ? - For actual mail messages how much does it slow ? - Can that be addressed by using concurrent maps from doug lea's concurrent library ? - Is there a alternative that has measurable better performance and scalability characteristics ? The last email from Danny indicated a -ive. Has something changed since. If it has why don't you post rather than pose. Let us talk code and results rather than take up mutually exclusive positions. There is a way to resolve conflict - measurable results. Suggest we measure: - Scalability - Performance - Impact on the rest of system > > 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. Good thinking Peter. > > 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. I did think JDK folks would have a better implementation then they had, but you may also note that after that I came up with something better, tested it and it did improve on uptime significantly. Do you have something that improves the system measurable ? If you do, once more post it. > The swapping strategy is not simple. It is simply wrong. Peter, I have never said that we cannot change the interface, however I want a) Measurable system gain b) Not swap strategies in this release esp. if there is a improved Scheduler implementation. We can take this up in next release. Said this earlier too. c) I want a backoff strategy if there are issues. If we had release with your patch and Danny had not tested, there would have been a significant regression and no easy implementation swap. Harmeet -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
