You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Mike Cumings (JIRA)" <ji...@apache.org> on 2009/06/17 23:26:07 UTC
[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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-854) RFE: Provide mechanism to allow
request transmission and response reception to be performed independently
Posted by "Sam Berlin (JIRA)" <ji...@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
[jira] Commented: (HTTPCLIENT-854) RFE: Provide mechanism to allow
request transmission and response reception to be performed independently
Posted by "Mike Cumings (JIRA)" <ji...@apache.org>.
[ 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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-854) RFE: Provide mechanism to allow
request transmission and response reception to be performed independently
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723228#action_12723228 ]
Oleg Kalnichevski commented on HTTPCLIENT-854:
----------------------------------------------
Mike,
This scenario actually is another reason why DefaultRequestDirector ought not to be used for deferred execution. HttpResponse and HttpClientConnection are not thread safe. Neither is DefaultRequestDirector. It makes no attempts to ensure only one thread has access to the HttpResponse object and the underlying response stream.
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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-854) RFE: Provide mechanism to allow
request transmission and response reception to be performed independently
Posted by "Mike Cumings (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723428#action_12723428 ]
Mike Cumings commented on HTTPCLIENT-854:
-----------------------------------------
You're right, Ortwin. I wasn't taking the memory model into account. So this issue should probably get back-burnered until httpclient becomes more generally threadsafe. I'll just have to live with the extra overhead for the time being.
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_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
[jira] Commented: (HTTPCLIENT-854) RFE: Provide mechanism to allow
request transmission and response reception to be performed independently
Posted by "Mike Cumings (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723295#action_12723295 ]
Mike Cumings commented on HTTPCLIENT-854:
-----------------------------------------
I noticed that. In my use case it ends up working out just fine though, since it is a thread hand-off, not two threads working concurrently against the same object instances.
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_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
[jira] Commented: (HTTPCLIENT-854) RFE: Provide mechanism to allow
request transmission and response reception to be performed independently
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ 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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-854) RFE: Provide mechanism to allow
request transmission and response reception to be performed independently
Posted by "Mike Cumings (JIRA)" <ji...@apache.org>.
[ 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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-854) RFE: Provide mechanism to allow
request transmission and response reception to be performed independently
Posted by "Mike Cumings (JIRA)" <ji...@apache.org>.
[ 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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-854) RFE: Provide mechanism to allow
request transmission and response reception to be performed independently
Posted by "Mike Cumings (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723146#action_12723146 ]
Mike Cumings commented on HTTPCLIENT-854:
-----------------------------------------
Oleg, that wouldn't work for my use case since it wouldn't allow for the response to be processed by another thread. Example:
0: sendRequest
0: enqueue deferred response
0: return
1: sendRequest
1: enqueue deferred response
1: return
2: pop deferred response
2: block until response received
2: process response
2: pop deferred response
2: block until response received
2: process response
...
This is critical for the following two interrelated reasons:
o It allows a single thread to be used for response processing
o It allows the sender to guarantee that the message has been sent before execution returns to the caller
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_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
[jira] Commented: (HTTPCLIENT-854) RFE: Provide mechanism to allow
request transmission and response reception to be performed independently
Posted by "Mike Cumings (JIRA)" <ji...@apache.org>.
[ 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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Issue Comment Edited: (HTTPCLIENT-854) RFE: Provide
mechanism to allow request transmission and response reception to be
performed independently
Posted by "Mike Cumings (JIRA)" <ji...@apache.org>.
[ 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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-854) RFE: Provide mechanism to allow
request transmission and response reception to be performed independently
Posted by "Ortwin Glück (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723338#action_12723338 ]
Ortwin Glück commented on HTTPCLIENT-854:
-----------------------------------------
Mike, even then there are no visbility guarantees between these threads. The fact that "it works" for you doesn't mean it will always work on every platform.
> 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
[jira] Commented: (HTTPCLIENT-854) RFE: Provide mechanism to allow
request transmission and response reception to be performed independently
Posted by "Sam Berlin (JIRA)" <ji...@apache.org>.
[ 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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-854) RFE: Provide mechanism to allow
request transmission and response reception to be performed independently
Posted by "Sam Berlin (JIRA)" <ji...@apache.org>.
[ 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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-854) RFE: Provide mechanism to allow
request transmission and response reception to be performed independently
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ 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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-854) RFE: Provide mechanism to allow
request transmission and response reception to be performed independently
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723556#action_12723556 ]
Oleg Kalnichevski commented on HTTPCLIENT-854:
----------------------------------------------
> So this issue should probably get back-burnered until httpclient becomes more generally threadsafe
Here we back to the square one. HttpClient will not become "more generally threadsafe" unless someone steps up and develops a implementation optimized for deferred / asynchronous HTTP request execution. DefaultHttpClient is perfectly thread safe when used as designed.
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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Updated: (HTTPCLIENT-854) RFE: Provide mechanism to allow
request transmission and response reception to be performed independently
Posted by "Mike Cumings (JIRA)" <ji...@apache.org>.
[ 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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-854) RFE: Provide mechanism to allow
request transmission and response reception to be performed independently
Posted by "Sam Berlin (JIRA)" <ji...@apache.org>.
[ 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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-854) RFE: Provide mechanism to allow
request transmission and response reception to be performed independently
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ 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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-854) RFE: Provide mechanism to allow
request transmission and response reception to be performed independently
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12722875#action_12722875 ]
Oleg Kalnichevski commented on HTTPCLIENT-854:
----------------------------------------------
Sam
The biggest problem with HttpClient 3.x has been the tendency to add features at the expense of design. I personally would not like the same to happen to HttpClient 4.x.
Let's face a very simple fact: we do not have enough people to maintain HttpClient even with its current feature set. Adding more features without adding more people to the project willing to maintain the code hardly helps. The _only_ reason why I have not started working on asynchronous version of HttpClient is because it do not want to end up the only person maintaining it.
Code duplication can be as bad as abuse of inheritance. By all of means feel free to refactor DefaultRequestDirector, but I suspect that adding more functionality to it will not make it any simpler. I see code duplication as a lesser evil in this particular case.
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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-854) RFE: Provide mechanism to allow
request transmission and response reception to be performed independently
Posted by "Mike Cumings (JIRA)" <ji...@apache.org>.
[ 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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-854) RFE: Provide mechanism to allow
request transmission and response reception to be performed independently
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723009#action_12723009 ]
Oleg Kalnichevski commented on HTTPCLIENT-854:
----------------------------------------------
Mike, Sam
A very simple solution to this issue involving no code duplication at all would be a callback interface
interface AfterRequestBeforeResponse {
void doSomeImportantStuff(HttpRequest request, HttpContext context);
}
An implementation of that interface could be injected into DefaultHttpClient using a setter and passed to the DefaultRequestDirector as a constructor parameter.
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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-854) RFE: Provide mechanism to allow
request transmission and response reception to be performed independently
Posted by "Sam Berlin (JIRA)" <ji...@apache.org>.
[ 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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-854) RFE: Provide mechanism to allow
request transmission and response reception to be performed independently
Posted by "Mike Cumings (JIRA)" <ji...@apache.org>.
[ 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
[jira] Updated: (HTTPCLIENT-854) RFE: Provide mechanism to allow
request transmission and response reception to be performed independently
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ 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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Updated: (HTTPCLIENT-854) RFE: Provide mechanism to allow
request transmission and response reception to be performed independently
Posted by "Mike Cumings (JIRA)" <ji...@apache.org>.
[ 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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Updated: (HTTPCLIENT-854) RFE: Provide mechanism to allow
request transmission and response reception to be performed independently
Posted by "Mike Cumings (JIRA)" <ji...@apache.org>.
[ 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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org