[
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: The original intention of this story was to allow an older
client to connect to a multiplexed server and continue to work by having the
multiplexed processor handle any request that does not contain a service name
and colon prefix. (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. 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.)
> 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
>
>
> The original intention of this story was to allow an older client to connect
> to a multiplexed server and continue to work by having the multiplexed
> processor handle any request that does not contain a service name and colon
> prefix.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
