thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konrad 'Hcorg' Grochowski <hc...@minions.org.pl>
Subject Re: oneway Thrift version 0.9.1 oneway flag generates regular T_CALL as opposed to T_ONEWAY with c++ code
Date Tue, 16 Sep 2014 10:01:36 GMT
I was able to reproduce Steven's problem. Seems that T_ONEWAY encodes 
badly in Compact protocol: "Thrift: Tue Sep 16 11:54:30 2014 received 
invalid message type 0 from client"

I'll debug all those shifts and masks etc, hopefully it's a programming 
mistake, not protocol issue (T_ONEWAY == 4 and there are 4 bits for 
message type, so everything should be ok...)

Konrad

W dniu 2014-09-15 15:07, Ben Craig pisze:
> Looks like an oversight to me.  The server side of the generated code in
> C++ respects T_ONEWAY and T_CALL.
>
> Coincidentally, someone at my company was likely going to run into this
> issue in about three weeks.  They are doing some fancy pass-through server
>
> stuff, and as a 'server' without access to a specific .thrift file, they
> need to know whether to wait as a 'client' when passing an RPC.  They were
>
> planning on looking at the message type to figure that out.
>
> I've looked at your commit, but have not tested it.  +0.9.
>
> Konrad Grochowski <hcorg@minions.org.pl> wrote on 09/14/2014 09:08:28 AM:
>
>> From: Konrad Grochowski <hcorg@minions.org.pl>
>> To: user@thrift.apache.org,
>> Date: 09/14/2014 09:09 AM
>> Subject: ODP: Re: oneway Thrift version 0.9.1 oneway flag generates
>> regular T_CALL as opposed to T_ONEWAY with c++ code
>>
>> 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
View raw message