hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <http-as...@dubioso.net>
Subject Re: HttpAsync Design - please review
Date Thu, 15 Jun 2006 19:32:39 GMT
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.


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

View raw message