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:[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) >>> >> >> >> >> > >
