Mailing-List: contact user-help@avro.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@avro.apache.org
From: Matt Gumbley <matt.gumbley@gmail.com>
Subject: Problem with initial use of callback methods in avro-ipc 1.8.1
To: user@avro.apache.org
Message-ID: <5809AD3A.4030406@gmail.com>
Date: Fri, 21 Oct 2016 06:52:58 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0)
 Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="------------090009000800080606030509"
archived-at: Fri, 21 Oct 2016 05:53:02 -0000

This is a multi-part message in MIME format.
--------------090009000800080606030509
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Hi,
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);
          t.transceive(request.getBytes(),
                       new TransceiverCallback<T>(request, callFuture));
          // Block until handshake complete
          callFuture.await();

Subsequent calls (once connected) reach a different part of the request
method:
    if (request.getMessage().isOneWay()) {
       ...
    } else {
       t.transceive(request.getBytes(),
                   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

--------------090009000800080606030509
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi,<br>
    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.<br>
    <br>
    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. <br>
    <br>
    I've traced this to Requestor::request : <br>
    <meta http-equiv="content-type" content="text/html; charset=utf-8">
    <br>
      /** Writes a request message and returns the result through a
    Callback. */<br>
      &lt;T&gt; void request(Request request, Callback&lt;T&gt;
    callback)<br>
        throws Exception {<br>
    <br>
    ... where there is an initial section performing a handshake if not
    connected, and performing a transceive that then blocks without
    timeout:<br>
    <br>
              CallFuture&lt;T&gt; callFuture = new
    CallFuture&lt;T&gt;(callback);<br>
              t.transceive(request.getBytes(),<br>
                           new TransceiverCallback&lt;T&gt;(request,
    callFuture));<br>
              // Block until handshake complete<br>
              callFuture.await();<br>
    <br>
    Subsequent calls (once connected) reach a different part of the
    request method:<br>
        if (request.getMessage().isOneWay()) {<br>
           ...<br>
        } else {<br>
           t.transceive(request.getBytes(),<br>
                       new TransceiverCallback&lt;T&gt;(request,
    callback));<br>
        }<br>
    <br>
    ... which returns immediately after sending, allowing me to await.<br>
    <br>
    <br>
    Is there a mechanism I'm missing that can establish the connection
    and perform the handshake without me making remote method calls? <br>
    Could a handshake timeout be added to Requestor, that is used in the
    above callFuture.await() ?<br>
    <br>
    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.<br>
    <br>
    (*) 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.<br>
    <br>
    <br>
    Kind regards,<br>
    Matt Gumbley<br>
  </body>
</html>

--------------090009000800080606030509--