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