> 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]>
