avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Baldassari (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (AVRO-1122) Java: Avro RPC Requestor can block during handshake in async mode
Date Mon, 22 Oct 2012 15:38:12 GMT

    [ 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

Mime
View raw message