----- Original Message ----- From: "Peter M. Goldstein" <[EMAIL PROTECTED]> > > All, > > This code is being posted almost a week after I'd originally intended to > post it. For that I can only apologize - I got held up by a bunch of > things. > > Basically this code is designed to address a bunch of > memory/robustness/scalability issues. 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 ? At least one has already been posted. One of the advantages of Avalon is that you can replace an impl. I thought the scheduler is a good abstration and widely used. What are the advantages of picking another abstraction to solve the same problem ? > > In addition, there was substantial rearchitecting of the service > structure. James services are now subclasses of the new > AbstractJamesService class. This class serves to unify the common > functionality of the services. BaseConnectionHandler is removed, > because the functionality once provided by that class has been moved > into AbstractJamesService. The Configurable interface (and the Earlier the intent was to have thin server and move towards a base handler class. I don't see the benefit in rearchitecture. Did the current system not meet a requirement ? In the past there has been conversation about removing derived Servers classes and making do with handlers. > corresponding behavior) has been removed from all the ConnectionHandler > children, in recognition that configuration is really on a per-server, > not per-handler, basis. A far simpler solution would have been to have a single params object per handler or optimize configuration code. This would have delivered the speed gain without a new architecture. Each philosophy would have holes and I don't see big enough of a hole in the hander mechanism to require a redo. > This leads to tighter coupling between the > Handlers and the corresponding server classes, but that's simply > recognition of a pre-existing reality. These classes are extremely > tightly coupled. Server is a listener. Handler contains protocol specific stuff. Why would there be a (tight) coupling ? It is a listen-dispatch mechanism. Shouldn't it be as loosely coupled as possible ? > > The config.xml entries were not modified to remove the > <handler></handler> tags, to maximize backwards compatibility. These > tags don't really make sense, even before this set of changes, and > should be removed in a future version. > > Some enhancements, including the ability to specify a thread group for > use by a particular service and the ability to do more fine-grained > connection management (i.e. to have more than one set of SSL > connections, each for use by different services) have been added. These > will be further documented, but are basically encapsulated in the > AbstractJamesService class. I thought the capability to create n listeners for each service already existed. > > There was some change to the behavior of the SMTP server - specifically, > the number of bytes required to reset the idle timer is now measured > against the total number of bytes read off the socket, not simply those > read in the DATA command. This substantially neatens the code and in > real life scenarios doesn't make a whole lot of difference. > > There is also a partial redress of bug #13316 in the NNTP code, which > will reset the watchdog every 100 headers it transmits. observer-observable model would be a good fix. > > I've done basic testing on this code, and I am now doing further load > testing. I will continue to do testing before submission. > > The code is attached as a set of diffs, and a collection of newly added > files. > > As always, comments, critiques, and questions are welcome. I don't follow the need for a new scheduler abstraction or re design of server-handler interaction. Maybe a bit of pro-con or a discussion on different options and what makes one better than other would help. thanks, Harmeet -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
