Harmeet,
> this > > 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. > > I am planning to checkin Scheduler implementation in the next few hours, > but > keep it disabled. i.e I won't swap scheduler impl in assembly.xml yet. > Hopefully as others test and there is more validation/improvements in the > next couple of days this will be enabled. > > Noel's testing and my own testing indicates a significant improvement > before > and after fix and it fits easily with current structure. -1 Noel's test makes it clear that even with the change, your code crashes. Period. He has not reported a successful run through of your code. Your server crashes. Always. And there are obvious flaws (which Noel expanded on) in your posted code. > The beauty of using the same abstraction is that there is a simple backoff > or switch strategy available. > 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. > 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 literally dozens of pages on the web that discuss the problems with high contention in systems like the one you're proposing. For example, http://www-106.ibm.com/developerworks/java/library/j-threads2.html To quote: "Contended synchronization can have a serious impact on the scalability of your programs. Even worse, unless you perform realistic load testing, contention-related performance problems do not always present themselves during the development and testing process" The specific issue is that the scaling is non-linear. Contention causes scaling like k! when you have k contending threads. Since the code you've posted has a double lock acquisition, and does expensive operations inside the synchronized area, it can be expected to occupy uncontended at least 2-3% of the request time (that's an extremely conservative estimate). Do the math. For 20 connections, or potentially 80 shared over multiple servers, that's disastrous. The contention made that 2 threads per connection doesn't scale I can only attribute to ignorance of standard server architectures. Most of the standard web servers (IPlanet, Apache) allow or require the use of multiple threads per connection in different configurations. One of the somewhat dated but standard texts on Java server development (Server-based Java Programming by Ted Neward) discusses the use of futures and other techniques that involve multiple threads per connection. They all scale. This is how you write a server in Java. Aside from all of this, it still doesn't address the issues I brought up in my first email. That is, centralized logging and fail on start behavior in the servers. --Peter -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
