[
https://issues.apache.org/jira/browse/HTTPCLIENT-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12721631#action_12721631
]
Sam Berlin commented on HTTPCLIENT-854:
---------------------------------------
I'm not sure I fully understand the difference between the patch you provided
and the usage by submitting the request to an ExecutorService.
When you submit a Callable (or Runnable) to an ExecutorService, the call() or
run() methods happen asynchronously. If the callable returns a value, that
value is stored until it's retrieved via the Future.get() method. So, in this
case of submitting HttpClient.execute in a callable to an ExecutorService, the
request is indeed sent independently of waiting for the response.
What is *not* happening asynchronously in the ExecutorService (and by the looks
of it, also not in your patch) is parsing the body of the response (in
HttpClient terms, the HttpResponse.getEntity). If you want to do that you have
a few avenues:
Future<byte[]> future = executeService.submit(new Callable() {
public HttpResponse call() throws IOException {
HttpResponse response = httpClient.execute();
if(response.getEntity() != null) {
return EntityUtils.toByteArray(response.getEntity());
} else {
return null;
}
}
});
// ... do other work while the request happens asynchronously
// and then..
byte[] responseData = future.get();
Or, you can make use of the ResponseHandler interface which transforms an
HttpResponse into an arbitrary object
Future<SomeType> future = executorService.submit(new Callable() {
public SomeType call() throws IOException {
return httpClient.execute(request, responseHandlerForSomeType);
}
});
// ... do other work asyncrhonously...
// and then,
SomeType result = future.get();
> RFE: Provide mechanism to allow request transmission and response reception
> to be performed independently
> ---------------------------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-854
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-854
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient
> Affects Versions: 4.0 Final
> Environment: All
> Reporter: Mike Cumings
> Priority: Minor
> Fix For: Future
>
> Attachments: HTTPCLIENT-854_httpclient_2009-06-18_1.patch,
> HTTPCLIENT-854_httpcore_2009-06-18_1.patch
>
>
> The HttpClient API currently provides for the execution of a request via the
> HttpClient.execute(...) methods. These methods all send the request and then
> block until the response has been received. This precludes the user of the
> API from being able to send the request, perform some additional work, then
> come back and block on the request. This style of processing is very
> desirable for implementation of HTTP-based protocols such as
> Bidirectional-streams Over Synchronous HTTP (BOSH). This capability is also
> closely related to HTTPCLIENT-258, support for HTTP 1.1 pipelining.
> The current code base (4.0) currently utilizes
> org.apache.http.impl.client.DefaultRequestDirector.execute(...) to transmit
> requests. This method contains a retry loop which blocks on and then
> examines the response from the remote server. When success is detected, it
> cleans up and returns the response instance. Requests are sent using an
> HttpResponseExecutor instance. These classes support the ability to
> separately doSendRequest() and doReceiveResponse().
> Please expose the ability to leverage this functionality outwith the retry
> loop but including the existing routing and authorization capabilities, where
> possible.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
