The problem seems to be this - You believe scheduler code cannot be used with handlers. - I think scheduler is designed with handlers in mind. I'll post the fixed code for pop3.
I'll buy you beer if I get it wrong. :-) ok ? Harmeet ----- Original Message ----- From: "Noel J. Bergman" <[EMAIL PROTECTED]> To: "James Developers List" <[EMAIL PROTECTED]> Sent: Saturday, October 12, 2002 1:59 PM Subject: RE: [PATCH] Removing Scheduler dependency, refactoring service code > > Peter, would you be able to put your proposals up for voting. I think > > such a major change requires proposal and voting. > > I believe that he did. And I don't think that this represents that major a > change. > > > The patch sent did not have any working protocol. > > The entire patch set would have to be integrated. I suppose that Peter > could post the files and everyone would have to manually integrate them into > the source tree. Or they could be committed, people could check them out as > normal, and tested. > > Or do you just want to see it visually, and couldn't run patch against his > diffs? > > > We seem to be talking about exchanging scheduler implementation > > with watchdog implementation. > > Yes. > > > It is felt that scheduler is not very performant. > > It is demonstrable, and was discussed extensively both on this mailing list > and on the Avalon mailing list. The point is that James is using the > Scheduler in a way contrary to the design point (purpose) for the scheduler. > In contrast, FetchPOP uses the Scheduler for precisely the designed purpose. > It isn't a matter of "James" using it correctly. The problem is that it is > not designed to serve the purpose that James needs. > > > Watchdog usage could be clearer in a complete protocal > > Looks to be there from what I can see. Please re-read the code. And there > is a thread pool associated with the watchdogs. > > > 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. > > Try performance testing James and seeing how many minutes it takes to crash > it (< 4). The changes made by Peter and Andrei directly relate to these > problems. > > > I belive the right solution is to have a scheduler per server or > > a single scheduler for James and have unique identifier per > > handler. > > Please indicate how you write a single watchdog that handles timeouts of > arbitrary granularity for arbitrary threads. I don't think that you've > thought this out carefully. One problem is that the watchdog has to wakeup > periodically to basically poll a list of entries, and can't do better than > the granularity of its sleep cycle. > > > [Currently] 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. > > As far as I can see from Avalon's documentation, that is exactly how > handlers are used. There could be an object pool for handlers, but that is > all you'd save. There is already a thread pool, and the new code provides > for one per service. > > > Would prefer a proposal, some performance figures and resolution based on > that. > > Please go back a few months in the archives and find Andrei's measurements > showing how James will fail in MINUTES at load, and how the changes proposed > corrected that problem. And I don't believe that justification for > architectural improvement is predicated solely upon performance > improvements. > > > server object(s) read handler configuration and pass a > > handler specific and strongly typed datastructure to > > each handler ? > > That is precisely what the new code does, EXCEPT that it sets each property > separately as a bean property, which is more in accord with Java programming > style. > > --- Noel > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
