You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Sangjin Lee (JIRA)" <ji...@apache.org> on 2007/11/21 01:36:43 UTC
[jira] Created: (GERONIMO-3615) AsyncHttpClient.sendRequest()
should return a future
AsyncHttpClient.sendRequest() should return a future
----------------------------------------------------
Key: GERONIMO-3615
URL: https://issues.apache.org/jira/browse/GERONIMO-3615
Project: Geronimo
Issue Type: New Feature
Security Level: public (Regular issues)
Components: AsyncHttpClient
Affects Versions: 1.x
Reporter: Sangjin Lee
Currently the caller gets notified when the I/O is completed via AsyncHttpClientCallback. While this works for many use cases, there may be situations where sendRequest() returning a future would lead to a much more straightforward programming model. This will become much more powerful especially if one initiates requests to multiple URLs at once.
I would request that sendRequest() return a future object on which one can query the status of the operation, and also obtain the result or an error case (exception or timeout) by calling methods on the future. It is desirable to have the return type implement java.util.concurrent.Future.
Furthermore, the implementation class of the Future could retain the reference to the callback. Then one can have a consolidated and coherent mechanism of completion (callbacks firing as a result of future completion).
In other words, the suggestion is to change the return type of sendRequest() from void to java.util.concurrent.Future<HttpResponseMessage>.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3615) AsyncHttpClient.sendRequest()
should return a future
Posted by "Sangjin Lee (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-3615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549147 ]
Sangjin Lee commented on GERONIMO-3615:
---------------------------------------
I have a patch ready that addresses this issue and also GERONIMO-3616.
Essentially the sendRequest() method is modified to return a ResponseFuture instead of void. In addition, an overloaded version of sendRequest() is created to take an additional argument of BlockingQueue<ResponseFuture>. The queue will serve as a completion queue on which a ResponseFuture object will be added as the request is complete.
The semantics is entirely analogous to a familiar java.util.concurrent.CompletionService, although I thought creating a concrete CompletionService implementation was an overkill.
I have also created a test class that exercises the new method.
I'll be uploading the patch...
> AsyncHttpClient.sendRequest() should return a future
> ----------------------------------------------------
>
> Key: GERONIMO-3615
> URL: https://issues.apache.org/jira/browse/GERONIMO-3615
> Project: Geronimo
> Issue Type: New Feature
> Security Level: public(Regular issues)
> Components: AsyncHttpClient
> Affects Versions: 1.x
> Reporter: Sangjin Lee
> Attachments: patch.zip
>
>
> Currently the caller gets notified when the I/O is completed via AsyncHttpClientCallback. While this works for many use cases, there may be situations where sendRequest() returning a future would lead to a much more straightforward programming model. This will become much more powerful especially if one initiates requests to multiple URLs at once.
> I would request that sendRequest() return a future object on which one can query the status of the operation, and also obtain the result or an error case (exception or timeout) by calling methods on the future. It is desirable to have the return type implement java.util.concurrent.Future.
> Furthermore, the implementation class of the Future could retain the reference to the callback. Then one can have a consolidated and coherent mechanism of completion (callbacks firing as a result of future completion).
> In other words, the suggestion is to change the return type of sendRequest() from void to java.util.concurrent.Future<HttpResponseMessage>.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3615) AsyncHttpClient.sendRequest() should
return a future
Posted by "Jeff Genender (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-3615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeff Genender closed GERONIMO-3615.
-----------------------------------
Resolution: Fixed
Never mind the last comment, I manually applied this patch, but the next one, if you could do a svn diff from the top directory, it will create the patch. For adding java or new files, just do an svn add and teh diff will pick those up. Thanks for the excellent patch!
> AsyncHttpClient.sendRequest() should return a future
> ----------------------------------------------------
>
> Key: GERONIMO-3615
> URL: https://issues.apache.org/jira/browse/GERONIMO-3615
> Project: Geronimo
> Issue Type: New Feature
> Security Level: public(Regular issues)
> Components: AsyncHttpClient
> Affects Versions: 1.x
> Reporter: Sangjin Lee
> Attachments: patch.zip
>
>
> Currently the caller gets notified when the I/O is completed via AsyncHttpClientCallback. While this works for many use cases, there may be situations where sendRequest() returning a future would lead to a much more straightforward programming model. This will become much more powerful especially if one initiates requests to multiple URLs at once.
> I would request that sendRequest() return a future object on which one can query the status of the operation, and also obtain the result or an error case (exception or timeout) by calling methods on the future. It is desirable to have the return type implement java.util.concurrent.Future.
> Furthermore, the implementation class of the Future could retain the reference to the callback. Then one can have a consolidated and coherent mechanism of completion (callbacks firing as a result of future completion).
> In other words, the suggestion is to change the return type of sendRequest() from void to java.util.concurrent.Future<HttpResponseMessage>.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3615) AsyncHttpClient.sendRequest()
should return a future
Posted by "Sangjin Lee (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-3615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545673 ]
Sangjin Lee commented on GERONIMO-3615:
---------------------------------------
I am working on code changes that achieves this and also aids the batch invocation (3616). I'll share it with you once it's reasonably complete.
> AsyncHttpClient.sendRequest() should return a future
> ----------------------------------------------------
>
> Key: GERONIMO-3615
> URL: https://issues.apache.org/jira/browse/GERONIMO-3615
> Project: Geronimo
> Issue Type: New Feature
> Security Level: public(Regular issues)
> Components: AsyncHttpClient
> Affects Versions: 1.x
> Reporter: Sangjin Lee
>
> Currently the caller gets notified when the I/O is completed via AsyncHttpClientCallback. While this works for many use cases, there may be situations where sendRequest() returning a future would lead to a much more straightforward programming model. This will become much more powerful especially if one initiates requests to multiple URLs at once.
> I would request that sendRequest() return a future object on which one can query the status of the operation, and also obtain the result or an error case (exception or timeout) by calling methods on the future. It is desirable to have the return type implement java.util.concurrent.Future.
> Furthermore, the implementation class of the Future could retain the reference to the callback. Then one can have a consolidated and coherent mechanism of completion (callbacks firing as a result of future completion).
> In other words, the suggestion is to change the return type of sendRequest() from void to java.util.concurrent.Future<HttpResponseMessage>.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3615) AsyncHttpClient.sendRequest()
should return a future
Posted by "Sangjin Lee (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-3615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549227 ]
Sangjin Lee commented on GERONIMO-3615:
---------------------------------------
Thanks. I'll do that from now on...
> AsyncHttpClient.sendRequest() should return a future
> ----------------------------------------------------
>
> Key: GERONIMO-3615
> URL: https://issues.apache.org/jira/browse/GERONIMO-3615
> Project: Geronimo
> Issue Type: New Feature
> Security Level: public(Regular issues)
> Components: AsyncHttpClient
> Affects Versions: 1.x
> Reporter: Sangjin Lee
> Attachments: patch.zip
>
>
> Currently the caller gets notified when the I/O is completed via AsyncHttpClientCallback. While this works for many use cases, there may be situations where sendRequest() returning a future would lead to a much more straightforward programming model. This will become much more powerful especially if one initiates requests to multiple URLs at once.
> I would request that sendRequest() return a future object on which one can query the status of the operation, and also obtain the result or an error case (exception or timeout) by calling methods on the future. It is desirable to have the return type implement java.util.concurrent.Future.
> Furthermore, the implementation class of the Future could retain the reference to the callback. Then one can have a consolidated and coherent mechanism of completion (callbacks firing as a result of future completion).
> In other words, the suggestion is to change the return type of sendRequest() from void to java.util.concurrent.Future<HttpResponseMessage>.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3615) AsyncHttpClient.sendRequest()
should return a future
Posted by "Sangjin Lee (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-3615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sangjin Lee updated GERONIMO-3615:
----------------------------------
Attachment: patch.zip
a suggested patch
> AsyncHttpClient.sendRequest() should return a future
> ----------------------------------------------------
>
> Key: GERONIMO-3615
> URL: https://issues.apache.org/jira/browse/GERONIMO-3615
> Project: Geronimo
> Issue Type: New Feature
> Security Level: public(Regular issues)
> Components: AsyncHttpClient
> Affects Versions: 1.x
> Reporter: Sangjin Lee
> Attachments: patch.zip
>
>
> Currently the caller gets notified when the I/O is completed via AsyncHttpClientCallback. While this works for many use cases, there may be situations where sendRequest() returning a future would lead to a much more straightforward programming model. This will become much more powerful especially if one initiates requests to multiple URLs at once.
> I would request that sendRequest() return a future object on which one can query the status of the operation, and also obtain the result or an error case (exception or timeout) by calling methods on the future. It is desirable to have the return type implement java.util.concurrent.Future.
> Furthermore, the implementation class of the Future could retain the reference to the callback. Then one can have a consolidated and coherent mechanism of completion (callbacks firing as a result of future completion).
> In other words, the suggestion is to change the return type of sendRequest() from void to java.util.concurrent.Future<HttpResponseMessage>.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3615) AsyncHttpClient.sendRequest()
should return a future
Posted by "Jeff Genender (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-3615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549168 ]
Jeff Genender commented on GERONIMO-3615:
-----------------------------------------
Sangjin...thanks for the patch...
Could you do a svn diff from the root of the source code and upload that, since those are easier to view and work with. Thanks!
> AsyncHttpClient.sendRequest() should return a future
> ----------------------------------------------------
>
> Key: GERONIMO-3615
> URL: https://issues.apache.org/jira/browse/GERONIMO-3615
> Project: Geronimo
> Issue Type: New Feature
> Security Level: public(Regular issues)
> Components: AsyncHttpClient
> Affects Versions: 1.x
> Reporter: Sangjin Lee
> Attachments: patch.zip
>
>
> Currently the caller gets notified when the I/O is completed via AsyncHttpClientCallback. While this works for many use cases, there may be situations where sendRequest() returning a future would lead to a much more straightforward programming model. This will become much more powerful especially if one initiates requests to multiple URLs at once.
> I would request that sendRequest() return a future object on which one can query the status of the operation, and also obtain the result or an error case (exception or timeout) by calling methods on the future. It is desirable to have the return type implement java.util.concurrent.Future.
> Furthermore, the implementation class of the Future could retain the reference to the callback. Then one can have a consolidated and coherent mechanism of completion (callbacks firing as a result of future completion).
> In other words, the suggestion is to change the return type of sendRequest() from void to java.util.concurrent.Future<HttpResponseMessage>.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.