Steven I can confirm that for my oneway messages I observe the same T_CALL (I have not looked into why)
The difference is that one way messages have fooClient::bar that just call send_bar and if it was not oneway it would call send_bar AND recv_bar Now realize that you do not have to use the RPC mechanism at all - you could just serialize objects into your messages, perhaps with a custom header (there may be something supported already). This is what we have been doing since thrift0.6.x for SOME of our connections - for that case we do not even define a service, just objects and an enumeration of messages On Fri, Sep 12, 2014 at 8:31 AM, Steven Varga <[email protected]> wrote: > Hi, > > the following service generates oneway RPC call flagged with T_CALL flag as > opposed to expected T_ONEWAY; I need the T_ONEWAY flag to implement proper > zero MQ message passing. Zero MQ message passing system differentiates > between request - reply patterns and push - pull ones at socket level; > > Am I doing something wrong ? > > best, > steve > > service foo { > oneway void bar( 1:string value ); > } > > void fooClient::put( const std::string& value ) { > send_bar( value ); // <- this is correct that recv_xxx is missing > } > > // ----- incorrect or unreasoned T_CALL instead of T_ONEWAY > void fooClient::send_bar(const std::string& value) { > int32_t cseqid = 0; > oprot_->writeMessageBegin("bar", ::apache::thrift::protocol::T_CALL, > cseqid); > .... > } > > ------ EXAMPLE ----- > service foo { > oneway void bar( 1:string value ); > } > > ------------- response excerpt ---------- > > void fooClient::bar(const std::string& value) > { > send_bar(value); > } > > void fooClient::send_bar(const std::string& value) > { > int32_t cseqid = 0; > oprot_->writeMessageBegin("bar", ::apache::thrift::protocol::T_CALL, > cseqid); > > foo_bar_pargs args; > args.value = &value; > args.write(oprot_); > > oprot_->writeMessageEnd(); > oprot_->getTransport()->writeEnd(); > oprot_->getTransport()->flush(); > } >
