----- Original Message ----- From: "Noel J. Bergman" <[EMAIL PROTECTED]> Sent: Oct 15, 1:14 PM
> Harmeet, > > > I have tried to run it with 100,00 mail messages and 20 workers > > for a few hours. Before fix it crashed James in a few minutes. > > Look at the while condition in your run method. Yes will fix that. I had a correctness problem. Target would never be triggered. I'll fix that. It should not impact the stability of the impl. esp. with short message flood (postal or Danny's test). Unfortuatly that is what I was testing for. Should have tested for correctness more but just so many hours. :-( > > > If you want to change performance, look at james-config.xml.diff. > > In other words, you took my idea about spreading the load over multiple > shared workers. There are still some issues, such as: I did say the idea to not block 'all' threads was implicit in your mail. :-) By spreading load across workers and appropriate handler id, it is possible for scheduler to even have one to one association with handlers just as the one watchdog to one handler patch. > > (1) It doesn't work. You need to fix that. :-) Yes.... :-) <run> Should have been (!Thread.currentThread().isInterrupted()) Forgot '!' will test for correctness, stability again and resend. Thanks for finding this. > (2) It doesn't work as a scheduler. The problem with inserting an earlier > time. It is ment to be james specific not a general scheduler. In the javadocs I highlight this along with some comments on either generalization impl or narrowing the interface. > (3) Synchronization and data structure management are still heavyweight > items. Yes reset is heavier than I like but can be fixed too. There are probably other optimizations that can be done. Harmeet
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
