Hi all, since there doesn't seem to be any more feedback coming, here are my thoughts.
- consuming (the remainder of) the response body I agree that this should be done by the background threads. When I started the implementation, I followed the generic idea of having these threads available to do other things. But with blocking IO, there is no way around having at least one thread per connection, and that thread can't do anything but wait for the connection to become available. It makes perfect sense to offload the consuming from the application and have it done by the background thread. - pre- and postprocessing I like Mike's suggestion to have this configurable. I admit that I never even thought about making that configurable. It's no big deal at all for preprocessing. Postprocessing by an application thread requires some thread synchronization to pick the one that's going to do the postprocessing. But that code is already implemented, and adding the alternative to postprocess in the background thread is no big deal. My main concern about pre-/postprocessing in the background thread is that unsuitable application code might be executed. In that case, we can simply tell people to reconfigure and have their code executed by an application thread where it will cause less harm. The default for postprocessing should be the background thread. That provides a more consistent behavior of the dispatcher: problems with postprocessing will lead to a problem notification, instead of having a success notification, followed by exceptions when application threads are trying to pick up the response. For preprocessing, I still prefer to have it in the application thread by default. Unlike postprocessing, it is clear which application thread will do the work, and errors will be detected immediately, before the request passes through queues into background threads. The resulting stack trace should also be more helpful for developers. What do you think? It will still be a few weeks until I start coding again, so there is time to integrate new ideas into the design yet. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
