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:[email protected]]
Sent: Wednesday, March 17, 2010 10:39 AM
To: [email protected]; 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:[email protected]]
Sent: Tuesday, March 16, 2010 7:41 PM
To: [email protected]; 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)
