[Paperclips-discuss] Filters and mapping implementation

[Nic Ferrier]

Paperclips tries to be fast at servicing requests.

There are 3 factors in being a fast servlet engine:

- how quickly you accept and begin to service the initial connection
Paperclips uses a thread pool for this, as the recent discussion on
advanced-servlets shows, nbio is unlikely to bring much benefit to
servlet servicing so the thread pool will stay (but maybe we need some
kind of system to plug in a fast webserver)

- how fast your HTTP implementation is
Some servers do some crazy things like doing reverse lookups for UA
addresses at initialization. Paperclips tries to keep the number of
things it does to a minimum and do those really fast, eg: we avoid
using StringTokenizers and use for loop/indexes into strings instead.
And note that it's not just HTTP init that's got to be quick, things
like chunked encoding must be fast too.,

- how quickly you work out what servlet you're targetting
This is something that is often ignored. The API look up rules are
really complicated. Paperclips does a pretty fast lookup for directory
mapped servlets by using a Trie based system. Tries provide fail fast
searches via indexes.


Unfortunately the new filter system means we have to change the
servlet lookup rules. Servlets are no longer the only thing that can
be looked up and the rule of "only one target is possible" has now
been broken by the API.

Briefly the Trie system used to find the single best matching servlet
based on the request uri. It did that by pulling out the list of
mappings for an index and comparing them.

With url-pattern filters we now need a system where we find ALL the
filters that match a particular URI but still find only the best
matching servlet.

I've been wracking my brains about this but can't think of a good way
to do it.

Anyone have any ideas?


Nic