[
https://issues.apache.org/jira/browse/THRIFT-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15833052#comment-15833052
]
Jens Geyer edited comment on THRIFT-2504 at 1/21/17 4:54 PM:
-------------------------------------------------------------
**As a developer** I continue to ask myself whether other folks (i.e.
non-developers) are around here? **As an email reader, I'd like to see the
entire topic in the mail subject line instead of an non-informative, cut-off
boilerplate prefix "As a developer, I want a serversi..."**. Honestly, do we
need to do that?
was (Author: jensg):
As a developer I coninue to ask myself whether other folks (i.e.
non-developers) are around here? As an email reader, I'd like to see the topic
in tzhe summary instead of an non-informative boilerplate prefix "As a
developer, I want a serversi...". Honestly, do we need to do that?
> As a developer, I want a server-side upgrade to MultiplexedProtocol to allow
> an older client to be handled properly 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
> Assignee: James E. King, III
>
> 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 is one of those changes that would require every language to adopt and
> be made part of the core requirements of MultiplexedProtocol if people feel
> it is worth it. The alternative is that the developer could continue to run
> an older protocol server on the same port that throws an exception telling
> the client to upgrade and what port to go to in the message. This isn't
> exactly firewall friendly because it needs a new port opened but it is a
> possible solution. Thoughts and suggestions welcome as to whether this is
> worth doing or we should resolve as won't fix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
