tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Santosh [ಸಂತೋಷ ]" <>
Subject Re: 6.x feature wishlist
Date Tue, 07 Aug 2007 09:45:08 GMT
1. Few more properties in "" 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

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 <> 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
>   Of course, you can turn on/off the auto context logger through
> 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.
> (
> )
> 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,
> thoughts
> Filip
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message