[
https://issues.apache.org/jira/browse/THRIFT-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III updated THRIFT-2504:
---------------------------------------
Description:
Multiplexed Protocol provides a number of benefits. It would be useful for a
developer to be able to upgrade a server to use MultiplexedProtocol while still
allowing older clients using BinaryProtocol (or others?) to submit their older
requests and have them processed as they were before the upgrade, or perhaps at
the very least get an exception telling them to upgrade their client. Right
now I believe the behavior of connecting this way is undefined; correct me if I
am wrong.
In THRIFT-66 I handled this by using an unused byte in the VERSION_1 protocol
header which was always initialized to zero, so I made "channel zero" something
that the server side could implement. In that solution however both ends
continued to use BinaryProtocol so it was easy to maintain backwards
compatibility. In this case we have a server speaking MultiplexedProtocol and
a client speaking some other (BinaryProtocol, let's say). I'm curious what
folks who worked on MultiplexedProtocol think about this notion.
was:Multiplexed Protocol provides a number of benefits. It would be useful
for a developer to be able to upgrade a server to use MultiplexedProtocol while
still allowing older clients using BinaryProtocol (or others?) to submit their
older requests and have them processed as they were before the upgrade, or
perhaps at the very least get an exception telling them to upgrade their client.
> As a developer, I want a server-side upgrade to MultiplexedProtocol to allow
> an older client to continue working in order to maintain backwards
> compatibility
> -------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: THRIFT-2504
> URL: https://issues.apache.org/jira/browse/THRIFT-2504
> Project: Thrift
> Issue Type: Improvement
> Components: Java - Library
> Reporter: Aleksey Pesternikov
>
> Multiplexed Protocol provides a number of benefits. It would be useful for a
> developer to be able to upgrade a server to use MultiplexedProtocol while
> still allowing older clients using BinaryProtocol (or others?) to submit
> their older requests and have them processed as they were before the upgrade,
> or perhaps at the very least get an exception telling them to upgrade their
> client. Right now I believe the behavior of connecting this way is
> undefined; correct me if I am wrong.
> In THRIFT-66 I handled this by using an unused byte in the VERSION_1 protocol
> header which was always initialized to zero, so I made "channel zero"
> something that the server side could implement. In that solution however
> both ends continued to use BinaryProtocol so it was easy to maintain
> backwards compatibility. In this case we have a server speaking
> MultiplexedProtocol and a client speaking some other (BinaryProtocol, let's
> say). I'm curious what folks who worked on MultiplexedProtocol think about
> this notion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
