I've implemented bi-directional event notifications using double-ended servers (Thrift server on each end). Each end needs a .thrift interface file or a combined .thrift that covers both ends. For local IPC it works well and is the most flexible approach IMHO. This approach may be difficult if the processes are on different machines. For example, each end would need to punch through the firewall; 2-way NAT traversal would be complex.
Another option for a single-ended server, and an alternative to polling, would be for the server to pend or block a notification RPC until something interesting happens. For instance, one thread might call client->ImmediateWork(), while a second thread calls client->NotifyMe(). ImmediateWork() is a regular RPC that the server processes and returns immediately. OTOH the server does not complete NotifyMe(), at least not until an event has occurred, after which the client can inspect the return value and decide what to do next. This was all done in C++ and I can't speak to whether Ruby support has other limitations. ------------------------------ *From:* Bryan Duxbury <[email protected]> *To:* [email protected] *Sent:* Thursday, January 12, 2012 11:31 AM *Subject:* Re: does thrift support async client for ruby? In rereading your original post, I think that I misread it initially. I think you're asking for server->client notifications, which we also don't support. If you don't want the client to wait, the simplest thing you can do is to have two methods - one to make a request that returns nothing, and another that gets the result if there is one. Then the client can poll on whatever appropriate interval. If you REALLY need notification based updates instead of polling, then the best thing to do would be to actually have your clients run a Thrift server as well and make the server know how to contact them with completion messages. This is complicated, and you're unfortunately on your own. On Wed, Jan 11, 2012 at 3:17 PM, T Vinod Gupta <[email protected]>wrote: > thanks Bryan. > Can you elaborate little more on what you meant by using threads to achieve > this? did you mean spawning multiple threads in ruby to get the data and > coalescing them somehow? > > thanks > > On Wed, Jan 11, 2012 at 3:05 PM, Bryan Duxbury <[email protected]> wrote: > > > I don't think we've implemented an async client in ruby thrift. > > > > The usual pattern is to use threads to achieve this sort of async behavior. > > > > On Thu, Jan 5, 2012 at 6:18 PM, T Vinod Gupta <[email protected]> > > wrote: > > > > > does anyone know if thrift (0.6.0 or 0.8.0) support async/non-blocking ruby > > > client? if yes, how does the client get the return results? > > > > > > in my setup, the client calls the service with a request that can take some > > > time for the server to respond to. so how can this be made non-blocking > > > wherein the client is gets notified with the results when the call really > > > returns? > > > > > > thanks > > > > > >
