[jira] Created: (HTTPCLIENT-854) RFE: Provide mechanism to allow request transmission and response reception to be performed independently

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


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@...
For additional commands, e-mail: dev-help@...

     [ https://issues.apache.org/jira/browse/HTTPCLIENT-854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Oleg Kalnichevski updated HTTPCLIENT-854:
-----------------------------------------

    Fix Version/s: Future

Mike,

It is _very_ unlikely someone will contribute such an extension unless you do it yourself. All requisite low level components already exist either in core or client. You would just need to provide a different client facing API.

Oleg  

> 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
>
>
> 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@...
For additional commands, e-mail: dev-help@...

     [ https://issues.apache.org/jira/browse/HTTPCLIENT-854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Cumings updated HTTPCLIENT-854:
------------------------------------

    Attachment: HTTPCLIENT-854_httpclient_2009-06-18_1.patch
                HTTPCLIENT-854_httpcore_2009-06-18_1.patch

The story of my life...  I'm already 5 stack frames deep in various library creation/updates.  What's one more?

How about something like what the attached provide?  Note:  I broke DefaultRequestDirector.execute(...) up into a bunch of private methods to A) get the cyclomatic complexity to a sane level, and B) to allow for the same code/logic to be used for both sync and async requests.

Mike

> 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@...
For additional commands, e-mail: dev-help@...

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

Sam Berlin commented on HTTPCLIENT-854:
---------------------------------------

Would something as simple as:

