[
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 <[email protected]>
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)
