[
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.
http://avro.apache.org/docs/current/sasl.html#anonymous
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
