[
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:
{code}
public class TestProtocolNetty extends TestProtocolSpecific {
@Override
public Server createServer(Responder testResponder) throws Exception {
return new NettyServer(responder, new InetSocketAddress(0));
}
@Override
public Transceiver createTransceiver() throws Exception{
return new NettyTransceiver(new InetSocketAddress(server.getPort()));
}
@Override
protected int getExpectedHandshakeCount() {
return REPEATING;
}
}
{code}
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:
{code}
} finally {
if(!connectionMetadata.isConnected()) {
e.getChannel().close();
}
}
{code}
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
necessary?
> 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
