tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <>
Subject Re: 6.x feature wishlist
Date Wed, 08 Aug 2007 03:51:14 GMT

"Filip Hanik - Dev Lists" <> wrote in message
>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
>   Of course, you can turn on/off the auto context logger through 

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.
> (

+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,
> thoughts
> Filip 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message