You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avro.apache.org by "James Baldassari (Created) (JIRA)" <ji...@apache.org> on 2012/01/25 10:50:40 UTC
[jira] [Created] (AVRO-1008) Allow IPC clients to perform the IPC
handshake before the first RPC is invoked
Allow IPC clients to perform the IPC handshake before the first RPC is invoked
------------------------------------------------------------------------------
Key: AVRO-1008
URL: https://issues.apache.org/jira/browse/AVRO-1008
Project: Avro
Issue Type: Improvement
Affects Versions: 1.6.1
Reporter: James Baldassari
Currently, the first RPC must complete before any subsequent RPCs may be invoked using the same Transceiver instance. The reason for this behavior is that the IPC client-server handshake must be performed before any requests can be exchanged. So while the first RPC is being invoked, all other threads using the same Transceiver instance will block. The goal of this enhancement is to allow clients to perform a handshake with the server _before_ any RPCs are invoked to avoid blocking any threads once the Transceiver is put into service.
I have a patch for review that I think will enable clients to perform the handshake before the first RPC is sent. The changes consist of:
* Modification to the Responder to handle a request that contains only a handshake (without an RPC)
* Addition of overridden SpecificRequestor.getClient(...) methods that take an boolean indicating whether the handshake should be performed immediately upon initialization of the Requestor
* Unit test which is essentially the same as the test I wrote for AVRO-1001, but it uses a pre-RPC handshake rather than invoking the add(...) RPC to perform the handshake
--
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-1008) Allow IPC clients to perform the IPC
handshake before the first RPC is invoked
Posted by "James Baldassari (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
James Baldassari updated AVRO-1008:
-----------------------------------
Assignee: James Baldassari
Status: Patch Available (was: Open)
> Allow IPC clients to perform the IPC handshake before the first RPC is invoked
> ------------------------------------------------------------------------------
>
> Key: AVRO-1008
> URL: https://issues.apache.org/jira/browse/AVRO-1008
> Project: Avro
> Issue Type: Improvement
> Affects Versions: 1.6.1
> Reporter: James Baldassari
> Assignee: James Baldassari
> Labels: java
> Attachments: AVRO-1008.patch
>
>
> Currently, the first RPC must complete before any subsequent RPCs may be invoked using the same Transceiver instance. The reason for this behavior is that the IPC client-server handshake must be performed before any requests can be exchanged. So while the first RPC is being invoked, all other threads using the same Transceiver instance will block. The goal of this enhancement is to allow clients to perform a handshake with the server _before_ any RPCs are invoked to avoid blocking any threads once the Transceiver is put into service.
> I have a patch for review that I think will enable clients to perform the handshake before the first RPC is sent. The changes consist of:
> * Modification to the Responder to handle a request that contains only a handshake (without an RPC)
> * Addition of overridden SpecificRequestor.getClient(...) methods that take an boolean indicating whether the handshake should be performed immediately upon initialization of the Requestor
> * Unit test which is essentially the same as the test I wrote for AVRO-1001, but it uses a pre-RPC handshake rather than invoking the add(...) RPC to perform the handshake
--
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-1008) Allow IPC clients to perform the IPC
handshake before the first RPC is invoked
Posted by "Doug Cutting (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202661#comment-13202661 ]
Doug Cutting commented on AVRO-1008:
------------------------------------
We already support pre-forcing the handshake by calling getRemote(). However this currently creates an error message on the server side each time it's done, which you address here. Also it would be good to make this more widely known, as it's useful.
Some comments & questions:
- We should update the RPC specification to note that if the empty string is passed as the message name during a handshake negotiation then it should be ignored. Or we might say that an empty message name is always to be ignored, to permit ping messages in any protocol at any time.
- The change to Responder might also check !wasConnected, unless we decide that pings are desired.
- What's the advantage of passing a boolean to the Requestor constructor to calling a method like getRemote()? We might instead add a new method ensureHandshake() or somesuch that does nothing but call getRemote().
- Why doesn't SpecificRequestor#getClient() just pass performHandshake to the requestor constructor, so the only call to getRemote() is in the base Requestor class, avoiding the duplication of that logic?
> Allow IPC clients to perform the IPC handshake before the first RPC is invoked
> ------------------------------------------------------------------------------
>
> Key: AVRO-1008
> URL: https://issues.apache.org/jira/browse/AVRO-1008
> Project: Avro
> Issue Type: Improvement
> Affects Versions: 1.6.1
> Reporter: James Baldassari
> Assignee: James Baldassari
> Labels: java
> Attachments: AVRO-1008.patch
>
>
> Currently, the first RPC must complete before any subsequent RPCs may be invoked using the same Transceiver instance. The reason for this behavior is that the IPC client-server handshake must be performed before any requests can be exchanged. So while the first RPC is being invoked, all other threads using the same Transceiver instance will block. The goal of this enhancement is to allow clients to perform a handshake with the server _before_ any RPCs are invoked to avoid blocking any threads once the Transceiver is put into service.
> I have a patch for review that I think will enable clients to perform the handshake before the first RPC is sent. The changes consist of:
> * Modification to the Responder to handle a request that contains only a handshake (without an RPC)
> * Addition of overridden SpecificRequestor.getClient(...) methods that take an boolean indicating whether the handshake should be performed immediately upon initialization of the Requestor
> * Unit test which is essentially the same as the test I wrote for AVRO-1001, but it uses a pre-RPC handshake rather than invoking the add(...) RPC to perform the handshake
--
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-1008) Allow IPC clients to perform the IPC
handshake before the first RPC is invoked
Posted by "James Baldassari (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13216586#comment-13216586 ]
James Baldassari commented on AVRO-1008:
----------------------------------------
bq. We should update the RPC specification to note that if the empty string is passed as the message name during a handshake negotiation then it should be ignored. Or we might say that an empty message name is always to be ignored, to permit ping messages in any protocol at any time.
I think that both of these sound like good solutions. Either way an RPC with an empty name should be considered reserved for internal use by Avro.
bq. The change to Responder might also check !wasConnected, unless we decide that pings are desired.
Makes sense. I've been thinking about the question of whether pings should be a core part of the protocol, and it doesn't seem like they would be useful in the general case. Can you think of a use case for pings that the majority of users would want/need? I suppose that one use case might be a type of pessimistic connection management scheme in which we ping the server periodically to make sure the connection is alive before we attempt an RPC. However, there is nothing to prevent the connection from terminating between the ping and the RPC, so even in this case the client would have to support an optimistic connection management policy in which the connection is assumed to be alive until a failure occurs, at which time the connection would have to be reestablished. The only other use case I can think of right now would be measuring client-server latency. Now this might be useful, and we could consider adding a method in Responder to give some kind of estimate of client-server latency by using pings.
bq. What's the advantage of passing a boolean to the Requestor constructor to calling a method like getRemote()? We might instead add a new method ensureHandshake() or somesuch that does nothing but call getRemote().
I suppose there is no real advantage to having this flag in the constructor, other than possibly making it more obvious to users who are more likely to look at the JavaDoc of the constructor than all of the other methods in the class. If we decide that we want to include pings as a general feature of Avro protocols, I suppose we could simply have a method called ping() or ensureHandshake() or measureLantency() that would establish this handshake if necessary.
bq. Why doesn't SpecificRequestor#getClient() just pass performHandshake to the requestor constructor, so the only call to getRemote() is in the base Requestor class, avoiding the duplication of that logic?
Good catch. It should be changed as you suggested.
So I guess the next steps are:
* Decide whether to change the RPC spec to make an empty message name reserved for use by Avro and to specify what should happen when a server receives a request with an empty message name
* Decide whether pings should be supported
* Make the suggested changes to the patch
> Allow IPC clients to perform the IPC handshake before the first RPC is invoked
> ------------------------------------------------------------------------------
>
> Key: AVRO-1008
> URL: https://issues.apache.org/jira/browse/AVRO-1008
> Project: Avro
> Issue Type: Improvement
> Affects Versions: 1.6.1
> Reporter: James Baldassari
> Assignee: James Baldassari
> Labels: java
> Attachments: AVRO-1008.patch
>
>
> Currently, the first RPC must complete before any subsequent RPCs may be invoked using the same Transceiver instance. The reason for this behavior is that the IPC client-server handshake must be performed before any requests can be exchanged. So while the first RPC is being invoked, all other threads using the same Transceiver instance will block. The goal of this enhancement is to allow clients to perform a handshake with the server _before_ any RPCs are invoked to avoid blocking any threads once the Transceiver is put into service.
> I have a patch for review that I think will enable clients to perform the handshake before the first RPC is sent. The changes consist of:
> * Modification to the Responder to handle a request that contains only a handshake (without an RPC)
> * Addition of overridden SpecificRequestor.getClient(...) methods that take an boolean indicating whether the handshake should be performed immediately upon initialization of the Requestor
> * Unit test which is essentially the same as the test I wrote for AVRO-1001, but it uses a pre-RPC handshake rather than invoking the add(...) RPC to perform the handshake
--
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-1008) Allow IPC clients to perform the IPC
handshake before the first RPC is invoked
Posted by "James Baldassari (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
James Baldassari updated AVRO-1008:
-----------------------------------
Attachment: AVRO-1008.patch
Patch attached.
> Allow IPC clients to perform the IPC handshake before the first RPC is invoked
> ------------------------------------------------------------------------------
>
> Key: AVRO-1008
> URL: https://issues.apache.org/jira/browse/AVRO-1008
> Project: Avro
> Issue Type: Improvement
> Affects Versions: 1.6.1
> Reporter: James Baldassari
> Labels: java
> Attachments: AVRO-1008.patch
>
>
> Currently, the first RPC must complete before any subsequent RPCs may be invoked using the same Transceiver instance. The reason for this behavior is that the IPC client-server handshake must be performed before any requests can be exchanged. So while the first RPC is being invoked, all other threads using the same Transceiver instance will block. The goal of this enhancement is to allow clients to perform a handshake with the server _before_ any RPCs are invoked to avoid blocking any threads once the Transceiver is put into service.
> I have a patch for review that I think will enable clients to perform the handshake before the first RPC is sent. The changes consist of:
> * Modification to the Responder to handle a request that contains only a handshake (without an RPC)
> * Addition of overridden SpecificRequestor.getClient(...) methods that take an boolean indicating whether the handshake should be performed immediately upon initialization of the Requestor
> * Unit test which is essentially the same as the test I wrote for AVRO-1001, but it uses a pre-RPC handshake rather than invoking the add(...) RPC to perform the handshake
--
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