[
https://issues.apache.org/jira/browse/THRIFT-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III updated THRIFT-2504:
---------------------------------------
Summary: TMultiplexedProcessor should allow registering default processor
called if no service name is present (was: I want a server-side upgrade to
MultiplexedProtocol to maintain backwards compatibility with older clients)
> TMultiplexedProcessor should allow registering default processor called if no
> service name is present
> -----------------------------------------------------------------------------------------------------
>
> 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
> Fix For: 0.11.0
>
>
> 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)
