If any help required in these, please let me know. I am ready to contribute.
On 8/7/07, Santosh [ಸಂತೋಷ ] <[EMAIL PROTECTED]> wrote: > > 1. Few more properties in "logging.properties" to LogHandler other than > directory, prefix, suffix, level, filter, formatter. Like, > prefix for level, suffix for level, level display (For Ex : Instead > of INFO, it must be possible to display "I"), timestamp display format > > Example. > levelprefix = [ > levelsuffix = ] > leveldisplay = INFO:I, ERROR:E > timestamp = dd-mm-yyyy hh:mm:ss > > This will help to reduce the log file size. > > 2. Admin webapp since its not ported on tomcat 6. > > > On 8/7/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED] > wrote: > > > > 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. > > > > 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 > > > > 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. > > > > 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. > > > > 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 > > > > 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 > > > > 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 > > ) > > > > 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 > > > > 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 > > > > 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 > > > > 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 > > > > 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 > > > > 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] > > > > >
