[
https://issues.apache.org/jira/browse/AVRO-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13044130#comment-13044130
]
Scott Carey commented on AVRO-539:
----------------------------------
I think CallFuture needs to use a CountDownLatch and not a Semaphore so that
two consecutive calls to get() don't cause it to block forever. Or , if there
is a race condition between retrieval and setting the result I think the
semaphore may block.
The Future interface defines get() as the following in the javadoc:
{noformat}
V get()
throws InterruptedException,
ExecutionException
Waits if necessary for the computation to complete, and then retrieves its
result.
Returns:
the computed result
Throws:
CancellationException - if the computation was cancelled
ExecutionException - if the computation threw an exception
InterruptedException - if the current thread was interrupted while
waiting
{noformat}
I interpret that to mean that it only blocks if necessary -- if the result has
not yet been returned. That behavior can be achieved with a CountDownLatch, so
that it blocks only until the count reaches 0. Additionally, isDone() will not
return true if get() is called after the result is set. Using a CountDownLatch
also simplifies the code.
Perhaps we should have CallFuture implement Callback<T>, replacing setResponse
and setError with handleResponse and handleError? Do we want to expose
CallFuture in the public API?
> Allow asynchronous clients to specify a callback to be run when server
> processing completes
> -------------------------------------------------------------------------------------------
>
> Key: AVRO-539
> URL: https://issues.apache.org/jira/browse/AVRO-539
> Project: Avro
> Issue Type: New Feature
> Reporter: Jeff Hammerbacher
> Attachments: AVRO-539.patch
>
>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
