[
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.
