Mailing-List: contact dev-help@avro.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@avro.apache.org
Date: Mon, 22 Oct 2012 15:38:12 +0000 (UTC)
From: "James Baldassari (JIRA)" <jira@apache.org>
To: dev@avro.apache.org
Message-ID: <119505349.10125.1350920292222.JavaMail.jiratomcat@arcas>
In-Reply-To: <545558286.60780.1340782303732.JavaMail.jiratomcat@issues-vm>
Subject: [jira] [Comment Edited] (AVRO-1122) Java: Avro RPC Requestor can
 block during handshake in async mode
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/AVRO-1122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481440#comment-13481440 ] 

James Baldassari edited comment on AVRO-1122 at 10/22/12 3:36 PM:
------------------------------------------------------------------

This is the expected behavior with the current implementation of NettyTransceiver.  The first request always blocks until the handshake is completed.  All subsequent requests are asynchronous.  There is an existing issue to improve this for Netty and other asynchronous implementations: AVRO-1008.

IIRC there is a workaround.  You can call getRemote() on the NettyTransceiver (or maybe the Responder?) immediately after you create it.  This will force the handshake to happen so that the first RPC will be asynchronous.  However, I think calling this method results in a stack trace being logged on the server side because the server gets a request with an empty RPC name.  It's harmless but just kind of annoying.

Another approach might be writing a patch to perform an asynchronous handshake, but the basic problem is that the handshake needs to be completed prior to invoking any RPC.  So there has to be some mechanism to block/prevent RPCs until the handshake is completed, unless anyone can think of another way to do it.
                
      was (Author: jbaldassari):
    This is the expected behavior with the current implementation of NettyTransceiver.  The first request always blocks until the handshake is completed.  All subsequent requests are asynchronous.  There is an existing issue to improve this for Netty and other asynchronous implementations: AVRO-1008.

IIRC there is a workaround.  You can call getRemote() on the NettyTransceiver immediately after you create it.  This will force the handshake to happen so that the first RPC will be asynchronous.  However, I think calling this method results in a stack trace being logged on the server side because the server gets a request with an empty RPC name.  It's harmless but just kind of annoying.

Another approach might be writing a patch to perform an asynchronous handshake, but the basic problem is that the handshake needs to be completed prior to invoking any RPC.  So there has to be some mechanism to block/prevent RPCs until the handshake is completed, unless anyone can think of another way to do it.
                  
> Java: Avro RPC Requestor can block during handshake in async mode
> -----------------------------------------------------------------
>
>                 Key: AVRO-1122
>                 URL: https://issues.apache.org/jira/browse/AVRO-1122
>             Project: Avro
>          Issue Type: Bug
>    Affects Versions: 1.6.3
>            Reporter: Mike Percy
>         Attachments: Screen Shot 2012-06-27 at 12.43.32 AM.png
>
>
> We are seeing an issue in Flume where the Avro RPC Requestor is blocking for long periods of time waiting for the Avro handshake to complete. Since we are using the API with Futures, this should not block.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira