tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Proposal: afterRead hook, encoding/parsing modularization
Date Mon, 01 May 2000 20:51:40 GMT

This proposal tries to improve the speed and design of tomcat.
If you agree with this we'll be able to:

- make all decoding code modular.

- improve  the parsing  code, make it more modular, share more
code between protocol modules.

- reduce the GC

- have a clear/better flow for request processing

- enable  input filters ( encoding/decoding are just particular cases).

The interface change is minimal - we'll add a "afterRead()" hook in
the RequestInterceptor, similar with beforeCommit() which is called
before the output buffer is written to the output stream.

The goal is to allow modules ( interceptors ) to control the encoding
and input/output processing.

The implementation will have few steps, and involves a smooth evolution:

1. Add the afterRead() hook

2. Move the  current decoding functionality in afterRead() hooks.
Move the current encoding functionality in beforeCommit() hooks.

3. Move some of the parsing code in afterRead hook ( HttpAdapter,
AjpAdapter ). Everything that is related with parsing can be shared
and will use common code ( instead of creating Strings with the
default constructor all over adapters )

4. Keep the "original" modules as "stable version", start experimenting
with new code like the one proposed by Jun Inamori, maybe use
special optimized encoders/decoders, maybe use existing ones.
Try to avoid GC - since the "core" and "adapters" will not parse and
decode we'll be able to have more control.

Implementing this proposal may require exposing the input/output
byte[] buffer and char[] buffer.

I think adding the afterRead() hook is valuable ( given that
we already have sevaral output hooks). Other web servers provide
similar callbacks - ( like SF_NOTIFY_READ_RAW_DATA).

Short term this will have little effect on the existing code, but will
allow us to resolve charset problems. Long term we can optimize
many modules by working on the char[] instead of String. There
is not reason to use imutable Strings in parsing and mapping
( other than comodity ).

For "integrated" mode we'll be able to take advantage of native
code and existing solutions, and remove a lot of per/request

Please let me know what you think and your vote.


View raw message