tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <wbar...@wilshire.com>
Subject Re: 6.x feature wishlist
Date Wed, 08 Aug 2007 04:07:00 GMT

"Santosh [????? ]" <santoshbmath@gmail.com> wrote in message 
news:ab4963eb0708071102t51800a0xefd7839a2116ce43@mail.gmail.com...
> On 8/7/07, Filip Hanik - Dev Lists <devlists@hanik.com> wrote:
>>
>> Santosh [????? ] wrote:
>> > If any help required in these, please let me know. I am ready to
>> contribute.
>> >
>> > On 8/7/07, Santosh [????? ] <santoshbmath@gmail.com> wrote:
>> >
>> >> 1. Few more properties in "logging.properties" to LogHandler other 
>> >> than
>> >> directory, prefix, suffix, level, filter, formatter. Like,
>> >>       prefix for level, suffix for level, level display (For Ex :
>> Instead
>> >> of INFO, it must be possible to display "I"), timestamp display format
>> >>
>> >> Example.
>> >> levelprefix = [
>> >> levelsuffix = ]
>> >> leveldisplay = INFO:I, ERROR:E
>> >> timestamp = dd-mm-yyyy hh:mm:ss
>> >>
>> >> This will help to reduce the log file size.
>> >>
>> >> 2. Admin webapp since its not ported on tomcat 6.
>> >>
>> If you want to make this one work, I would start from scratch.
>> There is no reason why the admin tool, whose only goal is to modify
>> server.xml has to interact or introspect a running tomcat instance.
>> Instead, what would be nice, is if the configuration reference contained
>> enough information and in an appropriate format that the admin
>> tool would introspect that XML and use the info as a base for the admin
>> tool.
>> since the configuration reference documentation could contain data type,
>> valid values, name and description, it would be the ideal data source to
>> fetch info for.
>>
>> just a thought, however, the existing admin app, suffers from the
>> chicken or the egg problem, I need a running tomcat to configure a tomcat
>> :)
>
>
> One important feature of admin webapp is to modify the server.xml while
> running the server. I think we can port 5.5 admin on tomcat 6.0 with 
> little
> changes.  Already I am in middle of this process. As i already said, some
> features are working in admin some are not working like adding/updating
> environment values, users, data sources. Currently i am analysing the 
> adding
> new environment. There is no change in NamingResourceMBean or 
> NamingResource
> in 5.5 and 6.0 but still i am getting error "addEnvironment() with String,
> String, String" not found.
>

I agree with Filip here.  I'm hugely -1 to accepting a port-from-5.5 version 
of the /admin webapp.  To get a version of the /admin webapp accepted to TC 
6, it would require a re-write.  The current version is pretty much 
unchanged from TC 4.1, and so it way out of date.

> Filip
>> >>
>> >> On 8/7/07, Filip Hanik - Dev Lists <devlists@hanik.com > 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.
>> >>>
>> >>> 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
>> >>>
>> >>> 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.
>> >>>
>> >>> 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.
>> >>>
>> >>> 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
>> >>>
>> >>> 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
>> >>>
>> >>> 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
>> >>> )
>> >>>
>> >>> 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
>> >>>
>> >>> 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
>> >>>
>> >>> 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
>> >>>
>> >>> 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
>> >>>
>> >>> 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
>> >>>
>> >>> I was thinking we can keep this list on Wiki or in a text file in 
>> >>> SVN,
>> >>> http://wiki.apache.org/tomcat/6xFeatures
>> >>>
>> >>>
>> >>> thoughts
>> >>> Filip
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> >>> For additional commands, e-mail: dev-help@tomcat.apache.org
>> >>>
>> >>>
>> >>>
>> >>
>> ------------------------------------------------------------------------
>> >>
>> >> No virus found in this incoming message.
>> >> Checked by AVG Free Edition.
>> >> Version: 7.5.476 / Virus Database: 269.11.8/940 - Release Date:
>> 8/6/2007 4:53 PM
>> >>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
> 




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message