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.
Since I loathe HttpSession - this means nothing to me.
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. This option should be a wait and see.
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.
It would be worth a try - but I'd expect too many special cases would
cause one large piece of convoluted code instead of 3+ copy/paste pieces
of 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.
Please! A warning would be ideal if the attribute in the XML is not
found as a bean in the target object. This would be nice as a backport too.
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
Scratch away ...
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 have enough pain points to have an opinion on this. But out of
the box - one log consolidated log file is better than one log file per
context. (YMMV)
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)
A good file system does all this for us. Doing this as a Valve/Filter
would be nice. As a Valve/Filter - once can also cache dynamic content too.
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
would this work? The same webapp can be loaded multiple times for
various virtual hosts. The name would be the same for them all.
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
That would be nice.
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
If it can be proven than its worth it. I am highly skeptical.
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
A sample webapp linked from the home page would be nice. (With the
appropriate Valves in place to help prevent some of the security reports
that typically get created from examples )
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
