You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2017/02/18 14:03:44 UTC
[jira] [Commented] (THRIFT-2504) I want a server-side upgrade to
MultiplexedProtocol to maintain backwards compatibility with older clients
[ https://issues.apache.org/jira/browse/THRIFT-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15873175#comment-15873175 ]
ASF GitHub Bot commented on THRIFT-2504:
----------------------------------------
GitHub user jeking3 opened a pull request:
https://github.com/apache/thrift/pull/1195
THRIFT-2504: Add default processor to java multiplexed processor to handle older clients
Supercedes PR #113 - I fixed the test case so it actually runs and added a missing test case.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/jeking3/thrift THRIFT-2504
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/thrift/pull/1195.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1195
----
commit b37938861fb7a6d5d66f7d92f7867469aa8393a7
Author: Aleksey Pesternikov <ap...@alekseys-mbp.att.net>
Date: 2014-05-01T20:58:18Z
THRIFT-2504: Add default processor to java multiplexed processor to handle older clients
----
> I want a server-side upgrade to MultiplexedProtocol to maintain backwards compatibility with older clients
> ----------------------------------------------------------------------------------------------------------
>
> 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 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.15#6346)