From: "Noel J. Bergman" <[EMAIL PROTECTED]> > I believe that there are two separate issues. One issue relates to the > watchdog, the other to the service refactoring.
I agree, these seem to be the 2 main issues. Peter, would you be able to put your proposals up for voting. I think such a major change requires proposal and voting. I am hoping a proposal can be done, but there has been some discussion/work on this already. I will attempt to briefly put in my main concerns without waiting for a proposal. General Comments: ----------------- a) The patch sent did not have any working protocol. Peter, can you post a complete working protocol, for example POP3. This would help see the complete working proposal. b) can you post before and after performance statistics. I have added pop3 protocol test suite. In testing package, runtest.[sh|bat] reads testconf.xml, exercises protocol and generates performance stats in CSV format. If you need any help, let me know. Watchdog Comments ----------------- 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. Service vs. handler ------------------- a) I really don't like the high coupling this may involve and don't see the advantage in this. b) Would prefer if this is resolved based on real gain(vs. I know better) i.e. performance gain and if current architecture can address a problem that may show up. Would prefer a proposal, some performance figures and resolution based on that. c) The main gain seems to that configuration is read a number of times in the current code. Handler is a transient object and it is configured each time before use. This seems to be a precalculation/caching gain related to configuration. If configuration object is slow, is there a way to make it faster ? If not, can server object(s) read handler configuration and pass a handler specific and strongly typed datastructure to each handler ? comments... Harmeet -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
