Return-Path: Delivered-To: apmail-hc-dev-archive@www.apache.org Received: (qmail 22903 invoked from network); 19 Jun 2009 03:18:22 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 19 Jun 2009 03:18:22 -0000 Received: (qmail 68911 invoked by uid 500); 19 Jun 2009 03:18:33 -0000 Delivered-To: apmail-hc-dev-archive@hc.apache.org Received: (qmail 68841 invoked by uid 500); 19 Jun 2009 03:18:32 -0000 Mailing-List: contact dev-help@hc.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "HttpComponents Project" Delivered-To: mailing list dev@hc.apache.org Received: (qmail 68831 invoked by uid 99); 19 Jun 2009 03:18:32 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Jun 2009 03:18:32 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Jun 2009 03:18:30 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 433D2234C044 for ; Thu, 18 Jun 2009 20:18:10 -0700 (PDT) Message-ID: <692702817.1245381490264.JavaMail.jira@brutus> Date: Thu, 18 Jun 2009 20:18:10 -0700 (PDT) From: "Sam Berlin (JIRA)" 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 X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/HTTPCLIENT-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12721634#action_12721634 ] Sam Berlin commented on HTTPCLIENT-854: --------------------------------------- That makes sense. What's the use-case for requiring that work be performed exactly after the request is sent & before the response is processed, as opposed to allowing request & response to happen in the background & react to the response when it arrives? Any links to learn more about BOSH and why it would require this? > 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-unsubscribe@hc.apache.org For additional commands, e-mail: dev-help@hc.apache.org