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] [Commented] (AVRO-539) Allow asynchronous clients to specify a callback to be run when server processing completes
Date Sun, 05 Jun 2011 22:39:47 GMT

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

James Baldassari commented on AVRO-539:

I'm just about ready to post a new version of the patch incorporating the ideas we've discussed
here.  I did run into one problem that I wanted to run by you guys.  I was trying to verify
that all the various handshake scenarios worked to make sure that I didn't introduce any regressions.
 I found that there was already a nice unit test for this, TestProtocolSpecific, in particular
the testParamVariation() test.  However, there didn't appear to be a version of this test
for Netty, so I made one by trivially extending TestProtocolSpecific like this:

public class TestProtocolNetty extends TestProtocolSpecific {
  public Server createServer(Responder testResponder) throws Exception {
    return new NettyServer(responder, new InetSocketAddress(0));
  public Transceiver createTransceiver() throws Exception{
    return new NettyTransceiver(new InetSocketAddress(server.getPort()));
  protected int getExpectedHandshakeCount() {
    return REPEATING;

When I ran that unit test, the testParamVariation() case hung.  I couldn't figure out what
was wrong at first, so I decided to run that same test against a clean checkout of trunk which
didn't have any of my changes.  It failed with a NPE when writing out data to the Netty channel.
 So I started thinking this might be an existing bug.  When I dug deeper I figured out basically
what was going on.  In NettyServer.NettyServerAvroHandler, around line 145, the server closes
the Netty channel if the handshake is not complete:

} finally {
  if(!connectionMetadata.isConnected()) {

So I believe what's happening is that the client performs the initial handshake, the server
detects that the protocols aren't exactly the same, and then closes the channel.  However,
the client (NettyTransceiver) doesn't ever re-establish the connection after the server closes
it.  So the client attempts to write the second part of the handshake to the Netty channel,
but the channel has been closed, so the server never receives the handshake and never sends
its reply.  This is why the test was hanging for me while attempting to read from the channel
(the client was waiting for a reply that never came).  When I commented out the "e.getChannel().close()"
line in NettyServer the test passed both against a clean trunk and with my patch.  I was hoping
someone could shed some light on why the server is closing the channel here.  Is this really

> 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

View raw message