(Regarding the auto formatter) There is a mailing list thread discussing coding standards (http://groups.google.com/group/deft-web-server/browse_thread/thread/10d2096f13c0b745). Until things have converged and settled I think we should leave the current formatting as is. (Feel free to raise your voice in that thread btw )
The "cancelled key processing" exception sounds interesting and could very well be bug in the current code base. Do you mind showing me an example when this occurs?
(Regarding CharsetDecoder) Nicholas Whitehead improved the http request parsing by ~8% with his patch for #104: https://github.com/rschildmeijer/deft/commit/c4bf2e0451dbfdcc87cf81022ba100bcfe3661c0
Maybe we could improve this even further using the CharsetDecoder class. Feel free do experiment on your own, benchmark, and create an issue with patch supplied if you notice any performance increase.
You said you are calling response.finish() from another thread. That is dangerous and not deterministic. (The only thread that is allowed to call the methods on a org.deftserver.web.http.HttpResponse is the io loop thread).
Before we have #103 (https://github.com/rschildmeijer/deft/issues#issue/103) (or a mongodb client lib that is compatible with deft == runs in defts ioloop) in place, its not possible to use third party asynchronous libraries.
My best tips is to use a blocking mongodb client api and block the ioloop (good reading: https://github.com/facebook/tornado/wiki/Threading-and-concurrency) (Thanks once again Ben for this excellent article).
Using Apache HttpCore for request parsing is interesting. I guess that Deft's current request parsing is much more simple than the one done in HttpCore. If you don't want to do this benchmarking by yourself, feel free to create an issue and hopefully someone else will find it interesting and spend some time on it (For me its mostly a matter of time and priorities. Time that I don't have right now ).