--
Future<HttpResponse> futureResponse = executeService.submit(new Callable() {
   public HttpResponse call() throws IOException {
          return httpClient.execute(...);
   }
};
// do other work
HttpResponse response = future.get(...);
--

That plays nicely with the built-in JDK concurrency controls & the existing HttpClient API.

> 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@...
For additional commands, e-mail: dev-help@...

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

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

Unfortunately, no.  I looked at doing something like that early on.  The problem is that the request needs to be sent independently of waiting for the response.  Deferring both of them until some time in the future is not an equivalent operation.

I thought about leveraging Callable in the solution I've posted in place of AsyncHttpResponse but use of Callable (which implies a relationship to the executor services) seemed too arbitrary and misleading.

> 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@...
For additional commands, e-mail: dev-help@...

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

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

Unfortunately, no.  I looked at doing something like that early on.
The problem is that the request needs to be sent independently of
waiting for the response.  Deferring both of them until some time in
the future is not an equivalent operation.

Mike




--
Mike Cumings

> 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@...
For additional commands, e-mail: dev-help@...

     [ https://issues.apache.org/jira/browse/HTTPCLIENT-854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Cumings updated HTTPCLIENT-854:
------------------------------------

    Comment: was deleted

(was: Unfortunately, no.  I looked at doing something like that early on.
The problem is that the request needs to be sent independently of
waiting for the response.  Deferring both of them until some time in
the future is not an equivalent operation.

Mike




--
Mike Cumings
)

> 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@...
For additional commands, e-mail: dev-help@...

    [ 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-unsubscribe@...
For additional commands, e-mail: dev-help@...

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

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

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-unsubscribe@...
For additional commands, e-mail: dev-help@...

    [ 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@...
For additional commands, e-mail: dev-help@...

    [ 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-unsubscribe@...
For additional commands, e-mail: dev-help@...

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

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

Sure.  Here's the link to the spec.  Section 4 gives a nice overview:

http://xmpp.org/extensions/xep-0124.html

> 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@...
For additional commands, e-mail: dev-help@...

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

Oleg Kalnichevski commented on HTTPCLIENT-854:
----------------------------------------------

Mike,

(1) It is too late to make any changes to the API. The patch in its present state cannot be committed until 5.0 (which may never happen). Please consider restructuring your code in such a way that it can be incorporated into the HttpClient code line as a separate, optional module. That optional module could go into the 4.1 branch.

(2) I am not entirely sure the proposed solution is generic enough. It surely addresses your specific use case, but it may be not common enough. I kind of think HttpCore NIO could have been a better foundation for a fully asynchronous HTTP client. Building asynchronous HTTP client on top of HttpCore NIO would be a major, major effort but I personally think that would be the right thing to do. Have a look at it.

Oleg

> 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@...
For additional commands, e-mail: dev-help@...

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

Sam Berlin commented on HTTPCLIENT-854:
---------------------------------------

I can see the patch being reformed to not require API changes.  An issue with it for me was the word "async" -- I read that and immediately think, "Oh, things are going to happen asynchronously and I'll be notified when they're done!"  Since that isn't what's happening, it's not really async to me.  It's more like a separation of the request & response stages.

What about something like:

AdvancedHttpClient extends HttpClient {
    /** Blocks as the request is sent, but does not process the response. */
    DeferredHttpResponse sendRequest(...) throws ...;
}

DeferredHttpResponse {
    /** Processes a pending response and returns the ultimate response after handling redirects & all that. */
    HttpResponse processResponse() throws ...;
}

> 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@...
For additional commands, e-mail: dev-help@...

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

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

@Oleg:  Sure, I can restructure the code a bit to make it a bit more of an add-on.  The use of interfaces everywhere sure makes it difficult to maintain API stability.  There's no way I could possibly justify the time to build up a new API on top of HttpCore NIO.  I agree that this is an uncommon use scenario (though I have seen requests for this made in the past on the list).  Knowing that, I want to leverage as much existing code as possible to prevent this code path from getting left behind, stale, etc.

@Sam: I couldn't find a nomenclature that I liked at all.  Since I'm equally unhappy with anything I've come up with, I have no problem switching over to "deferred".

I'm running out of time to dedicate to this but what I'm thinking I'll do is:
- Add an interface ("SplitExecutionHttpClient", "SerialHttpClient", ...?) which defines the executeRequest(...) method.
- Implement the above interface in AbstractHttpClient.
- Add an interface following the same naming scheme for "SplitExecutionRequestDirector"
- Implement the SERD interface in the DefaultRequestDirector
- Update the AbstractHttpClient to reference the DefaultRequestDirector using the new interface when split exec is desired
- Update the HttpCore code to follow the new naming scheme

Sound acceptable?

> 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@...
For additional commands, e-mail: dev-help@...

     [ https://issues.apache.org/jira/browse/HTTPCLIENT-854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Cumings updated HTTPCLIENT-854:
------------------------------------

    Attachment: HTTPCLIENT-854_httpclient_2009-06-19_1.patch
                HTTPCLIENT-854_httpcore_2009-06-19_1.patch

Updated patches based on feedback thus far.  I also added an explicit "dispose" method to the deferred responses in the event that the caller wants to clean up resources yet abort the receipt and processing of the response data.

> 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@...
For additional commands, e-mail: dev-help@...

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

Oleg Kalnichevski commented on HTTPCLIENT-854:
----------------------------------------------

Mike,

I think we all agree the proposed solution targets a fairly uncommon use case and it is suboptimal. Therefore I personally would very much prefer this code to be entirely decoupled from the standard API even at the expense of some code duplication. There is still hope we will develop a full blown async HTTP client based on HttpCore NIO.

Oleg

> 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@...
For additional commands, e-mail: dev-help@...

    [ 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@...
For additional commands, e-mail: dev-help@...

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

Oleg Kalnichevski commented on HTTPCLIENT-854:
----------------------------------------------

Mike

The original developer of HttpAsync decided to not proceed with its development. Feel free to search the archives for more details on HttpAsync.

http://svn.apache.org/repos/asf/httpcomponents/httpasync/branches/suspended-at-HttpCoreAlpha4/

All I am asking is to not couple this functionality with DefaultRequestDirector / DefaultHttpClient but provide a separate client dedicated specifically for deferred request execution, so that at some point of time it could be deprecated in favor of an architecturally better solution based on HttpCore NIO.

Oleg

> 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@...
For additional commands, e-mail: dev-help@...

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

Sam Berlin commented on HTTPCLIENT-854:
---------------------------------------

Oleg,

Would you be comfortable with a refactoring of DefaultRequestDirector that was independent of (but compatible with) this change, so that it could be introduced without duplicating the code?  I see some benefit in a refactoring the DefaultRequestDirector.execute method for the sake of simplicity & testability alone.  If that refactoring can enable a subclass to hook in and perform just a portion of the execute, then all the better.

I'm not sure this particular problem needs (or even wants) any NIO or asynchronous behavior.  It seems more like a two-stepped blocking solution, which suits itself well to httpclient (as opposed to httpcore or httpcore-nio).

> 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@...
For additional commands, e-mail: dev-help@...