thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James E. King, III (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (THRIFT-2504) 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
Date Sat, 21 Jan 2017 16:12:26 GMT

     [ 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: 
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.

  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.


> 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
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 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)

Mime
View raw message