You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avro.apache.org by "Mike Percy (JIRA)" <ji...@apache.org> on 2012/06/27 09:31:42 UTC
[jira] [Created] (AVRO-1122) Java: Avro RPC Requestor can block
during handshake in async mode
Mike Percy created AVRO-1122:
--------------------------------
Summary: 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
Reporter: Mike Percy
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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AVRO-1122) Java: Avro RPC Requestor can block
during handshake in async mode
Posted by "Mike Percy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-1122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Percy updated AVRO-1122:
-----------------------------
Attachment: Screen Shot 2012-06-27 at 12.43.32 AM.png
YourKit screenshot attached.
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AVRO-1122) Java: Avro RPC Requestor can block
during handshake in async mode
Posted by "Mike Percy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-1122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13486585#comment-13486585 ]
Mike Percy commented on AVRO-1122:
----------------------------------
Hi James, yep now I know it pretty much has to block based on the Transceiver API and the way the Proxy is implemented. It's a little tricky, since at the moment you can't perform the handshake before the proxy object is instantiated AFAICT. Based on my experience with Avro RPC in Flume, I'd like to be able to use a client API that provides something along the lines of:
1. set address & port of endpoint (NettyTransceiver does this today)
2. set interface (SpecificRequestor.getClient() does this today)
3. async TCP connection using a CallFuture (not possible today)
- throws if address/port not set properly
4. async handshake using a CallFuture (not possible today)
- throws if not connected, or if interface not set properly
- alternatively, specify a boolean flag to connect if needed
5. async RPC calls (possible using the CallFuture / Callback APIs)
- throws if handshake not completed or connection is not open
I'm not sure how to weave that into the existing framework yet, though.
> 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
[jira] [Commented] (AVRO-1122) Java: Avro RPC Requestor can block
during handshake in async mode
Posted by "James Baldassari (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-1122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481440#comment-13481440 ]
James Baldassari commented on AVRO-1122:
----------------------------------------
This is the expected behavior with the current implementation of 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
[jira] [Comment Edited] (AVRO-1122) Java: Avro RPC Requestor can
block during handshake in async mode
Posted by "James Baldassari (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Comment Edited] (AVRO-1122) Java: Avro RPC Requestor can
block during handshake in async mode
Posted by "James Baldassari (JIRA)" <ji...@apache.org>.
[ 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:35 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 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 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
[jira] [Updated] (AVRO-1122) Java: Avro RPC Requestor can block
during handshake in async mode
Posted by "Mike Percy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-1122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Percy updated AVRO-1122:
-----------------------------
Affects Version/s: 1.6.3
Seeing against Avro 1.6.3. Still figuring out how to reproduce since we are seeing this in a load testing environment.
> 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
>
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira