> > These issues were, at least in part, due to problems with the
> > Cornerstone TimeScheduler. Dependence on the global
> > TimeScheduler, previously used to handle idle timeouts, has
> > been removed. Instead, James now uses the classes of the new
> > org.apache.james.util.Watchdog package to provide this functionality.
> I have been using a scheduler implementation for 1+ year without any
issues.
> If you don't trust a scheduler implementation why not replace that with
> another one?
> What are the advantages of picking another abstraction to solve the same
> problem ?
As I recall, this was discussed by a half dozen or more folks over several
discussion cycles since late Spring. The problem is that a Scheduler has a
lot more responsibility and overhead than a lightweight timeout watchdog. I
had looked at a lightweight Scheduler implementation a month or two ago, but
the interface doesn't lend itself to a truely lightweight implementation.
For example, if I recall correctly, the interface takes a String that
requires a lookup.
> In the past there has been conversation about removing derived Servers
> classes and making do with handlers.
I suppose that one of the problems is that without a good architecture
document, if developers have undocumented intents and they aren't around to
discuss them, things can shift. Even if there is an architecture document,
architectures can change (as I mentioned in an earlier message).
It might be elegant to have a single generic Server class that dispatches
incoming connections on a given port to handlers for that port. However, as
I see it, there is server behavior that is not part of the protocol handler,
e.g., server configuration, which I'm not convinced is entirely generic.
Therefore, although the subclassing may be minimal, there is a case for some
server related code that is not part of the handler code, which should be
related to implementing the protocol.
Regardless, handlers should be pooled so that performance is more optimal
than reconfiguring them for each connection. And I agree that configuration
is per server, not per connection. Mind you, I'd like to be able to setup
multiple instances of a single server type, but with different configured
properties, so long as they were listening different ports and/or addresses.
> I don't follow the need for a new scheduler abstraction or re design of
> server-handler interaction.
I don't think that the Scheduler interface is amenable to a truely
lightweight implementation, which is necessary for a watchdog that could be
invoked 1000s of times per second. I'm more than willing to bat around
ideas related to server-handler interaction, which I do think should be
documented as a clear, reusabe, scalable, architecture. What do you see as
the abstract behavior for a server? For a handler? As I said, I believe
that there are some server behaviors that don't share implementation, but
perhaps you have other ideas.
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
