> a) We seem to be talking about exchanging scheduler implementation > with watchdog implementation. It is felt that scheduler is not very > performant. It would be good to collect some data on it. I think > scheduler does not perform well, but not because the scheduler is > broken but because James is not using it correctly. > b) Watchdog usage could be clearer in a complete protocal > implementation(1st general comment) but from what I can tell, there > will be one thread associated with per watchdog. > c) If (b) is true then the this will severly constrain James. Each > thread is heavy and we should attempt to limit the number of > threads. > d) I belive the right solution is to have a scheduler per server or > a single scheduler for James and have unique identifier per > handler. Currently there is one scheduler per handler and handlers > are transient objects. I don't think that is the right > usage. Avalon developers on this list or in Avalon list may be able > to confirm. If we have one scheduler for n handlers, James would > suddenly be a lot better.
Using 100 delivery threads, each delivering 100 1k mails to James with new connections every time Java bugs out at about mail 1200, out of memory, ps shows a gazillion James threads. Re-using a single connection for each thread lets 10,000 11k mails be delivered in 690 seconds on my hardware, however James does freak out at this too, it stops accepting connections and I don't yet know why. I can commit my tests, but they're very rough, I wanted to see the results, not build something nice. d. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
