[
https://issues.apache.org/jira/browse/HTTPCLIENT-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12721633#action_12721633
]
Mike Cumings edited comment on HTTPCLIENT-854 at 6/18/09 8:29 PM:
------------------------------------------------------------------
The difference is that the request is not flushed to the server before the
arbitrary work is performed. The execute() method performs *both* the request
transmission and the response processing. Thus, there is no way to flush the
request without blocking to wait for the response.
I should elaborate a bit more, perhaps. It is technically possible to do what
you suggest. However, doing so would mean that I would employ N (dynamically
allocated) threads for N requests (plus the originalting thread), whereas the
asynchronous code I've added allows for efficient processing using just 1
thread (plus the originating thread). In my use case, the requests for all
outstanding connections must be flushed immediately. The responses must be
processed in the order in which the connections are made. This is important
for my application.
was (Author: mcumings):
The difference is that the request is not flushed to the server before the
arbitrary work is performed. The execute() methos performs *both* the request
transmission and the response processing. Thus, there is no way to flush the
request without blocking to wait for the response.
> 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
