[
https://issues.apache.org/jira/browse/AVRO-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13044074#comment-13044074
]
James Baldassari commented on AVRO-539:
---------------------------------------
That is an interesting idea, Scott. I think it's a good option for a couple of
reasons. We don't have to return a Future with every RPC call, which is likely
to be ignored in most cases. It also makes the generated interfaces cleaner
and less confusing for someone trying to figure out how to use it for the first
time.
We would need to make a minor change to ProtocolFuture to override
handleError(Exception e) and throw that Exception inside get() if an error is
returned by the callback. Also, ProtocolFuture could simply wrap a
CallFuture<T>. Something like this:
{code}
public class ProtocolFuture<T> implements Future<T>, Callback<T> {
private final CallFuture<T> future = new CallFuture<T>();
@Override
public final void handleResult(T result) {
future.setResponse(result);
}
@Override
public final void handleError(Exception e) {
future.setError(e);
}
@Override
public final T get() throws InterruptedException, ExecutionException {
return future.get();
}
@Override
public T get(long timeout, TimeUnit unit) throws InterruptedException,
ExecutionException, TimeoutException {
return future.get(timeout, unit);
}
}
{code}
After thinking about it for a bit, I really like this approach. The interface
is clean, and you can still use either Callbacks or Futures. Any other
opinions?
> 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
