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 logging.properties
Of course, you can turn on/off the auto context logger through
logging.properties
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
logging.properties ?)
- 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 logging.properties
- 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.
(http://fisheye5.cenqua.com/browse/glassfish/appserv-http-engine/src/java/com/sun/enterprise/web/connector/grizzly/FileCache.java?r=1.21)
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
Engine.name+Host.name+Context.name
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,
http://wiki.apache.org/tomcat/6xFeatures
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.
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
