thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konrad Grochowski <hc...@minions.org.pl>
Subject ODP: Re: oneway Thrift version 0.9.1 oneway flag generates regular T_CALL as opposed to T_ONEWAY with c++ code
Date Sun, 14 Sep 2014 14:08:28 GMT
I suspected that something will break - that's why I submited pull req to see what will Travis
say :)

I'll look further into it, also I hope for some explaining comments to issue from devs ;)

Konrad

-------- Oryginalna wiadomość --------
Od: Steven Varga <steven.varga@gmail.com> 
Data:14.09.2014  14:41  (GMT+01:00) 
Do: user@thrift.apache.org 
Temat: Re: oneway Thrift version 0.9.1 oneway flag generates regular T_CALL as opposed to
T_ONEWAY with c++ code 

Hello Konrad,

I looked at the patch but it only resolves the issue posted; and may lead
to deeper problems:
Whereas  TBinaryProtocol is ok with T_ONEWAY flag, TCompactProtocol seems
to have a different way of handling things [it filters it out?], and
TDenseProtocol also failed test  but I didn't follow up with that and the
rest of the provided protocols.

steve

On Sun, Sep 14, 2014 at 7:19 AM, Konrad 'Hcorg' Grochowski <
hcorg@minions.org.pl> wrote:

> I've created issue https://issues.apache.org/jira/browse/THRIFT-2704 and
> submited patch, maybe it'll get accepted :)
>
> W dniu 2014-09-12 18:25, Randy Abernethy pisze:
>
>  +1
>> On Sep 12, 2014 8:13 AM, "Nevo Hed" <nhed+thriftusr@aereo.com> wrote:
>>
>>  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 <steven.varga@gmail.com>
>>> 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();
>>>> }
>>>>
>>>>
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message