avro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Gumbley <matt.gumb...@gmail.com>
Subject Problem with initial use of callback methods in avro-ipc 1.8.1
Date Fri, 21 Oct 2016 05:52:58 GMT
I'm using Avro-IPC 1.8.1 and also the current master branch. Java
1.7.0_75, OSX El Capitan. Using a NettyTransceiver.

I'm trying to use callbacks in remote method calls(*) so that I can
timeout if the remote side does not reply, and have run into a problem:
the first remote method call I make (with a CallFuture) always blocks
for the entire duration of the call; it does not return immediately
allowing me to await for my timeout duration. However, once connected,
and the handshake has been performed, subsequent calls successfully
allow me to await the completion of the CallFuture.

I've traced this to Requestor::request :

  /** Writes a request message and returns the result through a Callback. */
  <T> void request(Request request, Callback<T> callback)
    throws Exception {

... where there is an initial section performing a handshake if not
connected, and performing a transceive that then blocks without timeout:

          CallFuture<T> callFuture = new CallFuture<T>(callback);
                       new TransceiverCallback<T>(request, callFuture));
          // Block until handshake complete

Subsequent calls (once connected) reach a different part of the request
    if (request.getMessage().isOneWay()) {
    } else {
                   new TransceiverCallback<T>(request, callback));

... which returns immediately after sending, allowing me to await.

Is there a mechanism I'm missing that can establish the connection and
perform the handshake without me making remote method calls?
Could a handshake timeout be added to Requestor, that is used in the
above callFuture.await() ?

I could add a kludgey no-op one-way method to each protocol I define,
that I call before anything else - this could still block though.

(*) There doesn't seem to be a mechanism for providing a timeout for
*all* remote method invocations, without supplying my own CallFuture to
each call - so I have a dynamic proxy with which I can set a global
timeout on all method calls, this then dispatches non-callback method
invocations to their callback-supplying variants, with a CallFuture that
the invoke method awaits on, for the global timeout duration. I'm happy
to contribute this to the project, if it would be useful, or work it
into the Requestor.

Kind regards,
Matt Gumbley

View raw message