[
https://issues.apache.org/jira/browse/AVRO-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13044130#comment-13044130
]
Scott Carey edited comment on AVRO-539 at 6/3/11 11:40 PM:
-----------------------------------------------------------
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 in the current
implementation, which does not comply with the Future interface semantics.
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?
was (Author: scott_carey):
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
