tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: 6.x feature wishlist
Date Wed, 08 Aug 2007 21:11:24 GMT
Remy Maucherat wrote:
> 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, 
> actually.
>> 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.
bummer, this community has always been against any kind of non blocking 
stuff. well, it will bite us later :)
>> 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.
APR and NIO are almost identical, in other words, when I wrote the NIO 
crap, I copied the APR code, and then replaced any native with java.nio
but I can see how this is a pain, but at some point, it would be nice to 
have a more modular system and reuse more of the code
>> 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.
apparently not :), you're already experimenting with it
>> 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.
yes, the downside is the client support, that's where the sticky issue. 
I could do something better for the server, but who would use it if 
there is no client.
so I'll continue with this, however, we need to resolve the CometEvent 
interface issue first
>> 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 support)
> - 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
it would be configurable of course, its an added option, and I've seen 
the usage requested. Since its configurable and you can decide to use it 
or not, I don't see why we wouldn't offer it
>> 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
I'm not talking about a cache in the connector like glassfish, simply 
use MappedByteBuffer's in our ResourceCache, currently, SEND_FILE 
operations are not taking advantage of any cache as they open a file 
channel for each file, even if it is the same file, completely bypassing 
the cache.
>> 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.
The name would have to be a concatenation of
>> 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 ...
I don't see that much of a difference, and most importantly, the request 
"fairness" improves greatly using the executor.
I'm not saying get rid of the old thread pool, I'm saying pull it out of 
the endpoints.

>> 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.
except no one can get the example from the docs working :)
>> 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).
see my email about trunk status.


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

View raw message