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: ma...@bestweb.net [mailto:ma...@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 >
