I see. That explains quite a bit. Thanks for the quick reply! -- Norman Casagrande Head of Music Research last.fm
> -----Original Message----- > From: David Reiss [mailto:dre...@facebook.com] > Sent: 04 May 2010 17:43 > To: thrift-dev@incubator.apache.org > Subject: Re: Use of T_ONEWAY > > We discussed it in this thread > <http://markmail.org/thread/t4rdbevdvkesofqu>, > and there was a general consensus that it is okay to go ahead with > phase 2 > of the plan. We just haven't gotten around to it yet. > > --David > > Casagrande, Norman wrote: > > Hi, > > > > While writing a simple application that balances thrift calls to > different servers, I stumbled upon oneway (former async) calls. From a > processor prospective there's no way to tell whether one call will > return or not, forcing me to provide such information upfront. > > > > This seems odd given that TProtocol defines T_ONEWAY as one of the > possible message types (see the TMessageType enum), but apparently this > is *never* being used: any function use T_CALL instead. > > > > Normally this is not a problem because the compiler generates both > the server and the client code and they both know which call is oneway > and which not, but that's not the case for definition-agnostic programs > that wants to parse the thrift serialized data. > > > > This seemed to be the goal of the patch in THRIFT-388, but I have > seen no updates since. > > > > Is there any way around this? > > > > -- > > Norman Casagrande > > Head of Music Research > > last.fm > > > > > >
