[ 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: I want a server-side upgrade to MultiplexedProtocol to allow an older client to be handled properly in order to maintain backwards compatibility (was: 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) > 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)