You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by ma...@bestweb.net on 2010/03/12 01:47:57 UTC
Exception after Oneway?
If a CALL contains an unknown name, the server returns an EXCEPTION
instead of a REPLY.
However, what if it is a ONEWAY? Shouldn't it just drop it on the floor
without trying to reply?
Mayan
RE: Exception after Oneway?
Posted by Mark Slee <ms...@facebook.com>.
Yeah, in that case I think it might be okay not to add the client-side compilation option. Would rather not do that anyways, if we don't have to, since then we'll have to go through an annoying deprecation process for the code that sets that option (unless we want to have it be redundantly available forever, or just start ignoring it).
-----Original Message-----
From: Todd Lipcon [mailto:todd@cloudera.com]
Sent: Thursday, March 11, 2010 6:47 PM
To: thrift-dev@incubator.apache.org
Subject: Re: Exception after Oneway?
On Thu, Mar 11, 2010 at 6:43 PM, David Reiss <dr...@facebook.com> wrote:
> > Tough call on breaking the backwards compatibility. There are a lot of
> folks out there with deployed async methods that would not appreciate
> breakage.
> Well, it would only affect C++ and Erlang servers built with Thrift prior
> to r761389.
>
In that case, an 0.3 release will be compatible with 0.2 (since 0.2 includes
that revision). So, I'd say this seems fine to make the change now without a
lot of client options, and tell people that we don't support rolling upgrade
from prereleases prior to that version.
-Todd
>
> > I wonder if we could mitigate things by making people specifically
> compile client-code with an option to send ONEWAY instead of CALL
> That sounds like a good way to go about it.
>
--
Todd Lipcon
Software Engineer, Cloudera
Re: Exception after Oneway?
Posted by Todd Lipcon <to...@cloudera.com>.
On Thu, Mar 11, 2010 at 6:43 PM, David Reiss <dr...@facebook.com> wrote:
> > Tough call on breaking the backwards compatibility. There are a lot of
> folks out there with deployed async methods that would not appreciate
> breakage.
> Well, it would only affect C++ and Erlang servers built with Thrift prior
> to r761389.
>
In that case, an 0.3 release will be compatible with 0.2 (since 0.2 includes
that revision). So, I'd say this seems fine to make the change now without a
lot of client options, and tell people that we don't support rolling upgrade
from prereleases prior to that version.
-Todd
>
> > I wonder if we could mitigate things by making people specifically
> compile client-code with an option to send ONEWAY instead of CALL
> That sounds like a good way to go about it.
>
--
Todd Lipcon
Software Engineer, Cloudera
Re: Exception after Oneway?
Posted by David Reiss <dr...@facebook.com>.
> Tough call on breaking the backwards compatibility. There are a lot of folks out there with deployed async methods that would not appreciate breakage.
Well, it would only affect C++ and Erlang servers built with Thrift prior to r761389.
> I wonder if we could mitigate things by making people specifically compile client-code with an option to send ONEWAY instead of CALL
That sounds like a good way to go about it.
RE: Exception after Oneway?
Posted by Mark Slee <ms...@facebook.com>.
Ah crap, I didn't realize we weren't already using the T_ONEWAY message type.
Tough call on breaking the backwards compatibility. There are a lot of folks out there with deployed async methods that would not appreciate breakage.
I wonder if we could mitigate things by making people specifically compile client-code with an option to send ONEWAY instead of CALL, but have the server accept both by default.
Then, after some period of time, we could change the client-side behavior.
-----Original Message-----
From: David Reiss [mailto:dreiss@facebook.com]
Sent: Thursday, March 11, 2010 6:25 PM
To: thrift-dev@incubator.apache.org
Subject: Re: Exception after Oneway?
The problem is that the only way to tell if the message is oneway is if the server is aware of the existence of the function. If it is an unknown function, the server will not know whether the client is waiting for a response or not. In r761389, I added a new message type "T_ONEWAY", which is recognized as an alias of T_CALL. The plan was to eventually change the clients to make them send this message types with oneway calls to allow servers (and generic proxies) to automatically determine if the client expected a response. However, if we make this change, new clients will not be able to send oneway messages to C++ or Erlang servers built with Thrift versions prior to r761389.
Committers, what do you think? Has the time come to take this step forward? To make the first backwards-incompatible wire-format change since Thrift was released as Open Source?
--David
Mark Slee wrote:
> Not an unreasonable suggestion.
>
> The client won't even attempt to read the reply, and if the client sends another request after the ONEWAY, it'll get confused by reading back the exception from the 1st call as the result of the 2nd call. Message sequence ids should make it possible to address this issue, though I'm not sure our current implementation does.
>
> So yeah, given that the client will never attempt to read anything back after a ONEWAY, by design, I agree we shouldn't ever send back anything, even in the error state.
>
> -----Original Message-----
> From: mayan@bestweb.net [mailto:mayan@bestweb.net]
> Sent: Thursday, March 11, 2010 4:48 PM
> To: Thrift Developer
> Subject: Exception after Oneway?
>
> If a CALL contains an unknown name, the server returns an EXCEPTION
> instead of a REPLY.
>
> However, what if it is a ONEWAY? Shouldn't it just drop it on the floor
> without trying to reply?
>
> Mayan
>
Re: Exception after Oneway?
Posted by David Reiss <dr...@facebook.com>.
> Could we do this in two phases? (a) be able to receive T_ONEWAY as identical
> to T_CALL in all the servers
That's what r761389 did.
Re: Exception after Oneway?
Posted by Todd Lipcon <to...@cloudera.com>.
On Thu, Mar 11, 2010 at 6:24 PM, David Reiss <dr...@facebook.com> wrote:
> The problem is that the only way to tell if the message is oneway is if the
> server is aware of the existence of the function. If it is an unknown
> function, the server will not know whether the client is waiting for a
> response or not. In r761389, I added a new message type "T_ONEWAY", which
> is recognized as an alias of T_CALL. The plan was to eventually change the
> clients to make them send this message types with oneway calls to allow
> servers (and generic proxies) to automatically determine if the client
> expected a response. However, if we make this change, new clients will not
> be able to send oneway messages to C++ or Erlang servers built with Thrift
> versions prior to r761389.
>
> Committers, what do you think? Has the time come to take this step
> forward? To make the first backwards-incompatible wire-format change since
> Thrift was released as Open Source?
>
Could we do this in two phases? (a) be able to receive T_ONEWAY as identical
to T_CALL in all the servers, then in the next release start sending
T_ONEWAY? That way if people go 0.2 -> 0.3 -> 0.4 they can do rolling
upgrades.
-Todd
>
> --David
>
> Mark Slee wrote:
> > Not an unreasonable suggestion.
> >
> > The client won't even attempt to read the reply, and if the client sends
> another request after the ONEWAY, it'll get confused by reading back the
> exception from the 1st call as the result of the 2nd call. Message sequence
> ids should make it possible to address this issue, though I'm not sure our
> current implementation does.
> >
> > So yeah, given that the client will never attempt to read anything back
> after a ONEWAY, by design, I agree we shouldn't ever send back anything,
> even in the error state.
> >
> > -----Original Message-----
> > From: mayan@bestweb.net [mailto:mayan@bestweb.net]
> > Sent: Thursday, March 11, 2010 4:48 PM
> > To: Thrift Developer
> > Subject: Exception after Oneway?
> >
> > If a CALL contains an unknown name, the server returns an EXCEPTION
> > instead of a REPLY.
> >
> > However, what if it is a ONEWAY? Shouldn't it just drop it on the floor
> > without trying to reply?
> >
> > Mayan
> >
>
--
Todd Lipcon
Software Engineer, Cloudera
Re: Exception after Oneway?
Posted by David Reiss <dr...@facebook.com>.
The problem is that the only way to tell if the message is oneway is if the server is aware of the existence of the function. If it is an unknown function, the server will not know whether the client is waiting for a response or not. In r761389, I added a new message type "T_ONEWAY", which is recognized as an alias of T_CALL. The plan was to eventually change the clients to make them send this message types with oneway calls to allow servers (and generic proxies) to automatically determine if the client expected a response. However, if we make this change, new clients will not be able to send oneway messages to C++ or Erlang servers built with Thrift versions prior to r761389.
Committers, what do you think? Has the time come to take this step forward? To make the first backwards-incompatible wire-format change since Thrift was released as Open Source?
--David
Mark Slee wrote:
> Not an unreasonable suggestion.
>
> The client won't even attempt to read the reply, and if the client sends another request after the ONEWAY, it'll get confused by reading back the exception from the 1st call as the result of the 2nd call. Message sequence ids should make it possible to address this issue, though I'm not sure our current implementation does.
>
> So yeah, given that the client will never attempt to read anything back after a ONEWAY, by design, I agree we shouldn't ever send back anything, even in the error state.
>
> -----Original Message-----
> From: mayan@bestweb.net [mailto:mayan@bestweb.net]
> Sent: Thursday, March 11, 2010 4:48 PM
> To: Thrift Developer
> Subject: Exception after Oneway?
>
> If a CALL contains an unknown name, the server returns an EXCEPTION
> instead of a REPLY.
>
> However, what if it is a ONEWAY? Shouldn't it just drop it on the floor
> without trying to reply?
>
> Mayan
>
RE: Exception after Oneway?
Posted by Mark Slee <ms...@facebook.com>.
Not an unreasonable suggestion.
The client won't even attempt to read the reply, and if the client sends another request after the ONEWAY, it'll get confused by reading back the exception from the 1st call as the result of the 2nd call. Message sequence ids should make it possible to address this issue, though I'm not sure our current implementation does.
So yeah, given that the client will never attempt to read anything back after a ONEWAY, by design, I agree we shouldn't ever send back anything, even in the error state.
-----Original Message-----
From: mayan@bestweb.net [mailto:mayan@bestweb.net]
Sent: Thursday, March 11, 2010 4:48 PM
To: Thrift Developer
Subject: Exception after Oneway?
If a CALL contains an unknown name, the server returns an EXCEPTION
instead of a REPLY.
However, what if it is a ONEWAY? Shouldn't it just drop it on the floor
without trying to reply?
Mayan