Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Message-ID: <719831904.1245702187644.JavaMail.jira@brutus>
Date: Mon, 22 Jun 2009 13:23:07 -0700 (PDT)
From: "Mike Cumings (JIRA)" <jira@apache.org>
To: dev@hc.apache.org
Subject: [jira] Commented: (HTTPCLIENT-854) RFE: Provide mechanism to allow
 request transmission and response reception to be performed independently
In-Reply-To: <305883024.1245273967342.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HTTPCLIENT-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12722800#action_12722800 ] 

Mike Cumings commented on HTTPCLIENT-854:
-----------------------------------------

If this is the final position, I'm disappointed.  It appears as if this use case was known prior to 4.x development (http://wiki.apache.org/jakarta-httpclient/UseCases/SingleAsyncRequest) yet was not implemented.  Meanwhile, the 4.x API was implemented such that modifications to the API are not possible without breaking source and binary compatibility.  Additions to the API to work around this limitation are not being accepted, leaving options of waiting for long periods of time (e.g., for 5.x) or implementing an entirely separate API built upon the NIO core (again requiring long periods of time as well as the application of significant engineering resource).  Is this a fair characterization?

httpclient is a very useful API and I thank the core team members for your contribution.  Hopefully this will get resolved in the future, sometime.  For now, I suppose I'll just have to code around this and hope that I can revisit the issue to remove the inefficiency, later.

> 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_httpclient_2009-06-19_1.patch, HTTPCLIENT-854_httpcore_2009-06-18_1.patch, HTTPCLIENT-854_httpcore_2009-06-19_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-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org