tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: 6.x feature wishlist
Date Tue, 07 Aug 2007 06:18:50 GMT
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

Here's my opinion on these. I think most of them are not a good idea, 

> 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 idea about that.

> 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 think it's too early to speculate on what the Servlet API may add, and 
I don't see any benefit this would bring at this point. I am managing to 
implement non blocking functionality without major problems without 
these additional calls. I also think your API proposal for Comet in 
trunk is inappropriate, and I will come back with my original proposal, 
which I like more and more. So -1 for this one.

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

This has been tried before (I was supporting it), but the endpoints (and 
connectors) have a fairly different processing logic. The result was 
actually more complex than the original version, so I removed it. -1 too.

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

That's going to be hard to do in a consistent way.

> 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

Ok. You could try to come up with something better if you think it's not 
good enough.

> 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 

I don't like that:
- very little logging occurs through the context logger (or maybe it's a 
default for the whole webapp like if you added a file handler in ?)
- JULI already provides a separate logging environment for the webapp 
(because it uses a separate classloader), and webapps interested in that 
can easily configure it using a
- JULI specific (if this is actually done, I would like to remove log4j 
- and most importantly, would automagically be creating zillions of 
small logfiles, so I like the idea of people configuring it in better 
than configuring it out

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

I dislike gimmick cache functionality inside the connector (worst 
Grizzly idea ever ...), where actually the overhead of the default 
servlet is very slim. In the real world people could instead:
- write a caching valve using sendfile which would fit their needs 
better and which will have a couple more % of overhead
- use a separate webserver for static resources if they have so many of them
- would have a lodbalancer/proxy nullifying the benefit

> 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

Really ? How would they know that this corresponds to something 
meaningful ? It's possible to determine the webapp name in a similar 
proprietary way without this, but making the change seems harmless.

> 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

Very easy to do (I added a system property). This has some drawbacks 
though, and I considered it JBoss specific.

> 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

The executor based pools have really bad performance, so I don't see any 
reason to stop using the simpler pools. This does not remove any 
pluggability (a configured executor will be used). I added executors as 
an experiment, and was really let down by the performance. Knowing the 
results, I would not have bothered adding the feature ...

> 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

I don't see that many calls being made, and many need the millisecond 
precision (= not a HTTP date). I would like evidence that 
System.currentTimeMillis is some sort of performance bottleneck before 
supporting these changes.

> 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

This isn't really something which should be proposed, it's part of the docs.

> I was thinking we can keep this list on Wiki or in a text file in SVN,

My own view is to do a number of changes, but keep the 6.0.x branch as 
most changes I support could fit in there (for example, my own Comet API 
changes - arguably the most significant change - are pretty much 
backwards compatible, and as a result could occur there).


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

View raw message