"Filip Hanik - Dev Lists" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >I wanted to start a wish list of what we can move forward with, here is a >short list of items that I had in mind as a starter > > 1. Session replication - stateless backup location > Store the backup location of a session as part of the sessionId, similar > to the jvmRoute but opposite. > This way, you can scale a cluster horizontally, since the location of > the backup node doesn't have to be known until you fail over. >
No real comment, but scratch away. > 2. Add a block/no-block parameter to InputFilter.doRead and > OutputFilter.doWrite > InputFilter -> public int doRead(ByteChunk chunk, Request unused, > boolean block) throws IOException; > OutputFilter -> public int doWrite(ByteChunk chunk, Response unused, > boolean block) throws IOException; > Servlet 3.0 will most likely expose non blocking read/write through the > servlet API, this will get us there ahead of time > Haven't thought of how we expose this API yet though, but more will > follow > I agree with Remy here. We should do it when we know that Servlet 3.0 requires it. Until then, the transport layer should be opaque to the Servlet container. That is how Coyote is currently designed (i.e. if somebody had an itch to resurect the JNI Channel for Windows (IIS/Httpd) for AJP/1.3, would this even be meaningful?). > 3. Consolidate connector code > Currently we have Http11Processor/Http11NioProcessor/Http11AprProcessor > doing almost the same thing, there is much that > can be consolidated to make the code more maintainable > Essentially, you create a Endpoint base line interface. > At the same time we could consolidate the Internal(In/Out)put buffers as > they are copies too. > We have some fairly tuned endpoints now, it would also be nice to make > these protocol agnostic. > Again, I agree with Remy that the current implementations are too different to consolidate. However, if you care enough to draft up a concrete [PROPOSAL], then I'd be happy to comment on it. > 4. Startup -> server.xml warnings > If one enters an invalid element or attribute that is simply ignored > today, at least output an info or warn message letting the > admin know if its misconfiguration. > You can get the attributes now by setting debug logging on o.a.t.u.IntrospectionUtils. It wouldn't be hard to do in general (e.g. make IntrospectionUtils.setAttribute return boolean instead of void, and warn in Digester.startElement if no rules are configured, but make the later configurable so that the TC shutdown digester doesn't produce a ton of warnings). However, it means that our fork of Digester increasingly moves away from c-d. > 5. Finish bayeux -> I started this in sandbox, took me a while to > understand the protocol, and its not as cool as I thought it would be > but I still feel its important for it to be part of Tomcat > Prefer that it is an optional component, but no strong opinions. > 6. Auto context logging > Automatically create loggers for each context, so that one doesn't have > to specify one per context in logging.properties > Of course, you can turn on/off the auto context logger through > logging.properties > Agree with Remy: it should be opt-in rather than opt-out, if we do it at all. Most admins I know prefer to look in one place for problems, rather than 1000. > 7. File cache - use MappedByteBuffers for the file cache, that way the > send file operation can benefit even more > when you have two direct buffers, and you also avoid reading the disk > each time for a file > ideas on this came from Jeanfrancois Arcand. > > (http://fisheye5.cenqua.com/browse/glassfish/appserv-http-engine/src/java/com/sun/enterprise/web/connector/grizzly/FileCache.java?r=1.21) > +1000 to Remy's comment. This doesn't belong in the connector layer. If implemented at all, it should be done in the naming caching code. > 8. Add getName()/setName() to the WebappClassLoader, name of the web app > classloader will correspond to the one of the Context container > Applications like Terracotta or AOP apps can much easier plug in and be > able to share data when they know what loader the class came from > Like Remy said, basically harmless and useless. > 9. Add the configuration option to start the connectors after all apps are > deployed > If some applications are taking long to startup, load balancers are > already trying to send requests to the Tomcat instance, which is just > bound to a port, but not yet taking requests > Since this effects sites running under jsvc, I don't think it will be too popular, but scratch away. > 10.Turn our embedded thread pools into Tomcat Executor thread pools, same > performance but pluggable. Instead of having them hidden in the end point > code > Any useful way to do this would be cosmetic only (e.g. 'public class ThreadPool implements Executor'), I can't give more than a +0.25 on this. > 11.Timestamps & System.currentTimeMillis > System.currentTimeMillis is invoked everywhere during the chain of > events for a HTTP requests, even though most dates only need precision > down to the second. > I've received feedback that this could be improved by keeping a time > service, that updates a timestamp every second, and therefor reduces the > number of system calls > I think we would need to prove the theory before committing to the > implementation, but that should be pretty easy > We already use a formatter for response.setDateHeader that reuses the value to the second, and otherwise I think that the other comments have shown this to be a non-issue. > 12.Comet sample webapp > While most folks want to start with Comet, it is a strange question, > tons of users on the user list just are having a hard time getting kick > started > again, scratch away. > I was thinking we can keep this list on Wiki or in a text file in SVN, > http://wiki.apache.org/tomcat/6xFeatures > > > thoughts > Filip --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
