You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@thrift.apache.org by Daniel Kluesing <dk...@bluekai.com> on 2010/03/17 03:13:23 UTC
async c++ client / THRIFT-1
I wanted/needed something approximating async requests on the client - directly call send_ stuff, do unrelated stuff that might fail, directly call recv_ stuff - so I hacked into the c++ generator on 0.2.0 a bit more support for cseqid and rseqid. I did this somewhat quickly and while it works for my purposes, it isn't the 'right' thing to do. Is there any news on http://issues.apache.org/jira/browse/THRIFT-1 or anyone working on a proper nonblocking c++ client? (I saw the spotify ASIO patch)
(and if anyone out there wants similar functionality, I can port my changes to trunk and make a patch, I didn't bother since this has lain dormant for quite a while, so I'm guessing interest is low)
Re: async c++ client / THRIFT-1
Posted by Mayan Moudgill <ma...@bestweb.net>.
So, if I understand things correctly - you do send#1, you don't get
response#1, so you do send#2. Since the server is NOT out-of-order, it
will respond with response#1 then response#2.
The only thing you're going to save is part of the time to parse
response#1 - you're STILL going to have to read all of response#1 and
parse it enough to find the message boundary.
Do I understand something wrong? Is the overhead of doing a full parse
vs. a skip of a message that high?
If the cost of parsing messages constitutes a significant overhead, have
you considered using cthrift? It should have a lower overhead for the
parsing, perhaps enough to solve your problems. If want to, I'll be more
than happy to tailor cthrift to your needs and work with you on any
stability issues.
Mayan
Daniel Kluesing wrote:
>>I'm a little curious why you would expect to get repsonses out-of-order.
>
>
> It's case where I might bail out after calling the send_ but before calling recv_,
> and I don't want to tear-down/reestablish the TCP connection before I
send another
> request, so the next call needs to know to ignore. (Basically, some
tight time
> constraints where it's better to not have that data than to be slow)
>
> I think the split calls is good enough for me. An aside, if you ever want a
> tester for your CFG stuff, feel free to ping me off list. Love to
take a peak.
>
> -----Original Message-----
> From: Mayan Moudgill [mailto:mayan@bestweb.net]
> Sent: Wednesday, March 17, 2010 10:39 AM
> To: thrift-user@incubator.apache.org; Daniel Kluesing
> Subject: Re: async c++ client / THRIFT-1
>
> I'm a little curious why you would expect to get repsonses out-of-order.
> If you're using TCP/IP (or some other inherently FIFO transport) + a
> FIFO server, then RPC responses will appear in the order in which the
> send were sent. Why would you need to reorder cseqids? Are you planning
> on using UDP or something else? Or do you want a non-order-preserving
> server? Or are you communicating with multiple servers? In the last
> case, I'm assuming you'll have different sockets for each server - but
> since the communication with each server will be FIFO, you still won't
> need to reorder cseqids.
>
> As for recv being blocking:
> 1. You can use an O_NONBLOCK socket (maybe not in TSocket.py, but
> cthrift uses O_NONBLOCK sockets).
> 2. But that doesn't solve the problem if you're talking to multiple
> sockets and the size of response is > PIPE_BUF, then it is possible for
> a RPC response to be split up into multiple packets. So, you'll read the
> data from the first packet, then get blocked waiting for the second
> packet to come in - UNLESS you can set up things so that when you get
> blocked, you switch to a different context (thread/coroutine) to process
> any other data.
>
> I can't speak for the Thrift team, but I don't think splitting a client
> call into a send part and a receive part is enough to make a fully
> non-blocking client, and they may be trying to figure out how to get there.
>
> I'm working on some ideas for non-coroutine/context switch based,
> partial progress receivers [they involve treating the RPC response
> specification as a CFG {which it is} derive a table driven parser, and
> then save the intermediate parse state on a block] - these are for the
> server, but it should be trivial to add to the client. However, I will
> only be implementing them in cthrift, not Thrift.
>
> Mayan
>
> Daniel Kluesing wrote:
>
>>Well, what I'm really curious about is a fully non-blocking c++ client.
>
> > What I'm doing now is sending the send_'s, setting cseqids myself, and
> > then sorting out the responses based on the rseqid, that's ok, but the
> > recv call in TSocket is still a blocking call. Since it's been an open
> > issue for so long, I'm curious if there are others working on it, or
> > deep seeded reasons why it's not been done that I just don't know about.
>
>>-----Original Message-----
>>From: Mayan Moudgill [mailto:mayan@bestweb.net]
>>Sent: Tuesday, March 16, 2010 7:41 PM
>>To: thrift-user@incubator.apache.org; Daniel Kluesing
>>Subject: Re: async c++ client / THRIFT-1
>>
>>I'm guessing you want the abilitiy to separate the calls and receives on
>>a client; is that correct?
>>
>>Thanks
>>
>>Mayan
>>
>>Daniel Kluesing wrote:
>>
>>
>>
>>>I wanted/needed something approximating async requests on the client - directly call send_ stuff, do unrelated stuff that might fail, directly call recv_ stuff - so I hacked into the c++ generator on 0.2.0 a bit more support for cseqid and rseqid. I did this somewhat quickly and while it works for my purposes, it isn't the 'right' thing to do. Is there any news on http://issues.apache.org/jira/browse/THRIFT-1 or anyone working on a proper nonblocking c++ client? (I saw the spotify ASIO patch)
>>>
>>>(and if anyone out there wants similar functionality, I can port my changes to trunk and make a patch, I didn't bother since this has lain dormant for quite a while, so I'm guessing interest is low)
>>>
>>
>>
>>
>>
>
>
>
RE: async c++ client / THRIFT-1
Posted by ma...@bestweb.net.
CFG stuff is in 0.3.3, though only for the client so far. Have a look.
Mayan
>>I'm a little curious why you would expect to get repsonses out-of-order.
>
> It's case where I might bail out after calling the send_ but before
> calling recv_, and I don't want to tear-down/reestablish the TCP
> connection before I send another request, so the next call needs to know
> to ignore. (Basically, some tight time constraints where it's better to
> not have that data than to be slow)
>
> I think the split calls is good enough for me. An aside, if you ever want
> a tester for your CFG stuff, feel free to ping me off list. Love to take a
> peak.
>
> -----Original Message-----
> From: Mayan Moudgill [mailto:mayan@bestweb.net]
> Sent: Wednesday, March 17, 2010 10:39 AM
> To: thrift-user@incubator.apache.org; Daniel Kluesing
> Subject: Re: async c++ client / THRIFT-1
>
> I'm a little curious why you would expect to get repsonses out-of-order.
> If you're using TCP/IP (or some other inherently FIFO transport) + a
> FIFO server, then RPC responses will appear in the order in which the
> send were sent. Why would you need to reorder cseqids? Are you planning
> on using UDP or something else? Or do you want a non-order-preserving
> server? Or are you communicating with multiple servers? In the last
> case, I'm assuming you'll have different sockets for each server - but
> since the communication with each server will be FIFO, you still won't
> need to reorder cseqids.
>
> As for recv being blocking:
> 1. You can use an O_NONBLOCK socket (maybe not in TSocket.py, but
> cthrift uses O_NONBLOCK sockets).
> 2. But that doesn't solve the problem if you're talking to multiple
> sockets and the size of response is > PIPE_BUF, then it is possible for
> a RPC response to be split up into multiple packets. So, you'll read the
> data from the first packet, then get blocked waiting for the second
> packet to come in - UNLESS you can set up things so that when you get
> blocked, you switch to a different context (thread/coroutine) to process
> any other data.
>
> I can't speak for the Thrift team, but I don't think splitting a client
> call into a send part and a receive part is enough to make a fully
> non-blocking client, and they may be trying to figure out how to get
> there.
>
> I'm working on some ideas for non-coroutine/context switch based,
> partial progress receivers [they involve treating the RPC response
> specification as a CFG {which it is} derive a table driven parser, and
> then save the intermediate parse state on a block] - these are for the
> server, but it should be trivial to add to the client. However, I will
> only be implementing them in cthrift, not Thrift.
>
> Mayan
>
> Daniel Kluesing wrote:
>> Well, what I'm really curious about is a fully non-blocking c++ client.
> > What I'm doing now is sending the send_'s, setting cseqids myself, and
> > then sorting out the responses based on the rseqid, that's ok, but the
> > recv call in TSocket is still a blocking call. Since it's been an open
> > issue for so long, I'm curious if there are others working on it, or
> > deep seeded reasons why it's not been done that I just don't know
> about.
>>
>> -----Original Message-----
>> From: Mayan Moudgill [mailto:mayan@bestweb.net]
>> Sent: Tuesday, March 16, 2010 7:41 PM
>> To: thrift-user@incubator.apache.org; Daniel Kluesing
>> Subject: Re: async c++ client / THRIFT-1
>>
>> I'm guessing you want the abilitiy to separate the calls and receives on
>> a client; is that correct?
>>
>> Thanks
>>
>> Mayan
>>
>> Daniel Kluesing wrote:
>>
>>
>>>I wanted/needed something approximating async requests on the client -
>>> directly call send_ stuff, do unrelated stuff that might fail, directly
>>> call recv_ stuff - so I hacked into the c++ generator on 0.2.0 a bit
>>> more support for cseqid and rseqid. I did this somewhat quickly and
>>> while it works for my purposes, it isn't the 'right' thing to do. Is
>>> there any news on http://issues.apache.org/jira/browse/THRIFT-1 or
>>> anyone working on a proper nonblocking c++ client? (I saw the spotify
>>> ASIO patch)
>>>
>>>(and if anyone out there wants similar functionality, I can port my
>>> changes to trunk and make a patch, I didn't bother since this has lain
>>> dormant for quite a while, so I'm guessing interest is low)
>>>
>>
>>
>>
>>
>
>
RE: async c++ client / THRIFT-1
Posted by Daniel Kluesing <dk...@bluekai.com>.
>I'm a little curious why you would expect to get repsonses out-of-order.
It's case where I might bail out after calling the send_ but before calling recv_, and I don't want to tear-down/reestablish the TCP connection before I send another request, so the next call needs to know to ignore. (Basically, some tight time constraints where it's better to not have that data than to be slow)
I think the split calls is good enough for me. An aside, if you ever want a tester for your CFG stuff, feel free to ping me off list. Love to take a peak.
-----Original Message-----
From: Mayan Moudgill [mailto:mayan@bestweb.net]
Sent: Wednesday, March 17, 2010 10:39 AM
To: thrift-user@incubator.apache.org; Daniel Kluesing
Subject: Re: async c++ client / THRIFT-1
I'm a little curious why you would expect to get repsonses out-of-order.
If you're using TCP/IP (or some other inherently FIFO transport) + a
FIFO server, then RPC responses will appear in the order in which the
send were sent. Why would you need to reorder cseqids? Are you planning
on using UDP or something else? Or do you want a non-order-preserving
server? Or are you communicating with multiple servers? In the last
case, I'm assuming you'll have different sockets for each server - but
since the communication with each server will be FIFO, you still won't
need to reorder cseqids.
As for recv being blocking:
1. You can use an O_NONBLOCK socket (maybe not in TSocket.py, but
cthrift uses O_NONBLOCK sockets).
2. But that doesn't solve the problem if you're talking to multiple
sockets and the size of response is > PIPE_BUF, then it is possible for
a RPC response to be split up into multiple packets. So, you'll read the
data from the first packet, then get blocked waiting for the second
packet to come in - UNLESS you can set up things so that when you get
blocked, you switch to a different context (thread/coroutine) to process
any other data.
I can't speak for the Thrift team, but I don't think splitting a client
call into a send part and a receive part is enough to make a fully
non-blocking client, and they may be trying to figure out how to get there.
I'm working on some ideas for non-coroutine/context switch based,
partial progress receivers [they involve treating the RPC response
specification as a CFG {which it is} derive a table driven parser, and
then save the intermediate parse state on a block] - these are for the
server, but it should be trivial to add to the client. However, I will
only be implementing them in cthrift, not Thrift.
Mayan
Daniel Kluesing wrote:
> Well, what I'm really curious about is a fully non-blocking c++ client.
> What I'm doing now is sending the send_'s, setting cseqids myself, and
> then sorting out the responses based on the rseqid, that's ok, but the
> recv call in TSocket is still a blocking call. Since it's been an open
> issue for so long, I'm curious if there are others working on it, or
> deep seeded reasons why it's not been done that I just don't know about.
>
> -----Original Message-----
> From: Mayan Moudgill [mailto:mayan@bestweb.net]
> Sent: Tuesday, March 16, 2010 7:41 PM
> To: thrift-user@incubator.apache.org; Daniel Kluesing
> Subject: Re: async c++ client / THRIFT-1
>
> I'm guessing you want the abilitiy to separate the calls and receives on
> a client; is that correct?
>
> Thanks
>
> Mayan
>
> Daniel Kluesing wrote:
>
>
>>I wanted/needed something approximating async requests on the client - directly call send_ stuff, do unrelated stuff that might fail, directly call recv_ stuff - so I hacked into the c++ generator on 0.2.0 a bit more support for cseqid and rseqid. I did this somewhat quickly and while it works for my purposes, it isn't the 'right' thing to do. Is there any news on http://issues.apache.org/jira/browse/THRIFT-1 or anyone working on a proper nonblocking c++ client? (I saw the spotify ASIO patch)
>>
>>(and if anyone out there wants similar functionality, I can port my changes to trunk and make a patch, I didn't bother since this has lain dormant for quite a while, so I'm guessing interest is low)
>>
>
>
>
>
RE: async c++ client / THRIFT-1
Posted by Mark Slee <ms...@facebook.com>.
To your other question, there are no deep seeded reasons for not doing this. It has been oft-talked about, but yet to happen.
I think the main reasons are simply that it is quite a complex implementation, and relatively few people have a real need for it (most client applications typically *need* to block until they get a response to do something with).
-----Original Message-----
From: Mayan Moudgill [mailto:mayan@bestweb.net]
Sent: Wednesday, March 17, 2010 10:39 AM
To: thrift-user@incubator.apache.org; dk@bluekai.com
Subject: Re: async c++ client / THRIFT-1
I'm a little curious why you would expect to get repsonses out-of-order.
If you're using TCP/IP (or some other inherently FIFO transport) + a
FIFO server, then RPC responses will appear in the order in which the
send were sent. Why would you need to reorder cseqids? Are you planning
on using UDP or something else? Or do you want a non-order-preserving
server? Or are you communicating with multiple servers? In the last
case, I'm assuming you'll have different sockets for each server - but
since the communication with each server will be FIFO, you still won't
need to reorder cseqids.
As for recv being blocking:
1. You can use an O_NONBLOCK socket (maybe not in TSocket.py, but
cthrift uses O_NONBLOCK sockets).
2. But that doesn't solve the problem if you're talking to multiple
sockets and the size of response is > PIPE_BUF, then it is possible for
a RPC response to be split up into multiple packets. So, you'll read the
data from the first packet, then get blocked waiting for the second
packet to come in - UNLESS you can set up things so that when you get
blocked, you switch to a different context (thread/coroutine) to process
any other data.
I can't speak for the Thrift team, but I don't think splitting a client
call into a send part and a receive part is enough to make a fully
non-blocking client, and they may be trying to figure out how to get there.
I'm working on some ideas for non-coroutine/context switch based,
partial progress receivers [they involve treating the RPC response
specification as a CFG {which it is} derive a table driven parser, and
then save the intermediate parse state on a block] - these are for the
server, but it should be trivial to add to the client. However, I will
only be implementing them in cthrift, not Thrift.
Mayan
Daniel Kluesing wrote:
> Well, what I'm really curious about is a fully non-blocking c++ client.
> What I'm doing now is sending the send_'s, setting cseqids myself, and
> then sorting out the responses based on the rseqid, that's ok, but the
> recv call in TSocket is still a blocking call. Since it's been an open
> issue for so long, I'm curious if there are others working on it, or
> deep seeded reasons why it's not been done that I just don't know about.
>
> -----Original Message-----
> From: Mayan Moudgill [mailto:mayan@bestweb.net]
> Sent: Tuesday, March 16, 2010 7:41 PM
> To: thrift-user@incubator.apache.org; Daniel Kluesing
> Subject: Re: async c++ client / THRIFT-1
>
> I'm guessing you want the abilitiy to separate the calls and receives on
> a client; is that correct?
>
> Thanks
>
> Mayan
>
> Daniel Kluesing wrote:
>
>
>>I wanted/needed something approximating async requests on the client - directly call send_ stuff, do unrelated stuff that might fail, directly call recv_ stuff - so I hacked into the c++ generator on 0.2.0 a bit more support for cseqid and rseqid. I did this somewhat quickly and while it works for my purposes, it isn't the 'right' thing to do. Is there any news on http://issues.apache.org/jira/browse/THRIFT-1 or anyone working on a proper nonblocking c++ client? (I saw the spotify ASIO patch)
>>
>>(and if anyone out there wants similar functionality, I can port my changes to trunk and make a patch, I didn't bother since this has lain dormant for quite a while, so I'm guessing interest is low)
>>
>
>
>
>
Re: async c++ client / THRIFT-1
Posted by Mayan Moudgill <ma...@bestweb.net>.
I'm a little curious why you would expect to get repsonses out-of-order.
If you're using TCP/IP (or some other inherently FIFO transport) + a
FIFO server, then RPC responses will appear in the order in which the
send were sent. Why would you need to reorder cseqids? Are you planning
on using UDP or something else? Or do you want a non-order-preserving
server? Or are you communicating with multiple servers? In the last
case, I'm assuming you'll have different sockets for each server - but
since the communication with each server will be FIFO, you still won't
need to reorder cseqids.
As for recv being blocking:
1. You can use an O_NONBLOCK socket (maybe not in TSocket.py, but
cthrift uses O_NONBLOCK sockets).
2. But that doesn't solve the problem if you're talking to multiple
sockets and the size of response is > PIPE_BUF, then it is possible for
a RPC response to be split up into multiple packets. So, you'll read the
data from the first packet, then get blocked waiting for the second
packet to come in - UNLESS you can set up things so that when you get
blocked, you switch to a different context (thread/coroutine) to process
any other data.
I can't speak for the Thrift team, but I don't think splitting a client
call into a send part and a receive part is enough to make a fully
non-blocking client, and they may be trying to figure out how to get there.
I'm working on some ideas for non-coroutine/context switch based,
partial progress receivers [they involve treating the RPC response
specification as a CFG {which it is} derive a table driven parser, and
then save the intermediate parse state on a block] - these are for the
server, but it should be trivial to add to the client. However, I will
only be implementing them in cthrift, not Thrift.
Mayan
Daniel Kluesing wrote:
> Well, what I'm really curious about is a fully non-blocking c++ client.
> What I'm doing now is sending the send_'s, setting cseqids myself, and
> then sorting out the responses based on the rseqid, that's ok, but the
> recv call in TSocket is still a blocking call. Since it's been an open
> issue for so long, I'm curious if there are others working on it, or
> deep seeded reasons why it's not been done that I just don't know about.
>
> -----Original Message-----
> From: Mayan Moudgill [mailto:mayan@bestweb.net]
> Sent: Tuesday, March 16, 2010 7:41 PM
> To: thrift-user@incubator.apache.org; Daniel Kluesing
> Subject: Re: async c++ client / THRIFT-1
>
> I'm guessing you want the abilitiy to separate the calls and receives on
> a client; is that correct?
>
> Thanks
>
> Mayan
>
> Daniel Kluesing wrote:
>
>
>>I wanted/needed something approximating async requests on the client - directly call send_ stuff, do unrelated stuff that might fail, directly call recv_ stuff - so I hacked into the c++ generator on 0.2.0 a bit more support for cseqid and rseqid. I did this somewhat quickly and while it works for my purposes, it isn't the 'right' thing to do. Is there any news on http://issues.apache.org/jira/browse/THRIFT-1 or anyone working on a proper nonblocking c++ client? (I saw the spotify ASIO patch)
>>
>>(and if anyone out there wants similar functionality, I can port my changes to trunk and make a patch, I didn't bother since this has lain dormant for quite a while, so I'm guessing interest is low)
>>
>
>
>
>
RE: async c++ client / THRIFT-1
Posted by Daniel Kluesing <dk...@bluekai.com>.
Well, what I'm really curious about is a fully non-blocking c++ client. What I'm doing now is sending the send_'s, setting cseqids myself, and then sorting out the responses based on the rseqid, that's ok, but the recv call in TSocket is still a blocking call. Since it's been an open issue for so long, I'm curious if there are others working on it, or deep seeded reasons why it's not been done that I just don't know about.
-----Original Message-----
From: Mayan Moudgill [mailto:mayan@bestweb.net]
Sent: Tuesday, March 16, 2010 7:41 PM
To: thrift-user@incubator.apache.org; Daniel Kluesing
Subject: Re: async c++ client / THRIFT-1
I'm guessing you want the abilitiy to separate the calls and receives on
a client; is that correct?
Thanks
Mayan
Daniel Kluesing wrote:
> I wanted/needed something approximating async requests on the client - directly call send_ stuff, do unrelated stuff that might fail, directly call recv_ stuff - so I hacked into the c++ generator on 0.2.0 a bit more support for cseqid and rseqid. I did this somewhat quickly and while it works for my purposes, it isn't the 'right' thing to do. Is there any news on http://issues.apache.org/jira/browse/THRIFT-1 or anyone working on a proper nonblocking c++ client? (I saw the spotify ASIO patch)
>
> (and if anyone out there wants similar functionality, I can port my changes to trunk and make a patch, I didn't bother since this has lain dormant for quite a while, so I'm guessing interest is low)
>
Re: async c++ client / THRIFT-1
Posted by Mayan Moudgill <ma...@bestweb.net>.
I'm guessing you want the abilitiy to separate the calls and receives on
a client; is that correct?
Thanks
Mayan
Daniel Kluesing wrote:
> I wanted/needed something approximating async requests on the client - directly call send_ stuff, do unrelated stuff that might fail, directly call recv_ stuff - so I hacked into the c++ generator on 0.2.0 a bit more support for cseqid and rseqid. I did this somewhat quickly and while it works for my purposes, it isn't the 'right' thing to do. Is there any news on http://issues.apache.org/jira/browse/THRIFT-1 or anyone working on a proper nonblocking c++ client? (I saw the spotify ASIO patch)
>
> (and if anyone out there wants similar functionality, I can port my changes to trunk and make a patch, I didn't bother since this has lain dormant for quite a while, so I'm guessing interest is low)
>