----- Original Message ----- Peter, Here is a snippet from Noel's email
> > > latest change. It appeared to fix the known problem, right up until > the > > > point when his system died. Don't know what the cause was. IF this > > code > > is > > > OK, it improves upon the DefaultAvalonScheduler for James' needs. My machine crashed that is why system died. Not sure why but it does that once in while. Before and after test here was the change Danny test with 20 concurrent threads and no upper limit on the number of connections crashed james within a few mins. After the fix, it did not crash for several hours. Noel did note a significant improvement too in his mail. > > Harmeet, I'm not going to go over this again. There are fundamental > flaws with the scheduler idea. We've gone over this. There are > They all scale. This is how you write a server in Java. Test for scale and performance with your fix and with mine and see the difference. As far as I can tell from mails there is a independent system improvement verification with my fix and a negetive improvement verification with your fix. Maybe you should do a test run or two. Regarding changing and your patch, For now -1 Reasons. > Once we are over this release let us talk about switching abstractions. I > have nothing against changing to WatchDog or another scheduler abstraction, > but I would like to see a demonstrable benefit. i.e performance, > scalability. I think sharing code with commons is good esp. if there is also > yields a system wide benefit. Regarding contention and exepensive synchronized methods. (a) I am improving those to some extent. (b) There are ways of improving it more. Doug Lea has documented a few ways and has a library to help eleviate problems you are mentioning. regarding > And there are obvious flaws (which Noel > expanded on) in your posted code. In my last email I have said that I am fixing flaws Noel has found and would appreciate more feedback. Please note Noel said 'IF this code is OK, it improves upon the DefaultAvalonScheduler for James' needs.' So far no one has mentioned correctness problems. His suggestions are performance improvements on a fix that improves James. BTW. I am not planning on fixing James handlers till there is more independent verification. This is again from my last email. What is your -1 is for ? Harmeet -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
