avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Cutting (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AVRO-625) RPC: permit out-of-order responses
Date Thu, 14 Jun 2012 19:43:42 GMT

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

Doug Cutting commented on AVRO-625:

My hope is that we can standardize on a single Avro RPC wire format that both:
  - permits out-of-order responses; and
  - permits encryption, authentication and authorization.

Currently NettyTransceiver provides the former and SaslSocketTransceiver provides the latter.

My original proposal above was to add out-of-order to SaslSocketTransceiver in a back-compatible
manner.  But it seems that lots of folks are already using NettyTransceiver in production.
 So I wonder if we instead might add SASL negotiation to NettyTransceiver and otherwise standardize
on its wire format.  The overhead of adding this is very small when security features are
not used, just adding a few bytes to the first request and response.


To implement this I'd:
 - add a new SaslTransceiver that updates SaslSocketTransceiver to be compatible with NettyTransceiver,
 - add a new SaslNettyTransceiver that adds the anonymous SASL handshake to NettyTransceiver.
 - deprecate the other transceivers.

This simple change would mean that folks would still have to choose between out-of-order responses
and security, but the two would use a compatible format, so that eventually one or the other
could be extended to support both without breaking existing applications.  The specification
would then contain a single wire format that supports both, a single alternative to Http.

Does this sound like a reasonable approach?
> RPC: permit out-of-order responses
> ----------------------------------
>                 Key: AVRO-625
>                 URL: https://issues.apache.org/jira/browse/AVRO-625
>             Project: Avro
>          Issue Type: New Feature
>          Components: java, spec
>            Reporter: Doug Cutting
>            Assignee: Doug Cutting
> It should be possible, when using a stateful, connection-based transport, for a client
to complete a second request over a connection before the first request has returned.  In
other words, responses should be permitted to arrive out-of-order.

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


View raw message